Every free tool on this site that quotes a model price — the cost calculator, the model comparison, the caching-savings estimator — reads the same number from the same place. That place is not a database. It is a set of JSON files checked into the repository, versioned by git like any other source code. This post is about why, because the choice is doing more work than it looks like.
The obvious design, and what it costs#
The obvious way to store model prices is a table: one row per model, a column for input price, a column for output price, updated by a script or an admin form. It is the default, and for a lot of data it is the right default.
For a public number that people spend real money on the strength of, it has two
quiet problems. First, a row in a table has no memory: when the price changes,
the old value is overwritten and gone, so "what did this model cost last month?"
becomes unanswerable without building a separate audit trail. Second, a row has
no provenance by default — nothing about 0.0000025 in a cell tells you where it
came from or when anyone last checked it. Both problems are invisible right up
until someone needs the answer.
The registry#
So the prices live in a model registry: git-versioned JSON where every priced model carries not just its numbers but the context that makes them trustworthy — the source URL the price came from, the date it was last verified, and a verification status. The tools never read a hardcoded table; they read through the registry, and they surface exactly what it knows.
Three things fall out of storing this in git rather than a database:
- History is the archive. Every price change is a commit — a diff, with an
author, a date, and a message. Nothing is overwritten into oblivion; the old
value is one
git logaway. The pricing tracker tool is not backed by a separate history table — it reads that commit history directly, which is why it can show you every cut and hike on record. - Provenance travels with the number. Because the source URL and last-verified date sit in the same record as the price, a tool can always show you where a figure came from and when it was checked — on the same page, next to the number, not buried in an admin panel.
- Review is a pull request. A price change is a code change. It can be
diffed, reviewed, and reverted with the same tools and the same discipline as
the rest of the codebase, instead of a silent
UPDATEnobody sees.
Verified, or nothing#
The registry is also where the honesty rule that runs through this whole site lives structurally. A price is only marked verified when independent public sources agree on it. When there is a single source, or the sources disagree, the entry stays pending — and a pending price is never rendered as a number. It shows up as pending, with a visible badge, because a one-source figure is a lead, not a fact.
Verified prices also age. Past a freshness window, a previously-good number is flagged stale — shown as the number it is, dated, so you can judge whether to trust it, rather than presented as if it were checked this morning. (The reasoning behind these states has its own post.)
None of that requires special machinery. It is a status field on a record in a file, and a set of tools that agree to respect it.
Why a file, and not a service#
There is a version of this that lives behind an API — a pricing service the tools call at runtime. That is a real option, and one day part of it may be. But for a set of read-only tools over data that changes on the order of days, a committed file has properties a live service does not: it builds into the site as static data, it cannot be down, it is diffable, and its entire history is right there in the repository. The same registry backs the public pricing API and MCP server, so an agent and a human read the identical, sourced number.
The prices live in git because git already solved the hard parts — history, review, provenance — and a database would have made us rebuild them.