GPT-5.6: correct every rate from the model cards, curate the models (PR-3), and fix the tool that missed them

[philmerrell]

Three things, one thread

1. Every dev GPT-5.6 rate was wrong — all over-charging by exactly 20%. Corrected in the dev catalog 2026-09-06T15:59Z.
2. PR-3 is now shipped — the three models are curated and one-click-creatable.
3. The tool that missed the rates is fixed — it had a 1000× unit bug and a filter that could never match.

---

1. The rates

The published rates were in AWS's model cards the whole time (Sol, Terra, Luna, GPT-5.4).

model	field	was	now
sol	output	26.40	22.00
terra	input / output / cache read / cache write	2.64 / 15.84 / 0.264 / 3.30	2.20 / 13.20 / 0.22 / 2.75
luna	input / output / cache read / cache write	0.264 / 1.584 / 0.0264 / 0.33	0.22 / 1.32 / 0.022 / 0.275

The 1.2× is not coincidence: Terra and Luna had been sourced wholesale from the GovCloud Price List rows, which are exactly 1.2× commercial. Sol's output was the one figure with no source at all — a 6× input ratio inferred from GovCloud, where the real ratio is 5×.

My error, plainly: I concluded these rates existed in no source and had to be derived empirically. The search ran against pricing APIs — Price List, then Marketplace Catalog — and stopped there. Absence from an API is not absence from the docs. The spec now carries that as a standing note: check the model card first. It is where AWS documents rates, caching support, context windows, service tiers and endpoint support together.

2. PR-3 — the models are curated

CURATED_BEDROCK_RESPONSES_MODELS behind a new Bedrock Responses catalog tab. Two values are pinned by test because they are pricing correctness, not preference:

• supportsCaching: true — these cache implicitly server-side with no way to turn it off, so false is a false statement whose only effect is to clear the cache-rate fields, pricing cached tokens at $0.00 while AWS bills them in full.
• maxInputTokens: 272_000 — the models have a 1M window, but AWS prices them on two cards: above 272K, input costs 2× and output 1.5×. A CuratedModel holds one flat rate per bucket, so this cap is what keeps that single rate honest. Raising it silently opens the second price card.

Also fixes a live bug in the curated openai.gpt-5.4 Mantle entry. It inherited mantleDefaults()' supportsCaching: false, so one-click-creating it produced exactly the mis-priced row that had to be repaired by hand in prod last night. Its card publishes cache read at 0.1× input and an em dash for cache write, so caching is on with a literal 0 write rate — 0 is correct rather than missing, because it makes compute_wasted_usd see a non-positive premium and return $0 instead of inventing waste. The mantleDefaults() comment claiming Bedrock caching is model-bound to Claude+Nova was simply wrong, and is corrected.

claudeRates → ratesWithDerivedCache: the 1.25×/0.1× multipliers aren't Claude-specific. The GPT-5.6 cards publish the same two, and commercial Cost Explorer billing reproduces them to four decimals — two model families, two independent sources.

supportedParams is deliberately omitted. AWS publishes no parameter table for GPT-5.6, and a declared spec flips the #915 guard from permissive to restrictive — so a guessed one would silently block parameters the model accepts. Better none than a guess.

This also resolves PR-3's modelling gap

• Service tiers don't apply. Every card: "Priority and Flex tiers are not supported for this model."
• Long context is real, and the spec's "2× twin" was wrong — past 272K input is 2× but output only 1.5×. A flat 2× would have over-priced long-context output by a third.
• We don't reach it — the 272K cap plus compaction at 100K.

For prod: global.openai.gpt-5.6-* prices 9.1% below the us.* rates across every bucket, and prod already runs Claude on global.*. The prod rows should not be copies of dev's.

3. The tooling

Now the audit of the published numbers rather than the source, and only trustworthy because it's fixed. --rates-only had three defects, all found by running it:

1. A filter that could never match — it searched usage types for gpt-5.6, but no usage type contains a model id. It matched nothing and printed "Cost Explorer lags ~24h, try tomorrow".
2. A 1000× error — it assumed 1K-token units; Marketplace rows bill in 1M tokens, and Cost Explorer declares the unit in its own Unit field.
3. Monthly granularity — daily rows are exact round numbers; a multi-day window blends models into an average that looks like a rate.

Marketplace usage types carry the bucket and tier but never the model, so a rate is only attributable on a single-model day; --table now reconciles against sessions-metadata and refuses to vouch otherwise. That guard exists because I nearly shipped the mistake it prevents: a first read gave a cache-read rate matching gpt-5.4's 0.1× to four decimals, and a reconcile then showed zero GPT calls in that window.

Also closed

google.gemma-4-31b's supportsCaching: false is correct — across 2026-06-01..09-06 and 455K input tokens it has only ever produced input and output usage types, never a cache SKU.

Testing

• Backend: 7,458 passed, 3 skipped.
• Frontend: 2,477 passed (220 files). A first run showed one unrelated sidenav.spec.ts failure; an identical-code re-run was fully green, consistent with the repo's known cross-file flake.
• The rewritten Cost Explorer reader was validated against a window whose ground truth was already known, and both probe arms ran live against us.openai.gpt-5.6-sol.
• Corrected dev catalog rows verified by reading them back.

Not browser-verified: the catalog is admin-gated against the dev backend, so an unmerged frontend change can't be signed in to. Layout risk is low (the tab strip is flex-wrap, the card grid unchanged), but the visual check is worth doing on dev after merge.

🤖 Generated with Claude Code