price(models): add gpt-5.6-sol at $5/$30 per MTok (#1360)

[rafaelgiln]

Closes #1360.

What

Adds one row to scripts/lib/model-prices.json:

"gpt-5.6-sol": { "provider": "openai", "inputPerMillion": 5, "outputPerMillion": 30 }

The 2026-08-07 daily (run 31163810520) spent 2,304 tokens over 3 calls on this
model, from agent-structured-output.spec.ts and
agent-context-id-continuity.spec.ts. With no row, the platform's Cost tab
reported the whole run as ≥ $0.04757965 — a floor, not a figure.

Rate verified 2026-08-07 against OpenAI's published pricing
($5.00 / $30.00 per MTok) and cross-checked against an independent aggregator.
The full caveat lives in the entry's _comment (which syncs as the row's
note): this file holds one pair per key, so the batch ($2.50/$15.00) and fast
($10.00/$60.00) tiers cannot be expressed, and the absent cached-input concept
($0.50/MTok) means a cache-heavy run is over-priced here — the opposite
direction from every other approximation downstream, which fails toward a floor.
An aggregator's claimed >272K-input tier at $10/$45 is not encoded, because
OpenAI's own page did not show it.

Two decisions worth reviewing

Flat, no since. buildPricePayload applies FLAT_SINCE = 2026-08-01,
which is earlier than the first run carrying tokens for this model (2026-08-03),
so no recorded run falls before the band. A flat entry carrying since is a
hard error there by design, so the field is absent.

The key is the full id, not a gpt-5.6 family key. resolvePriceKey
short-circuits on an exact match, so the producer resolves and records the
string gpt-5.6-sol — which is exactly what quality-platform's backfill for
today's three rows targets. A shorter family key would make future runs resolve
a different identity and leave those rows orphaned; the migration's EXISTS
guard does not catch that case.

Drive-by: the header comment named the wrong mechanism

The file's top-level _comment said ids absent exactly are matched by
substring in both directions. The code is a prefix match —
longer.startsWith(shorter), scripts/lib/token-cost.mjs:259, whose own
comment says so explicitly. Every conclusion the header drew still holds (the
suffixes it targets are appended, never inserted), but the mechanism it
described is not the one that runs, and a reader reasoning from "substring"
would predict matches that never happen. Corrected in the same commit, with the
old claim noted so the change reads as a correction rather than a rewrite. The
same error exists in quality-platform's migration 20260804220000 header and is
recorded there.

Verification

• npm run test:scripts — 794 pass / 0 fail / 1 skipped (795 tests), which
  covers scripts/sync-model-prices.test.mjs and scripts/lib/token-cost.test.mjs.
• resolvePriceKey("gpt-5.6-sol", prices) → "gpt-5.6-sol" (exact). Neighbours
  unchanged: gpt-5-mini → gpt-5-mini, gpt-4o-2024-08-06 → gpt-4o,
  gpt-5.6 → null, gpt-5.6-solar → null; gpt-5.6-sol-preview →
  gpt-5.6-sol (allowed suffix).
• buildPricePayload emits
  {price_key: "gpt-5.6-sol", since: "2026-08-01", provider: "openai", input_per_million: 5, output_per_million: 30, note: "<the _comment>"}.
• 24 rows, 0 duplicate (price_key, since) pairs — the platform table's PK.
• JSON parses; the entry carries no since.

After merge

sync-model-prices.yml fires on push to main under this path, so the sync is
automatic — dispatch it manually only if the push-triggered run does not appear.
Confirm the band landed:

SELECT price_key, since, provider, input_per_million, output_per_million
  FROM e2e_model_prices WHERE price_key = 'gpt-5.6-sol';
-- expected: 1 row / 2026-08-01 / openai / 5 / 30

Only then does quality-platform's migration 20260807030000 stop being a no-op.
This PR prices FUTURE runs only — the platform freezes price_key at ingest, so
today's three fact rows keep a NULL key until that migration backfills them. No
database change is made from this repo.

🤖 Generated with Claude Code