An AI price needs a date and a workload beside it
Luna’s price cut was real. The lasting lesson is to keep dated rates and workload assumptions together so a copied price cannot silently rewrite an estimate.
The correction comes first: the Luna price cut was real. OpenAI’s July 30 announcement states standard API rates of $0.20 per million input tokens and $1.20 per million output tokens. An earlier launch price is historical evidence, not grounds to dismiss a later effective price.
That correction strengthens the operating rule I care about. An AI cost estimate should carry a dated rate record and a workload description. A model name beside one copied number is too little information to reconstruct what the estimate meant.
The problem is not that vendors should never change prices. Lower prices can make valuable work feasible. The problem is that a spreadsheet can preserve the model name while losing the commercial conditions that gave its number meaning.
Keep the rates separate long enough to do the arithmetic
Input and output can have different rates. Cached input can have another. Processing mode and service tier can change the applicable offer. A blended estimate is useful only when its underlying quantities and conditions remain available.
Take an illustrative workload with one million uncached input tokens and half a million output tokens, using the stated Luna standard rates. The token charge would be $0.20 plus $0.60, or $0.80, before any other applicable charges. Changing the output volume changes the total even if the input volume and model stay fixed.
That example is deliberately small enough to check by hand. I would use a similarly transparent sample to test a pricing sheet before letting it estimate a large programme. A formula that cannot reproduce a simple request profile should not be trusted because its annual total looks precise.
The record should explain the time basis as well. Is this the rate effective when the work ran, or today’s rate applied to last month’s usage? Both calculations can answer useful questions. They should have different labels.
Preserve the estimate you actually approved
For a hypothetical document workflow, I would save the model identifier, rate source, effective date, input and output assumptions, and the relevant service conditions with the estimate. Then retain the observed usage and invoice evidence separately when the workflow runs.
If the price changes, create a revised estimate rather than overwrite the old one. The difference can then be explained: the workload changed, the rate changed, or both. Without that separation, a lower forecast can look like engineering efficiency even when the application did exactly the same work at a new price.
The reverse matters too. A higher bill after a price cut may reflect longer outputs, more retries or increased volume. The headline percentage does not diagnose the cause. A dated rate record makes it possible to investigate without reconstructing an old website from memory.
This is a proposed accounting discipline, not a claim that I have reconciled a production Luna invoice. Actual billing can include conditions beyond the simple token example, and a stable model alias does not guarantee identical task behaviour over time.
I would also keep this distinct from the service-tier review. That review asks whether the purchased service still meets the application’s timing needs. This record asks whether someone can reproduce the cost calculation and explain why it changed.
Cheap inference is useful. An explainable estimate is what lets a team decide where to use more of it without losing track of what improved.
Store the effective rates, the workload quantities and the source date together; preserve each approved estimate instead of updating its history away.
