Thinking Tokens: The Hidden Cost in AI Bills

A reasoning model thinks before it answers. You pay for that thinking, and you see very little of it.

A response can show 400 tokens while the bill counts 3,400. The request does not change. The answer gives no hint. Below is how three providers bill that hidden work, where it grows, and how to measure it.

You pay for words you never see

Anthropic, OpenAI and Google all bill thinking at the output-token rate. Output is the expensive side of every price list.

Anthropic says thinking tokens bill as output tokens. You pay for the full thinking. The summary in the response is shorter, and the docs say the billed output count does not match the visible token count.

OpenAI says reasoning tokens are not visible through the API and are billed as output tokens.

Google says Gemini response pricing is the sum of output tokens and thinking tokens. Its thinking guide says billing uses the full thought tokens, even when the response shows only a summary.

So the text you read tells you little about the tokens you pay for.

A worked example

This example is illustrative. The prices come from the data behind our LLM cost calculator, checked on 2026-09-27.

Say a service sends 50,000 requests a day to Claude Sonnet 5. Output costs $10 per 1M tokens. Each visible answer is 400 tokens.

• Visible answers: 50,000 × 400 = 20M tokens a day, or $200 a day.
• Add 3,000 thinking tokens per request: 50,000 × 3,400 = 170M tokens a day, or $1,700 a day.

The output line grows 8.5x. Over 30 days it goes from $6,000 to $51,000. Someone who reads the logs sees the same requests and the same answers. Only the usage numbers differ.

Your thinking length will be different. It changes with the model, the effort setting and the task. What matters is the ratio. The hidden part can be many times the visible part.

Where the cost hides

You see a summary of the thinking, but you pay for all of it. Anthropic states this directly.

A cut-off answer still bills. On OpenAI, a request that hits max_output_tokens comes back incomplete, and you still pay for the reasoning tokens. This is true even when no visible text comes back. Gemini works the same way. When a request hits max_output_tokens, the status is incomplete and the output can be short or empty. The thinking guide says Gemini still bills for any thinking tokens it generated.

Agent loops multiply the cost. On Anthropic, max_tokens is a hard cap for one request. In a tool-use loop, each request has its own max_tokens, so the cap does not bound the spend of the whole turn.

Old thinking comes back as input. On current Claude models, thinking blocks from earlier turns stay in the context. They bill again as input tokens on each later request.

A change of effort breaks the cache. On Anthropic, a new effort value between requests invalidates the prompt cache. A router that changes effort on each request can lose its cache savings.

How to measure it

Each provider reports the thinking count in the response. Log it on every call.

Provider	Usage field	Cap control
Anthropic	usage.output_tokens_details.thinking_tokens	max_tokens, effort
OpenAI	usage.output_tokens_details.reasoning_tokens	max_output_tokens, reasoning.effort
Google Gemini	total_thought_tokens	max_output_tokens

On Anthropic, the thinking count is part of output_tokens. Do not add it twice. The Gemini row uses the names from the Interactions API docs linked above. If you call the older generateContent API, the API reference names the field thoughtsTokenCount and the cap maxOutputTokens.

How to keep it in check

1. Pick the effort per route. A classifier needs less effort than a code reviewer. Use the lowest effort that passes your quality checks. Keep it stable within a session so the cache survives.
2. Set the output cap on purpose. A cap that is too low wastes money on cut-off answers. A cap that is too high hides a runaway. Test it with real traffic.
3. Cap the loop as well as the request. Count tokens per agent turn in your own code, and stop the loop at a budget you choose.
4. Log the usage field. Store the thinking count next to the model and the route. Your logs are the only place this split exists.
5. Alert per model. A move to a reasoning model shows up as a jump in the cost of one model. A total can hide it.

Current Claude models choose their own thinking depth. Control it with effort and max_tokens. Do not send budget_tokens to these models, because the API returns a 400 error.

What a daily cost view can and cannot tell you

CostMon pulls cost reports from your AI providers. It stores one cost row per day and per model. For each model, it shows cost per 1M output tokens and cost per request.

It can show that the daily cost of a model went up. It can show that the cost per 1M output tokens or per request for that model changed too. It can alert you on that jump per model, before the invoice arrives.

It cannot split thinking tokens from other output tokens. The provider cost reports do not make that split, so CostMon has no separate thinking number. For that split, log the usage fields from the table above.

The two views work well together. Your logs show which request type thinks too much. The daily view shows the day it started to cost real money.

To price your own volumes, try the LLM cost calculator. For more ways to cut spend, read reduce AI costs and AI agent costs. To see how a jump becomes an alert, read cost alerts.