Incorrect session cost estimate for models with context tiered pricing

[dpclark4]

Description

Opencode's pricing estimate is incorrect when a model with with tiered context pricing and your session goes into the higher tier. The local cost estimates use the price of smaller context for the entire session, resulting in a cost estimate that is lower than what it should be.

For example, the session that I discovered this showed $3.37 in opencode's UI, but the real price was $3.71. The longer the session, the wider the discrepancy.

Testing with grok 4.6, which has different pricing for > 200k, the model calls reported in Zen differed from what is stored in the local sqlite database.

Plugins

No response

OpenCode version

1.18.18

Steps to reproduce

For testing with Zen:
Use a model that has tiered context pricing, such as grok 4.6 or one of the gpt 5.6 models. Have a session go into the higher tiered pricing. Compare local session pricing vs Zen's UI.

   WITH ranked_calls AS (
     SELECT
       ROW_NUMBER() OVER (ORDER BY time_created, id) AS call_number,
       time_created,
       data
     FROM message
     WHERE session_id = 'ses_ff50d39fbffe2mOJcly5gtxQyW'
       AND json_extract(data, '$.role') = 'assistant'
       AND (
         COALESCE(json_extract(data, '$.tokens.input'), 0) +
         COALESCE(json_extract(data, '$.tokens.cache.read'), 0) +
         COALESCE(json_extract(data, '$.tokens.cache.write'), 0) +
         COALESCE(json_extract(data, '$.tokens.output'), 0) +
         COALESCE(json_extract(data, '$.tokens.reasoning'), 0)
       ) > 0
   )
   SELECT
     call_number,
     strftime('%b %d, %H:%M', time_created / 1000, 'unixepoch', 'localtime') AS date,
     json_extract(data, '$.modelID') AS model,
     COALESCE(json_extract(data, '$.tokens.input'), 0) +
       COALESCE(json_extract(data, '$.tokens.cache.read'), 0) +
       COALESCE(json_extract(data, '$.tokens.cache.write'), 0) AS input,
     printf('$%.4f', COALESCE(json_extract(data, '$.cost'), 0)) AS cost,
     substr('ses_ff50d39fbffe2mOJcly5gtxQyW', -8) AS session
   FROM ranked_calls
   WHERE call_number >= (
     SELECT MAX(call_number) - 9 FROM ranked_calls
   )
   ORDER BY call_number DESC;

Screenshot and/or share link

Zen pricing:

Local sqlite pricing:

Operating System

No response

Terminal

No response

[Zaczero]

The local estimate and Zen are not using the same tier cutoff, and Zen’s cutoff is not the one in the docs.

Go’s published Luna/Grok table is ≤272K / >272K:

https://opencode.ai/docs/go/#usage-limits

Zen still flips on a hardcoded 200 000 of input + cacheRead + cacheWrite5m + cacheWrite1h:

opencode/packages/console/app/src/routes/zen/util/handler.ts

Lines 1035 to 1039 in 9e22c40

	const modelCost =
	modelInfo.cost200K &&
	inputTokens + (cacheReadTokens ?? 0) + (cacheWrite5mTokens ?? 0) + (cacheWrite1hTokens ?? 0) > 200_000
	? modelInfo.cost200K
	: modelInfo.cost

On GPT-5.6 Luna the Usage History “Input” column is that same sum (usage-section.tsx), and inputTokens and cacheWrite5mTokens differ by 3 on almost every row — they are the same uncached tokens counted twice. So the 200k trip is really ~100k of actual prompt plus a write duplicate.

A 302-request Luna burst on 2026-08-18 classified cleanly: every request with that sum ≤193k billed at the low tier, every request ≥202k billed at the high tier. 94 requests sat in 200–272k and paid the high rate. Versus the documented 272k rule that is +$2.53 on one afternoon.

That is the same class of “UI used the cheap tier, invoice used the expensive one” as the $3.37 vs $3.71 in this report. The one-line fix is to stop using 200_000 and read cost.tiers[0].tier.size (272 000 for Luna / Grok / the GPT-5.6 family), and to decide the tier on input + cacheRead — not on input+read+write.

[xyzs996]

Three things I can add, one of which is a second bug on the local side that is the mirror image of the one reported here — it charges too much, in a band nobody has looked at yet.

1. The deprecated 200k field silently overrides the real threshold

opencode/packages/opencode/src/session/session.ts

Lines 380 to 386 in 3a31c4e

	const costInfo =
	input.model.cost?.tiers
	?.filter((item) => item.tier.type === "context" && contextTokens > item.tier.size)
	.sort((a, b) => b.tier.size - a.tier.size)[0] ??
	(input.model.cost?.experimentalOver200K && contextTokens > 200_000
	? input.model.cost.experimentalOver200K
	: input.model.cost)

The ?? fires whenever the tier filter comes back empty — and the filter is empty precisely when the request is below the real threshold. So control then falls to experimentalOver200K && contextTokens > 200_000, which is a different, hardcoded number.

That matters for any model that carries both fields, and models.dev gives gpt-5.6 and gpt-5.6-luna a tiers entry at 272 000 and a context_over_200k block. Running that expression against the real models.dev payload for gpt-5.6-luna:

context tokens	costInfo.input	documented
199 000	$0.20/M	$0.20/M
200 001	$0.40/M	$0.20/M ❌
250 000	$0.40/M	$0.20/M ❌
271 999	$0.40/M	$0.20/M ❌
272 001	$0.40/M	$0.40/M

Every Luna request between 200 001 and 272 000 tokens is estimated at 2× the documented rate, and the same holds for gpt-5.6 ($5 → $10/M). This is the exact band @Zaczero measured 94 requests sitting in on Zen — so in that band the local estimate and Zen are wrong in the same direction, for two unrelated reasons.

The fix is not to touch the constant but to stop reaching the fallback at all when tiers is present: fall back only when cost.tiers is absent or empty, not when it is present-but-unmatched.

2. The threshold is 200k for Grok and 272k for the GPT-5.6 family — not one number

the one-line fix is to stop using 200_000 and read cost.tiers[0].tier.size (272 000 for Luna / Grok / the GPT-5.6 family)

The first half is right; the parenthetical is a trap. models.dev has xai/grok-4.6 and xai/grok-4.5 at tier.size: 200000, and xAI's own models page splits every Grok row at < 200k / ≥ 200k prompt tokens. 272 000 is the OpenAI number. @dpclark4's report is a grok-4.6 session, so it is a 200k model, and @Zaczero's 302-request burst is Luna, a 272k model — two different thresholds in the same thread, which is the strongest argument there is for reading the field rather than substituting a new constant for the old one.

3. > versus >= at the threshold is vendor-specific, and the schema cannot express it

Line 382 uses strictly-greater for every provider. Vendors do not agree about the token at the line, and it is not a rounding question — they say opposite things in prose:

• xAI — "requests whose prompt reaches the listed token threshold are billed at the higher rate for all tokens in the request" (docs.x.ai/docs/models, read 2026-08-22). Exactly 200 000 → high tier. > undercharges here.
• Google — "$2.00, prompts <= 200k tokens $4.00, prompts > 200k tokens" (Gemini API pricing, read 2026-08-22). Exactly 200 000 → low tier. > is correct here.
• OpenAI — only a row label, gpt-5.5 (<272K context length), never stated in prose (pricing). Inclusive by the label, but inferred rather than quoted.

Same number, opposite answer, at the two vendors that share 200k. One token, so it is worth far less than #1 — but there is no field in models.dev's tier object to record it, so no consumer of that data can be right for both vendors no matter what operator it picks. I've written the boundary semantics up per vendor with the quotes here: https://xyzs996.github.io/llm-api-pricing/prices.html#same-number-opposite-answer — and filed the same question upstream at pydantic/genai-prices#587, which has the identical >-for-everyone comparison.

Happy to send a PR for #1 if that shape of fix is welcome.

[xyzs996]

PR for #1 is up: #44223.

While writing it I checked the whole models.dev catalog rather than just Luna, and the case is stronger than I put it above. context_over_200k is not a second, cheaper threshold — it is the lowest context tier under an older name:

• 361 models carry both tiers and context_over_200k
• in all 361, its prices equal the lowest context tier's exactly
• 0 models carry it without tiers

So the fallback is only ever reached below the real threshold, where the base price is the right answer. 252 tier entries sit at a threshold other than 200k (137 at 272k, 56 at 256k, 31 at 128k, 20 at 32k, 6 at 512k, 2 at 262144), and each has the same overcharged band.

One correction to my own comment: this does not touch @dpclark4's grok-4.6 case, since Grok's real threshold is 200k, so the fallback and the tier agree there. The $3.37 vs $3.71 gap is still the Zen side @Zaczero traced.

[xyzs996]

@Zaczero — your inference from the data is right, and the cause is one line in the Zen OpenAI helper. It also turns out to be two bugs, not one: the second is a straight double-charge on Zen's billing path that nobody has looked at.

The line

https://github.com/anomalyco/opencode/blob/main/packages/console/app/src/routes/zen/util/provider/openai.ts#L47-L61

normalizeUsage: (usage: Usage) => {
  const inputTokens = usage.input_tokens ?? 0
  const cacheReadTokens = usage.input_tokens_details?.cached_tokens ?? undefined
  const cacheWriteTokens = usage.input_tokens_details?.cache_write_tokens ?? undefined
  return {
    inputTokens: inputTokens - (cacheReadTokens ?? 0),   // <-- writes never subtracted
    ...
    cacheWrite5mTokens: cacheWriteTokens,

cached_tokens is subtracted; cache_write_tokens is not. OpenAI's docs say both are subsets of input_tokens, with arithmetic rather than prose — the GPT-5.6 sample in "Measure cache reads and writes":

usage.input_tokens = 2600
usage.input_tokens_details.cached_tokens = 2000
usage.input_tokens_details.cache_write_tokens = 400

In this example, 2,000 tokens were read from the cache and 400 additional tokens were written.
The remaining 200 input tokens were neither read nor written.

2,000 + 400 + 200 = 2,600 (https://developers.openai.com/api/docs/guides/prompt-caching, read 2026-08-22). So the disjoint non-cached count is input_tokens - cached_tokens - cache_write_tokens, and the helper leaves the writes in.

The local side of this same repo already does it correctly — session.ts subtracts both, with a comment saying exactly why:

https://github.com/anomalyco/opencode/blob/main/packages/opencode/src/session/session.ts#L360-L363

Bug 1 — the threshold, which is what you measured

handler.ts:1056 sums inputTokens + cacheRead + cacheWrite5m + cacheWrite1h. Substituting: (input_tokens − cached) + cached + written = input_tokens + written. The sum overshoots the real prompt by exactly cache_write_tokens, every request.

That's your "differ by 3 on almost every row": when nearly all fresh input gets written to cache, inputTokens (normalised) = written + neither, so it sits within neither of cacheWrite5mTokens — 3 tokens on those rows. And it explains the size of the effect: on a well-cached turn written ≈ inputTokens, so the sum runs ~2× the prompt and the 200k gate trips at ~100k of real context, which is the "~100k of actual prompt plus a write duplicate" you described. On OpenAI's own sample the sum gives 3,000 for a 2,600-token prompt.

Fixing the helper makes the sum correct and leaves the four buckets genuinely disjoint, which is what handler.ts assumes. Anthropic's helper needs no change and must not get one — Anthropic's input_tokens genuinely excludes both cache buckets, so summing there is already right. That asymmetry is exactly why the fix belongs in the OpenAI helper rather than in calculateCost.

Bug 2 — the same tokens are billed twice

handler.ts:1060 and :1067-1070:

const inputCost = modelCost.input * inputTokens * 100
...
return modelCost.cacheWrite5m * cacheWrite5mTokens * 100

Because the written tokens are still inside inputTokens, they are charged at the input rate and again at the cache-write rate. OpenAI rules that out in the same guide:

Tokens written to the cache are billed at 1.25× the uncached input token rate.
It is not an additional charge on top of another full input-token charge.

On gpt-5.6-luna ($0.20/M input) a written token should cost $0.25/M; Zen bills it $0.20 + $0.25 = $0.45/M, 1.8×. This is unrelated to the tier and applies to every cached OpenAI request through Zen, including ones nowhere near any threshold — so it's a plausible part of the residual $3.37 vs $3.71 gap in the original report even after the tier is fixed. The one-line helper fix closes both.

On the cutoff number itself

Agreed on reading the real threshold instead of the hardcoded 200_000. Two things worth pinning while it's being changed:

• OpenAI documents the 272k tier as "prompts with >272K input tokens are priced at 2x input and 1.5x output for the full session" (https://developers.openai.com/api/docs/models/gpt-5.4, read 2026-08-22) — so > is right there, and a prompt of exactly 272,000 stays cheap.
• But it can't become a house rule: xAI documents "requests whose prompt reaches the listed token threshold are billed at the higher rate for all tokens in the request" (https://docs.x.ai/docs/models, read 2026-08-22), i.e. exactly 200,000 bills high for Grok. Google (prompts <= 200k / > 200k) and MiniMax (≤ 512k / > 512k) follow OpenAI's convention. So whichever operator gets hardcoded is wrong for one of the four; the side wants to live on the tier entry. I raised the same point on fix(opencode): apply long context config pricing #42919, where the new test currently pins estimate(200_000) to Grok's base rate.

Cross-vendor table with each row carrying the sentence it came from, if useful: https://xyzs996.github.io/llm-api-pricing/prices.html#same-number-opposite-answer.

Happy to send the openai.ts one-liner plus a normaliser test asserting 2600/2000/400 → inputTokens: 200 as a separate PR — it's independent of #44223, which is the local-side experimentalOver200K fallback.