A growing share of models don't have a price. They have one below 200k prompt tokens and another above it, or one during peak hours and another off-peak. Every published price table I could find prints one number per row anyway, and the gap is usually a factor of two.

What a coding-agent model costs, next to how it ranks — 60 ranked models, regenerated from the source catalog, with the parts other tables drop:

• 12 of the 60 cost more than the price printed in their own row, and the trigger is prompt length. It's a cliff, not a tier: one token over the line roughly doubles the bill.
• The bigger the advertised context window, the smaller the share of it the advertised price covers. grok-4.20 advertises 2 000k of context at $1.25/M and steps to $2.50 at 200k, so 90% of that window bills at a number that isn't in the row.
• List price is not the bill. A coding agent re-reads its context every step, so ~95.6% of the tokens it sends are cache reads. Repriced at that mix, list input price overstates what an agent pays by a median 6.5x — and the 3.4x–7.9x spread in that multiple is what actually separates two models whose list prices look identical.

Every claim on that page says where its number came from and on what date, and the weights ship in the JSON so you can recompute with your own token mix. Table, data and generator are in llm-api-pricing; if a number looks wrong, an issue there is the fastest way to get it changed.

Put your own token counts in — one HTML file, nothing to install, no account. It reads the same JSON as the table above, so it is never a day behind it, and it does the three things a rate card structurally cannot:

• Peak/off-peak resolved live. DeepSeek's weekend rule changed on 2026-08-23: off-peak all weekend, at half price (which hours, and why every summary I could find gets it wrong). The page says which phase you are in right now, what the same call costs in the other one, and how long until it flips. The Beijing weekend runs Fri 16:00 → Sun 16:00 UTC, and both official peak windows sit clear of that seam — so a getUTCDay() implementation returns identical prices for all 168 hours of a week and no test written against the published windows can tell.
• The long-context cliff. One token past a threshold reprices every token in the request, including the ones below it. At gemini-3.1-pro-preview's 200 000 line, one extra token takes the same call from $0.2060 to $0.4090.
• Your mix, not the median. The default is a coding agent's ~95.6% cache-read share. Slide it to what your own logs say and the ordering of the cheapest ten changes.

Source and issues: llm-cost-calculator.

The clock cases that trip implementations are published separately as a fixture anyone can depend on — deepseek-peak-hours, plain JSON, no dependency, usable from any language. Seven projects have taken a fix found by running them, and the bundled harness scores nine published DeepSeek billing plugins against the same vectors: on 2026-08-23, two passed.

The table is the artifact; these are the arguments behind it. Each one leads with a figure you can check, and each is posted as a thread with a reply box — if a number is wrong, that is the place to say so.

All 53 are indexed at the writing list, rendered from the same repo as the table.

Where the same defect exists in a public catalog, it goes back as a PR — or, where I cannot sign the project's CLA, as an issue with the worked example attached — rather than staying a footnote on my page.

Landed, all the same defect — the weekday is read off the raw UTC instant, so the Beijing weekend is billed at 2x for eight hours at each end:

And one that isn't the weekday defect: dsh-meter#10 — DeepSeek's vision variant has no flat-price history, so a feed builder that assumes one falls back to the wrong model and reports 3x.

A different one closed with the field retired rather than the patch taken: models.dev#5277 argued that context_over_200k reads as a flat 200K threshold while 193 of the 357 entries carrying it use a different one. It was closed as superseded by #5335, which marks the field deprecated in the SDK types and points consumers at tiers for the real threshold. Same outcome from the consumer's side — the number that lied is no longer the one you're told to read.

Open right now:

Same rule: single purpose, regenerated automatically, every number says where it came from.

Corrections are welcome on any of them — open an issue on the repo in question. If you maintain a pricing catalog and want the numbers above as a diff against your format, say so on the repo and I'll send one.