API price change tracker: how to know when a model's price moved

An API price change tracker is a dated record of every rate change a model's provider has published: which model changed, which field (input, output, cached input, cache write or batch), the old value, the new value, the effective date and the official page it came from. It answers the question a budget cannot answer on its own: did the price I am paying today differ from the price I planned for, and if so, by how much on my workload?

What a price change record needs to hold

A useful record is narrower than a pricing page. Each entry should name one model and one field, so a change to the input rate is never mixed up with a change to the output rate. Meterary's own dataset stores each change in the same shape: a model slug, a date, a field name, an old value, a new value, a source URL and an optional note. The old and new values are nullable on purpose. A rate that a provider has never documented, or that has been removed from a model, cannot be written as a number without inventing one.

• The model slug and the provider's own model identifier, so a record can be matched to the exact model your code calls.
• The field that changed, one per record: input per million tokens, output per million tokens, cached input, cache write or batch discount.
• The old value and the new value, in the same unit and currency the provider publishes, usually USD per million tokens.
• The effective date, which can be later than the date the change was announced. Introductory pricing often carries a stated end date.
• The source URL of the provider page the number was read from, and a note when the change is a reversion, a status change or a conditional tier.

A worked example: a dated reversion

Meterary's dataset records a change to Claude Sonnet 5 that shows why the effective date matters. Introductory pricing of $2 per million input tokens and $10 per million output tokens applied from launch through 31 August 2026. From 1 September 2026, the standard rates of $3 and $15 apply, according to Anthropic's pricing page at platform.claude.com/docs/en/docs/about-claude/pricing. That is two records, one for each field, both carrying the same effective date and the same source. Nothing about the model's name or its capability changed. The only thing that moved was the number on the invoice.

The lesson is not that Anthropic changed its pricing. Introductory rates are published with an end date, and a budget built on the introductory rate starts to drift on that date. A tracker that stores only the current rate would show $3 and $15 and say nothing about the reversion. A tracker that stores the dated change shows the whole story.

Turning a change into a cost difference

A price change only matters in proportion to the tokens you send and receive. The monthly cost of one model is the input tokens divided by one million, times the input rate, plus the output tokens divided by one million, times the output rate, summed over the month. Run the arithmetic on both the old and new rates, using a workload you have actually measured, and the change becomes a number you can plan around.

Here is an illustrative workload, not a measured one. Suppose a feature makes 2,000 requests a day, each with 1,500 input tokens and 400 output tokens. Over 30 days that is 90 million input tokens and 24 million output tokens. At the introductory $2 and $10 rates the monthly cost is $420. At the standard $3 and $15 rates it is $630. The difference is $210 a month, a 50 per cent increase, and it arrived without any change in traffic or code. A tracker that records the reversion date lets you see that difference before the first invoice at the new rate, not after.

Use the same token shape for the old and new rates. If you change the prompt length or the output length in the same month as a price change, you cannot tell which one caused the difference on the bill.

Status changes count as price changes

A model moving to legacy or deprecated status is a pricing event even when its rate stays the same. OpenAI's deprecations page defines deprecation as the process of retiring a model or endpoint, and says a model is deprecated as soon as it is announced, with a shutdown date after which it is no longer accessible. It also states that generally available models receive at least six months' notice before retirement, and specialised variants of generally available models receive at least three months. A tracker should store the status field alongside the rate, so a model that is still cheap but no longer updated is flagged rather than quietly kept in a budget.

How to keep the record current

A tracker is only useful if it is checked on a schedule and diffed against the last check. Overwriting a rate in a spreadsheet loses the history that tells you when it changed. The practical approach has four parts, and each one is cheap on its own.

• Track only the models your product calls. A handful of models usually covers most production spend, and a market-wide list adds noise.
• Store a new row for every change rather than editing the old one, with the source URL and the date you checked the page.
• Diff each recheck against the previous one, and treat any difference in rate, status or effective date as a prompt to recalculate the budget.
• Rerun your real token shape through the new rate after each change, and record the monthly figure next to the date, so the trend survives a change of owner.

Meterary publishes its documented changes at the public changes page, newest first, with sources, and the model endpoint at /api/v1/models/[slug] includes the same priceChanges list for a single model. Either route lets you check a change without trusting a memory of the last price you saw. Keep your own copy as well, because the value you need is the one your bill was built on, which may be older than the one a directory shows today.

A tracker tells you what changed in the price list. It does not tell you how your costs will move, because that depends on your prompt length, output length and request volume. Pair it with a cost estimate built from measured usage. The post on how to estimate LLM costs before you build shows the inputs to gather, and the one on why AI API prices keep changing covers the causes of revisions in more detail. If a change touches cached input, the prompt caching cost savings post explains how cache writes and reads change the arithmetic, and the batch API discounts post covers when a discount applies and when it does not.

Frequently asked questions

Is there a free API price change tracker?

Yes. Meterary's changes page lists the documented price changes it tracks for the models in its directory, with sources, and it is publicly readable without an account. For a private record that covers your own models and your own usage, a spreadsheet or a workspace with dated rows is enough, provided each row keeps its source and date.

How often do AI API prices change?

There is no fixed schedule, and this post does not quote a frequency. Changes tend to cluster around new model launches, the expiry of introductory pricing and deprecations. The reliable habit is to recheck on each budget cycle and after you hear of a new model generation from a provider you depend on.

Does a price change take effect immediately?

Not always. Many changes carry an effective date that is later than the date they were announced, and introductory rates often end on a stated day. Store the effective date as its own field, and check it against the provider's pricing page rather than the date you first saw the change.

Does a lower rate always lower my bill?

No. A lower input rate can be offset by a higher output rate, a longer context, a different tokenizer that produces more tokens for the same text, or a switch to a model that needs more calls to finish a task. Compare the monthly cost on your own token shape before you treat a cut as a saving.

Where should I check the official rate?

Use the provider's own pricing page as the source of truth. For Anthropic that is platform.claude.com/docs/en/docs/about-claude/pricing. For OpenAI, check the pricing and deprecations documentation at developers.openai.com. For Google, use ai.google.dev/gemini-api/docs/pricing. Aggregator sites are useful for finding a change, but the number you budget against should come from the provider.