Skip to content

Bundled jawcode prices for gpt-5.6-terra and gpt-5.6-luna are the pre-price-cut rates #907

Closed
#1031
Closed
Bundled jawcode prices for gpt-5.6-terra and gpt-5.6-luna are the pre-price-cut rates#907
#1031
Labels
bugSomething isn't workingguiDashboard, tray, settings UI

Description

@brunoflma
brunoflma
opened on Aug 2, 2026

Client or integration

OpenCodex dashboard

Area

Dashboard

Summary

The bundled jawcode cost rows for openai/gpt-5.6-terra and openai/gpt-5.6-luna are the pre-price-cut rates. OpenAI has since lowered both, so the ~$ column and /api/usage over-estimate every request on those two models.

Model src/generated/jawcode-model-metadata.ts OpenAI official (2026-08-02)
gpt-5.6-terra { input: 2.5, output: 15, cacheRead: 0.25, cacheWrite: 3.125 } 2 / 12 / 0.20 / 0
gpt-5.6-luna { input: 1, output: 6, cacheRead: 0.1, cacheWrite: 1.25 } 0.20 / 1.20 / 0.02 / 0
gpt-5.6-sol { input: 5, output: 30, cacheRead: 0.5, cacheWrite: 6.25 } 5 / 30 / 0.50 / 0 — input/output/cacheRead match

Sol matching while Terra and Luna do not lines up with the two models having been repriced after the bundle snapshot; Sol was not.

The expected-price overlay cannot correct this, and I do not think it should: resolveMatchedPriceExact() deliberately prefers a non-zero jawcode row over any overlay, which is the right priority. The fix belongs in the source data.

Three separate points, in case they want splitting:

  1. Terra and Luna carry stale input/output/cacheRead rates.
  2. All three gpt-5.6-* rows carry a non-zero cacheWrite. OpenAI's automatic caching has no write charge — the published table has input / cached input / output and no write column. gpt-5.5 and gpt-5.4 in the same bundle correctly carry cacheWrite: 0, so the gpt-5.6 family looks like it picked up the Anthropic 1.25×-input convention by accident (6.25 = 5 × 1.25, 3.125 = 2.5 × 1.25, 1.25 = 1 × 1.25). No impact on my host — I have zero cacheCreationInputTokens on these models — but it would bite anyone whose client sends explicit cache writes.
  3. Unrelated to the stale values but in the same area: none of the gpt-5.6-* rows carries the long-context tier. OpenAI bills prompts above 272k input tokens at 2× input (and cached input) and 1.5× output for the whole request. Cost4 has no way to express that, so requests over the threshold are billed at the short rate. On my 30-day window 391 requests crossed a published threshold. I am happy to open that as its own issue if you would rather keep this one to the data fix.

Reproduction

Read the rows straight out of the bundle — no proxy needed:

bun -e 'import {getJawcodeModelMetadata} from "./src/generated/jawcode-model-metadata";
for (const m of ["gpt-5.6-sol","gpt-5.6-terra","gpt-5.6-luna","gpt-5.5","gpt-5.4"])
  console.log(m, JSON.stringify(getJawcodeModelMetadata("openai", m)?.cost));'

Then compare against https://developers.openai.com/api/docs/pricing.

To see it end to end: send any request through openai/gpt-5.6-luna, then open Logs. The ~$ value is 5× the amount OpenAI actually bills.

Version

2.10.0

Operating system

Windows 11 Home Single Language 10.0.26200

Provider and model

openai / gpt-5.6-terra, openai / gpt-5.6-luna (and gpt-5.6-sol for the cacheWrite point)

Logs or error output

# Bundled rows, 2.10.0
gpt-5.6-sol   {"input":5,"output":30,"cacheRead":0.5,"cacheWrite":6.25}
gpt-5.6-terra {"input":2.5,"output":15,"cacheRead":0.25,"cacheWrite":3.125}
gpt-5.6-luna  {"input":1,"output":6,"cacheRead":0.1,"cacheWrite":1.25}
gpt-5.5       {"input":5,"output":30,"cacheRead":0.5,"cacheWrite":0}
gpt-5.4       {"input":2.5,"output":15,"cacheRead":0.25,"cacheWrite":0}

# Effect on 30 days of my own usage.jsonl, replaying calculateCost() with each rate table.
# Same requests, same normalized tokens; only the Cost4 differs.
gpt-5.6-sol    n=6283  jawcode=$640.16  official=$640.16  delta=$0.00   (0%)
gpt-5.6-terra  n=1104  jawcode=$33.24   official=$26.59   delta=$6.65   (+25%)
gpt-5.6-luna   n=424   jawcode=$4.02    official=$0.80    delta=$3.22   (+400%)

The absolute numbers are small on my host because Sol carries most of my volume and Sol is correct. The percentages are the point — anyone whose workload leans on Luna sees a 5× over-estimate.

Checks

  • I searched existing issues and documentation.
  • I removed secrets, tokens, account details, request credentials, and personal data.

Activity

  1. github-actions commented on Aug 2, 2026

    @github-actions
    github-actionsbot
    on Aug 2, 2026 – with GitHub Actions
    Contributor

    Automated translation bookkeeping — detected language: unknown.

  2. github-actions
    added
    bugSomething isn't working
    guiDashboard, tray, settings UI
    on Aug 2, 2026

  3. brunoflma commented on Aug 2, 2026

    @brunoflma
    brunoflma
    on Aug 2, 2026
    Author

    Filed the long-context tier point separately as #908, since it needs a change to Cost4/resolveMatchedPrice rather than a data fix. The cacheWrite observation stays here — it is the same bundle rows.

  4. lidge-jun commented on Aug 2, 2026

    @lidge-jun
    lidge-jun
    on Aug 2, 2026
    Owner

    Triage: confirmed — the bundled jawcode rows still carry the pre-cut rates (Luna 1/6/0.1/1.25, Terra 2.5/15/0.25/3.125, plus Sol's nonzero cache-write rate) in src/generated/jawcode-model-metadata.ts:49. Not covered by #892; this needs a metadata regeneration against the current price sheet and is queued as a follow-up.

  5. lidge-jun commented on Aug 3, 2026

    @lidge-jun
    lidge-jun
    on Aug 3, 2026
    Owner

    Confirmed still stale on current dev, with one correction to the report.

    The bundle at src/generated/jawcode-model-metadata.ts:47 carries Terra 2.5/15/0.25/3.125 and Luna 1/6/0.1/1.25 — pre-cut rates, as you said.

    The correction: current published rates in input/output/cacheRead/cacheWrite order are Terra 2/12/0.20/2.50, Luna 0.20/1.20/0.02/0.25, Sol 5/30/0.50/6.25. So cache writes are not zero, and a regeneration that zeroed them would introduce a second wrong number in place of the first.

    Why this is not a one-command fix: the generator reads a canonical source, and that source is stale too, so bun run generate:jawcode-metadata alone reproduces the current values. The upstream models.json has to move first, which puts part of the work outside this repository. Left open rather than half-fixed here.

    Thanks for catching it — an overcharge in cost estimates is the kind of thing that goes unnoticed for a long time.

  6. lidge-jun commented on Aug 3, 2026

    @lidge-jun
    lidge-jun
    on Aug 3, 2026
    Owner

    Traced this to its source, and the fix is not in this repository — plus one correction to my own earlier comment.

    Why regeneration does not work. scripts/generate-jawcode-metadata.ts:22-24 reads ../jawcode/packages/ai/src/models.json, and :82-98 copies the four cost fields with no transformation — the generated file is a pure projection. That canonical source carries the same stale numbers, in four separate provider bundles:

    /openai/gpt-5.6-terra         {'input': 2.5, 'output': 15, 'cacheRead': 0.25, 'cacheWrite': 3.125}
/openai-codex/gpt-5.6-terra   {'input': 2.5, ...}
/github-copilot/gpt-5.6-terra {'input': 2.5, ...}
/opencode-zen/gpt-5.6-terra   {'input': 2.5, ...}

    So bun run generate:jawcode-metadata reproduces the defect exactly.

    The overlay is not a way around it either: src/usage/expected-prices.ts:1-11 scopes it to rows that are missing or all-zero, and src/usage/cost.ts:139-145 gives a valid nonzero jawcode row precedence over it. A nonzero-but-wrong row is never reached. And hand-editing the generated file fails tests/jawcode-metadata-sync.test.ts:21-47, which regenerates and byte-compares — that test working correctly.

    The correction to what I said earlier. I gave the current rates from memory. Opening the page confirms the figures but adds something that changes the shape of the fix — there are published long-context rows, which is a separate defect (#908). Retrieved 2026-08-03 from https://developers.openai.com/api/docs/pricing:

    Model input / cachedInput / cacheWrite / output
    gpt-5.6-sol 5.00 / 0.50 / 6.25 / 30.00
    gpt-5.6-terra 2.00 / 0.20 / 2.50 / 12.00
    gpt-5.6-luna 0.20 / 0.02 / 0.25 / 1.20

    Sol's bundled row is already correct. @brunoflma — your cache-write claim is the one part that does not hold: the page publishes a Short context cache writes column with nonzero values for all three. A regeneration that zeroed them would have replaced one wrong number with another, and it would have looked like progress.

    A coupling worth knowing before the fix lands. PRIORITY_MULTIPLIERS (src/usage/expected-prices.ts:152-156) stores Fast pricing as ratios against the base rates — Terra 1.6, Luna 0.4. Those were calibrated against the stale bases. Correcting the bases yields Terra 3.2/19.2 and Luna 0.08/0.48, against published Fast rates of 4/24 and 0.40/2.40. So the same change has to recompute or replace those multipliers, or it will fix an overcharge on standard requests and introduce an undercharge on Fast ones — silently, since the numbers stay syntactically valid and no test fails.

    Disposition. Keeping this open as the tracking issue. The upstream edit is Terra → 2/12/0.2/2.5 and Luna → 0.2/1.2/0.02/0.25 across all four bundles in lidge-jun/jawcode, Sol unchanged. Once that lands, this side is a regeneration plus a table-driven regression pinning the published tuples through resolveMatchedPrice() — the existing sync test proves the bundle matches its source but cannot prove the source matches the vendor, so the next price cut should fail a test instead of quietly overcharging.

    Thanks for the report — an overcharge in cost estimates is worth getting exactly right, including the parts of it that were wrong in both directions.

    Full write-up: devlog/_plan/260803_bug_backlog_stack/050_jawcode_price_blocker.md.

  7. chrisae9
    added a commit that references this issue on Aug 4, 2026

    docs(triage): map the open bug surface and lock the stack order

    0d42ebc
  8. Wibias
    linked a pull request that will close this issuefix(usage): refresh bundled gpt-5.6-terra/luna prices to the post-cut rates (#907) #1031on Aug 4, 2026
  9. lidge-jun
    added a commit that references this issue on Aug 5, 2026

    Merge pull request #1031 from lidge-jun/codex/lane-09-jawcode-prices

    27efe19
  10. chrisae9
    added a commit that references this issue on Aug 5, 2026

    fix(usage): refresh bundled gpt-5.6-terra/luna prices to the post-cut…

    e29508a

  11. lidge-jun commented on Aug 5, 2026

    @lidge-jun
    lidge-jun
    on Aug 5, 2026
    Owner

    Fixed on dev in #1031 (merged as 27efe1940).

    Bundled gpt-5.6-terra and gpt-5.6-luna prices are refreshed to the post-cut rates — Terra 2/12/0.20/2.50 and Luna 0.20/1.20/0.02/0.25 (input/output/cacheRead/cacheWrite), with Fast at 2x — verified against the live OpenAI pricing page. The upstream jawcode metadata is updated on codex/gpt-5.6-price-cut-refresh as well, so the source and the bundled copy agree.

    Not in a release yet. This is on dev, and main is at v2.10.0. It ships in the next release.

  12. lidge-jun
    closed this as completedon Aug 5, 2026
  13. lidge-jun
    added a commit that references this issue on Aug 8, 2026

    chore(metadata): vendor the jawcode models.json snapshot, drop the si…

    e64e6f1
  14. agentHits
    added 4 commits that reference this issue on Sep 17, 2026

    docs(triage): map the open bug surface and lock the stack order

    7a3c7a9

    fix(usage): refresh bundled gpt-5.6-terra/luna prices to the post-cut…

    7d8354e

    Merge pull request lidge-jun#1031 from lidge-jun/codex/lane-09-jawcod…

    6970f05

    chore(metadata): vendor the jawcode models.json snapshot, drop the si…

    c535425
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingguiDashboard, tray, settings UI

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions