token usage spike after deploy error prompt change costs triple fails

Not specified by the original author.

TL;DR

For budgets above 32k, use batch processing: long thinking runs hit network timeouts on live requests. Compare thinking\_tokens before and after the change on the same task.

Steps

1. Read usage.output_tokens_details.thinking_tokens on the response. That field reports how many of the billed output tokens were internal reasoning. The budget is a target, not a cap: actual usage varies, and max_tokens is the hard ceiling on total output. A 16k budget on a task the model could solve in 2k of thinking is pure overspend.
2. Start near the 1024-token minimum for simple tasks and raise incrementally; start around 16k only for genuinely complex ones.
3. On adaptive-thinking models, lower effort settings let the model skip thinking entirely on easy inputs.
4. For budgets above 32k, use batch processing: long thinking runs hit network timeouts on live requests.
5. Compare thinking_tokens before and after the change on the same task. Quality holding steady while thinking tokens drop is the win; if quality drops, you found the floor.

When to use

You are seeing this: Costs jump after enabling thinking, well beyond what the visible answer length would suggest. Use this skill when you run into "Anthropic bill is higher than expected with thinking on: reasoning tokens are billed as output tokens".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

Read usage.output\tokens\details.thinking\_tokens on the response.

Thinking tokens billed as output, the thinking_tokens usage field, the budget target-not-cap rule, and the 32k batch guidance are documented on the extended thinking page. Verified live at https://docs.anthropic.com/en/docs/build-with-claude/extended-thinking.

Not specified by the original author.

TL;DR: Your request logs say 2k tokens but the bill says 9k. The gap is tokens you never see: hidden reasoning tokens, image tokens, and cache writes. Confirm the cause Check the usage breakdown on a real response: 1. On reasoning models, usage.outputtokensdetails.reasoning_tokens counts internal thinking: billed as output, never returned in the response.

The fix

TL;DR: Your request logs say 2k tokens but the bill says 9k. The gap is tokens you never see: hidden reasoning tokens, image tokens, and cache writes. Confirm the cause Check the usage breakdown on a real response: 1. On reasoning models, usage.outputtokensdetails.reasoning_tokens counts internal thinking: billed as output, never returned in the response.

The symptom

Billed tokens consistently exceed what your prompt plus visible response suggest. The usage object has fields your logging ignores.

Confirm the cause

Check the usage breakdown on a real response:

1. Hidden reasoning tokens. On reasoning models, usage.output_tokens_details.reasoning_tokens counts internal thinking: billed as output, never returned in the response. A "short" answer can carry thousands of reasoning tokens. This is the biggest surprise on o-series and GPT-5.
2. Image tokens. Vision inputs are tokenized by size and detail level and land in input tokens. A few high-detail images can outweigh a long text prompt.
3. Tool and schema tokens. Tool definitions and structured output schemas count as input tokens on every call.
4. Cache write tokens. On GPT-5.6 and later, prompt_tokens_details.cache_write_tokens reports prompt tokens written to cache, billed at 1.25x the uncached input rate. Cache writes are not free on newer models.
5. Retries and streams. Every retried request rebills its prompt tokens. Every retried stream rebills them too.

The fix

• Log the full usage object, not just prompt and completion totals. Break down reasoningtokens, cachedtokens, and cachewritetokens per call.
• Budget reasoning models with reasoning in mind: lower reasoning_effort when deep thinking is not needed, and size max_completion_tokens for reasoning plus visible output.
• Right-size image detail. low instead of high when the task allows it.
• Fix retry storms and loops first; they multiply every hidden cost above.

Verify the fix

Compare your logged token totals against the billed totals for a day. After the fix they should reconcile within a few percent. Any remaining gap has a named field in the usage object; find it before it finds your budget.

When to use this

• This covers exactly what the title says: OpenAI billed more tokens than your logs show.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with OpenAI; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Mentions 5.6 in the original; behavior may differ on much older or newer releases.

OpenAI's reasoning guide documents reasoningtokens under usage outputtokensdetails: internal reasoning billed as output but never returned. The prompt caching guide documents cachewrite_tokens on GPT-5.6 and later, billed at 1.25x the uncached input rate, and confirms images, tools, and schemas count as input tokens (https://platform.openai.com/docs/guides/reasoning, https://platform.openai.com/docs/guides/prompt-caching).

Not specified by the original author.

TL;DR: An unexplained usage jump is always some code path burning tokens on your behalf. Triage in order: spend-limit scope, then key, then model and endpoint, then the four usual suspects. Attribution first, panic never. Confirm the cause Triage in this order: 1.

The symptom

The bill or usage dashboard jumps with no deploy you can tie to it. Attribution first, panic never.

Confirm the cause

Triage in this order:

1. Spend-limit scope. organization_spend_limit_exceeded 429s mean every project is burning; project_spend_limit_exceeded means the culprit is inside one project. The scope of the trip is the scope of the hunt.
2. Attribute by key. Usage is tracked per API key. Find which key jumped. A leaked key used by someone else looks exactly like a spike; rotate any key you cannot account for.
3. Attribute by model and endpoint. Reasoning models burn hidden reasoning tokens that never appear in the response but do appear on the bill. A model swap, even an alias resolving to a newer model, can multiply cost per call.
4. The four usual suspects: a retry storm on 429s multiplying every failed call; a tool-call loop running dozens of turns per task; a batch or backfill someone ran and forgot; streaming retries rebilling prompt tokens each time.

The fix

Kill the hot path first, argue later. Then add rails: org and project spend limits set to deliberate values, usage alerts before the limit, per-key tracking so the next spike names its key immediately. Rotate keys on a schedule so a leaked key has a short half-life.

Verify the fix

Watch usage for a full day and confirm the burn rate is back to baseline. Fire a test alert against your spend threshold before trusting it in production.

When to use this

• This covers exactly what the title says: OpenAI bill spiked overnight.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with OpenAI; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current OpenAI behavior.

OpenAI documents enforced monthly spend limits at organization scope (applies across all projects) and project scope, with distinct 429 codes when each trips, plus the OpenAI-assigned usage limit. Spend limits turn an unbounded spike into a paged alert, and retrying past them never restores access (https://platform.openai.com/docs/guides/error-codes, https://platform.openai.com/docs/guides/rate-limits).