What gets an entry here
Only changes you can observe from outside. Everything else is noise that teaches people to stop reading.
AddedA model that became callable, an endpoint that did not exist before, or a capability you can now use. Never urgent: nothing you have already written behaves differently because of it.
ChangedAnything that could alter the behaviour of code you have already written — a rate, a default, a response field, an error status. This is the tag to scan for, and it is deliberately the visually distinct one.
FixedA defect that was observable from outside: a wrong status code, a malformed field, a request that failed when it should not have. If you worked around it, this is where you find out you can stop.
Refactors, infrastructure moves, dependency bumps and copy edits do not appear, however large they were. If a change is invisible from the outside of the API, listing it only makes the entries that do matter harder to find. Entries are dated in UTC, newest first, and the initial release entry is the baseline: anything not described there shipped after it. The same entries are stored once as data rather than as prose, so anything else that needs release notes reads them from the same place instead of keeping a second copy that drifts.
How models and prices are announced
Two of them are machine-readable, so you never have to poll this page.
- A new model appears in the catalogue with its published rate as soon as we intend to carry it, and is marked unavailable until an upstream actually serves it — 7 of the 24 catalogued models are callable today. The entry here is written when it becomes callable, not when it is listed, because the listing is not the thing you can use.
- A rate change reaches you three ways: an entry on this page, a new
prices_updated_at timestamp on GET /v1/models, and the same stamp rendered as a freshness line on the pricing page. Every rate on the site, in that feed and in GET /v1/pricing is generated from one file, so there is no second copy to update late. - Contracted accounts get 30 days’ notice before a rate change affects them — that is a term of an enterprise agreement, not a promise made to every account, and it is worth knowing which of the two you have.
If you want to detect changes programmatically, diff GET /v1/models: it needs no authentication, carries every id, licence, context window and rate, and changes at the same moment the catalogue does. Availability questions, as opposed to releases, are answered live on the status page.