TL;DR (updated September 2026): If your product turns tokens into dollars - a cost dashboard, a rebilling engine, an internal budget report - there is a pricing table somewhere in your code, and it is probably already wrong. Frontier prices move, models get retired, and even announced effective-dated changes can be reversed: Anthropic canceled Sonnet 5's planned September 1 increase and kept $2/$10 as the standard rate. PostHog ships an automated PR every time provider prices change, with a human checklist to verify against the official pages - that is the tell: the price list is production code, not config you set once. The fix is to treat it like production code (versioned, effective-dated, provenance-tracked), never hardcode a rate inline, and reconcile computed cost against the real provider invoice so drift surfaces as a number instead of a surprise.
Every team that displays or bills AI cost builds the same small thing early: a map from model name to input and output price. It feels like configuration - set it once, move on. In 2026 it behaves like a dependency that ships breaking changes on the vendor's schedule, not yours. The map that was correct in June is wrong in July, and nothing in your code will tell you, because a wrong constant does not throw - it just quietly reports the wrong dollar amount to a customer or a finance team.
Four ways the table goes stale
- Silent price changes. Providers reprice input and output rates with a blog post, not a webhook. Your table keeps computing with last quarter's number until someone notices the finance report does not match the invoice.
- Announced changes can be canceled. Sonnet 5's $2/$10 launch rate was originally scheduled to become $3/$15 on September 1, then Anthropic made $2/$10 the standard price instead. A rate system therefore needs effective-dated rows that can be superseded before they activate - see the September pricing update.
- New tiers and renames. A new family lands (GPT-5.6 in July) and your code either does not know it, prices it as the wrong sibling, or crashes on an unknown model id. Renames and aliases quietly point traffic at a row that does not exist.
- Retirements and credit conversions. Models get deprecated, and "credits" add a layer where the token-to-credit rate is vendor-controlled per model - so the same token count can cost different amounts as the conversion moves, even when the token price does not.
Any one of these turns a "known" cost into a wrong one. The dangerous property is that it fails soft: no error, no alert, just a number that is confidently incorrect.
Treat the price list like production code
PostHog's approach - an automated PR on every provider price change, reviewed against the official pricing pages before merge - is the pattern worth copying, because it encodes the right assumption: prices change often enough that a human should be in the loop but a manual process will fall behind. Concretely:
- Version it and effective-date every rate. A price is not "the price," it is "the price from date X to date Y." That is the only way to compute historical cost correctly - and to cancel a future row cleanly when a provider reverses an announced change, as Anthropic did with Sonnet 5.
- Never inline a rate. A magic number multiplied by a token count buried in a function is the hardest kind of stale to find. One source of truth, referenced everywhere.
- Track provenance. Record where each number came from and when it was last verified, so "is this current?" is a lookup, not an archaeology project.
- Fail loud on unknown models. An unrecognized model id should raise, not silently price as $0 or the wrong sibling - a zero-cost row is how a whole workload disappears from a budget report.
The number that actually protects you: reconciliation
Versioning the table reduces drift; it does not prove you are current. The only thing that does is reconciling your computed cost against the provider's actual invoice. If your meter says $4,120 and the bill says $4,600, the delta is your drift - a stale rate, a missed tier, a retry storm, or a credit-conversion change - and it is now a number you can chase instead of a surprise you absorb. This is the same reconciliation discipline behind why usage metering needs its own event store: the meter and the invoice must be comparable, or "our AI cost" is just a hopeful estimate. A pricing table you never reconcile is a pricing table you cannot trust, however carefully you version it.
The honest take
The LLM pricing table is the least glamorous part of any AI cost system and the one most likely to be silently wrong, because it looks like set-and-forget config and behaves like a dependency that ships breaking changes monthly. Version it, effective-date it, stop inlining rates, fail loud on unknown models, and - above all - reconcile computed cost against the real invoice so drift shows up as a delta. The teams that get AI cost right are not the ones with the cleverest dashboard; they are the ones whose price list is production code and whose meter is checked against the bill.