On GPT-5.6 (sol and terra, Responses API), usage.output_tokens appears to be a cumulative re-sum of the running reasoning total — re-added once per reasoning item in output[] — rather than the number of tokens actually generated. The inflated value is what appears on the bill.

No earlier model is affected, because every model before 5.6 emits exactly one reasoning item per response, where the defect is a no-op. That’s why this is showing up now.

Measured over 22,922 reasoning calls from my own logs (1,054 of them on 5.6).

Request shape — nothing exotic enabled

I ask the model for a single chess move. No tools, no multi-agent, no pro mode:

{
  "model": "gpt-5.6-terra",
  "input": "<a chess position; instructs the model to reply with only a move>",
  "max_output_tokens": 128000,
  "reasoning": {"effort": "high", "summary": "auto"},
  "background": true,
  "store": true
}

Every response echoes back tools: [], reasoning.mode: "standard", no multi_agent key, and tool_usage with web_search: {num_requests: 0}. Nothing that could legitimately add output tokens is on.

The symptom

Worst example (gpt-5.6-terra, 2026-07-11 03:31:38 UTC):

466,818 output tokens cannot be reconciled with 21,064 reasoning tokens plus a four-character answer.

Secondary bug: the reported output_tokens is 3.6x my requested max_output_tokens while status is completed and incomplete_details is null. Per the reasoning guide, max_output_tokens bounds total generated tokens including reasoning, and blowing through it should surface as status: "incomplete" with incomplete_details.reason: "max_output_tokens". 31 of my 710 5.6 reasoning calls report output_tokens over the cap while claiming completed.

The pattern: a triangular re-sum

Let R = reasoning_tokens, k = number of reasoning items in output[]. The reported value fits a cumulative re-sum — i.e. the running total is re-added at every reasoning item:

output_tokens  ≈  R × (k + 1) / 2

Holds within 5–7% across a 20x range. The residual is consistent with later reasoning segments being larger than earlier ones, so the running total isn’t perfectly linear in k.

Why it’s invisible before 5.6. With k = 1, (k+1)/2 = 1 and the formula returns the correct value. Every pre-5.6 model emits a median of one reasoning item:

5.6 is the first model I’ve seen emit many reasoning items per response, and the inflation tracks that count almost exactly.

It’s billed

Summing the output_tokens the API returned to me, per model, and applying the published output rates reproduces my dashboard line items to the tenth of a cent:

So billing is computed from the defective field. Using reasoning_tokens + visible output as the honest count, real output cost across these calls was ~$36 against ~$320 billed — about 8.9x.

Input accounting, for contrast, looks correct (my terra input bills below the undiscounted rate, consistent with the cached-input discount). The defect appears isolated to output_tokens.

Possibly related

Three older models report output_tokens at a near-constant 2.0x their reasoning_tokens despite a median of one reasoning item — where the triangular formula predicts 1.0x. Different shape, possibly the same class of accounting defect:

My visible output on those calls is also a single chess move (~4 tokens), so a 2x multiple of the reasoning count isn’t explained by emitted text.

Ask

Can OpenAI confirm whether usage.output_tokens on 5.6 is double-counting, and whether billing is being computed from it? Happy to supply response IDs and full stored response bodies to staff.

Anyone else running 5.6 with reasoning: worth comparing usage.output_tokens against usage.output_tokens_details.reasoning_tokens on your own calls. If your response has more than one reasoning item in output[], the ratio should not be ~1.0x — and if it isn’t, you’re likely paying the difference.