What a Model Catalog Row Never Tells You About Price

A model catalog row looks like a fact: a slug, a context window, a price per million tokens, a listed date. Treat it as one and it can quietly mis-state all four. The price may be a time-boxed promotion. The rate may belong to one buying surface and not another. The date may record when a marketplace updated its database, not when the vendor shipped anything. And the vendor may have already told you, in writing, that the number is provisional.

This matters because catalog rows are where cost models start. Teams screenshot an aggregator page, drop the numbers into a spreadsheet, and project a quarter of spend from figures that were never load-bearing to begin with. In a single August 2026 window, we verified four separate cases — one per failure mode — where the row and the reality had already diverged.

This guide works through each case with the primary sources attached: a promotional rate being served as if it were list, a vendor family split across two pricing bases on one catalog page, listing dates that ran from ahead of the vendor’s own blog to roughly six months behind it, and a pricing page that warns its own numbers are expected to rise — with no date, no percentage, and no scheme.

A catalog row — on OpenRouter, on a vendor console, on any third-party price aggregator — is a snapshot of one surface at one moment, rendered without its qualifiers. The qualifiers are the price: whether the number is promotional or standing, which surface it bills on, when the record was written, and whether the vendor has flagged it as temporary. Strip those away and two teams reading the same row can build cost models that differ by an order of magnitude, both citing the same screenshot.

To be precise about what this piece is: it is a planning-risk guide, not a price tracker. For the running ledger of this month’s cuts and promotions, see our August 2026 pricing tracker; for what the newly cheap tier unlocks economically, the sub-$0.30 tier repricing analysis; for reference rates across the major vendors, the LLM API pricing index; and for what actually shipped versus what was merely announced this month, the August 2026 model releases tracker. Those pieces carry the numbers. This one carries the reading skill that stops the numbers from misleading you.

Upstage launched Solar Pro 4 on or around August 10–11, 2026, with a 512K context window and a launch discount the vendor states plainly: 90% off — off the Upstage Console standard list of $0.30 per million input tokens, $0.06 per million cached input, and $1.20 per million output. The promotional rate is $0.03 input / $0.12 output, it applies on Upstage Console and OpenRouter, and it runs through September 10, 2026 at 23:59 UTC. That expiry is a hard cliff, not a taper: the day after, the same workload bills at 10× the rate on both input and output.

Here is the part that makes this a catalog-literacy problem rather than a footnote-reading problem. We pulled OpenRouter’s raw model JSON directly and confirmed that upstage/solar-pro4 is listed at $0.03 / $0.12 per million — the promotional rate, served as the row’s price with no promo qualifier attached. And per our earlier verification pass, several third-party price aggregators were already carrying that promotional figure as Upstage’s standing price. The number is not wrong. It is real, live, and it is what the surface bills at the time of writing. It is simply a snapshot of a time-boxed promotion, presented with the same typography as a list price.

Play that forward. A team at example.com scopes a document-heavy workload against the catalog row in late August, budgets the quarter, and ships in October. Every unit economic in the plan is 10× optimistic by the time traffic arrives — not because anyone lied, but because a promotional rate crossed into a spreadsheet without its expiry date. The discount is only half the fact; the denominator and the cliff are the other half. Never carry a discounted figure into a plan without the list price it discounts and the date it reverts.

The comfortable assumption is that an aggregator like OpenRouter simply mirrors vendor pricing. Sometimes it does. We cross-checked OpenAI’s pricing documentation and other vendors’ published lists against OpenRouter’s raw model JSON, parsed directly rather than read off a rendered page. For Grok 4.6, Claude Opus 5, Claude Fable 5 and GPT-5.6 Sol, the OpenRouter row matches the vendor’s standard list exactly. For GPT-5.6 Terra and GPT-5.6 Luna — two siblings from the same vendor family, on the same catalog page — it does not.

We can state the observation with confidence; the mechanism is the aggregator’s to explain. Terra and Luna’s OpenRouter rates land exactly on the figures OpenAI documents for its batch tier — which OpenAI prices at 50% off the standard list for all three siblings — while Sol’s OpenRouter rate matches the standard tier. Nothing on the catalog page flags that two rows sit on one pricing basis and the third on another. The lesson is not “OpenRouter is wrong” — every one of those numbers is what the surface actually bills. The lesson is that divergence is asymmetric per model: checking Sol tells you nothing about Terra, and checking Terra tells you nothing about Luna. A spot-check does not generalise, even inside one vendor family.

The vendor’s own surface can hide structure too, in the opposite direction. ByteDance prices doubao-seed-2.0-code on Volcano Engine in CNY, tiered by input length — longer prompts bill at progressively higher per-token rates. OpenRouter lists the same model (bytedance-seed/seed-2.0-code) at a single flat $0.50 / $3.00 per million. The flat row and the tiered schedule cannot be declared cheaper or pricier than each other in general: which surface wins depends on how long your prompts run, and the single-number row gives you no way to tell which regime your workload is in. A catalog row flattens pricing structure by design; the structure is where the money is.

A subtler trap: a slug existing in a catalog — with a price attached — is not proof the vendor recognises it as a product. OpenRouter’s raw model list carries three gpt-5.6-*-pro rows — one apiece for the Sol, Terra and Luna tiers — each with a :batch sibling and each with its own listed price. Follow one back to the source and it dissolves: the corresponding model page on OpenAI’s developer docs returns an HTTP 404. OpenAI’s pricing documentation describes Pro as a reasoning.mode request parameter on an existing model — a setting, not a model. The catalog has minted a distinct product row, with distinct pricing, for something the vendor ships as a request-time flag.

The same catalog can also carry two prices for one genuine model. NVIDIA’s Nemotron 3.5 Lightning — covered in our launch analysis of the efficiency tier — lists on OpenRouter at $0.10 / $0.25 per million via the CoreWeave route and $0.05 / $0.20 via DeepInfra. Neither is “the OpenRouter price.” A quote that says “Nemotron costs $0.10 on OpenRouter” and one that says “$0.05” are both right and both incomplete — the price belongs to the provider route, and any citation that drops the route is under-specified by exactly 2× on input.

Every OpenRouter row carries a created timestamp, and it is routinely read as a launch date. It is not one. It answers “when did this catalog’s record change,” and the gap between that and the vendor’s actual ship date is neither small, nor constant, nor even reliably in one direction. We converted the raw timestamps ourselves and checked them against the vendor’s primary announcements where we could locate one — for ByteDance, against the Seed team’s own blog. Five listings from the same catalog, all live in the same August window:

Two rows deserve a closer look. Meta’s Muse Glimmer 30B — the open-weights local-agent model we covered in our Muse Glimmer analysis — appears on OpenRouter dated before the date on Meta’s own announcement blog. So the catalog does not merely lag; it can lead, which breaks the one heuristic (“the vendor announced it first”) that a careful reader might have relied on.

The strongest evidence, though, is what happened with seed-2-1-turbo. Between two pulls of the same OpenRouter endpoint, hours apart, that model’s created field moved — from August 10 to August 12, 2026. Same catalog, same model ID, same field, two different answers in one day. Whatever internal re-indexing explains it, the practical conclusion is stark: the catalog’s own date field is not a stable historical record. It cannot be cited as one, archived as one, or used to settle a “when did this ship” dispute. For ship dates, only the vendor’s dated primary counts.

The fourth thing a catalog row cannot show you is a footnote on the vendor’s pricing page. DeepSeek’s API pricing page currently lists deepseek-v4-pro at $0.435 per million input tokens on a cache miss and $0.87 per million output — vendor list rates that, per our own earlier snapshot checks, have not moved in weeks. Beneath that table sits this notice, quoted verbatim:

Read it as a contract term and notice what is missing: no effective date, no percentage, no named scheme, no affected model list. “Significant” is the only sizing word the vendor offers, and we will not speculate past it — DeepSeek gave no number, so no forecast belongs in a plan. This is not an announced price change; it is a standing disclaimer that the entire table above it is provisional. A team building a 12-month cost model on those rates has no primary-source way to bound the risk: the vendor has explicitly said the number will move, and explicitly declined to say when or by how much.

The surrounding signals make the picture stranger, not clearer. DeepSeek’s own homepage banner says the V4-Pro version “remains unchanged for now.” The pricing page’s model-version field reads DeepSeek-V4-Pro-0813 — a dated version string — while the vendor’s own Hugging Face card still describes the whole V4 series as “a preview version.” Two vendor surfaces, two maturity signals, one model family — and a price-increase warning underneath both. Our companion piece, published alongside this one, unpacks the 0813 version-string sighting in full. The footnote also predates the version-string edit — it is a separate, earlier change, which is exactly why footnotes deserve their own diff-watch: they move independently of the table.

The four cases reduce to four questions. Ask them of every catalog row before it enters a budget, and record the answers with the same discipline you would apply to an FX rate: sourced, dated, and labelled by surface.

Step back and the pattern has a structural cause worth naming: a catalog is a routing layer, not a procurement document. Its job is to make a model callable through one API — which it does well — and every field beyond the endpoint is metadata maintained on a best-effort basis. Promotions get cached because rows show what the route bills now; pricing bases mix because the row records whatever rate the listing was configured with; dates wobble because they are database fields, not archival records. None of this is deception. It is what happens when an operational surface gets read as a reference surface.

Looking forward, expect the divergence to widen rather than close. More launches now debut with time-boxed promotional rates, more vendors run multi-tier pricing that flattens badly into one-number rows, and aggregators keep adding provider routes — each a new surface with its own rate for the same slug. Teams that treat catalog figures the way finance treats exchange rates — a quoted number, from a named source, on a stated date, with a known revert — will keep their models honest. The same skill applies one shelf over: our companion piece on reading vendor benchmark tables is this argument applied to capability claims, and our AI procurement checklist covers the signing-stage version. If you want this discipline built into your stack’s cost governance — surface-labelled rate cards, promo-cliff calendars, fallback routing — that is exactly the kind of system our AI transformation engagements put in place.