Reasoning Tokens: The Invisible Output Tokens Eating Your OpenAI Bill

Here is the direct answer: when you call one of OpenAI's reasoning models, the model thinks before it answers, and that thinking is billed as output tokens — even though you never see a single one of those tokens. OpenAI's own reasoning guide says it plainly: reasoning tokens are not visible via the API, they still occupy space in the model's context window, and they are billed as output tokens. If your bill for a reasoning model looks far too high for the short answers you received, this is almost certainly why. You were not charged for the answer. You were charged for the thinking that produced it, at the most expensive rate on the price list.

The bill that does not add up

OpenAI's reasoning guide contains a small usage example that explains more about real bills than most pricing pages do. A request sends 75 input tokens and gets back 1,186 output tokens. That already looks odd for a short answer, and the breakdown explains why: of those 1,186 output tokens, 1,024 are reasoning tokens. Only 162 tokens are the visible answer. The model did roughly six times more thinking than writing, and every one of those 1,024 thinking tokens is billed at the output rate.

This is not a rounding error or an edge case. It is the normal behaviour of reasoning models. Before producing a response, the model generates internal reasoning tokens to plan, consider alternatives, and work through a problem step by step. The API does not return that reasoning text. What it returns is the final answer, plus a usage object that quietly records how much thinking happened. Developers who only look at the answer — the text their app displays — see a 162-token reply and expect a 162-token charge. The invoice says 1,186.

The gap gets worse with harder tasks. OpenAI's guide says a request may generate anywhere from a few hundred to tens of thousands of reasoning tokens, depending on the problem's complexity. A simple classification question might think for a few hundred tokens. A multi-step coding or research task can think for tens of thousands before writing anything. The harder the task you hand a reasoning model, the larger the share of your bill becomes invisible.

Worked math: what the invisible part actually costs

Take the guide's own example and price it on gpt-6.1-sol, whose standard rates on OpenAI's pricing page are $2.00 per million input tokens and $10.00 per million output tokens. The arithmetic is straightforward, and every number below comes from those two published rates and the guide's own token counts.

The output charge is 1,186 tokens × $10.00 ÷ 1,000,000 = $0.01186. The reasoning share of that is 1,024 × $10.00 ÷ 1,000,000 = $0.01024. The visible answer, priced alone, is 162 × $10.00 ÷ 1,000,000 = $0.00162. So 86 percent of the output bill — $0.01024 of $0.01186 — pays for thinking you never saw, and the answer you actually received costs about one-seventh of what you paid for the call's output.

Now scale the thinking up to the size OpenAI itself tells developers to plan for. The guide recommends reserving at least 25,000 tokens for reasoning and outputs when you start experimenting with these models. A call that uses the full 25,000-token reserve as reasoning costs 25,000 × $10.00 ÷ 1,000,000 = $0.25 in reasoning alone, before a single visible word. That is one call. Ten thousand such calls — an ordinary month for a small production feature — would be $2,500 of reasoning tokens. These are not measured bills from a real app; they are the guide's own reserve figure multiplied by the published output rate, shown so you can see how fast invisible tokens compound. The point is the multiplier: output tokens cost five times input tokens on this model, and reasoning tokens are billed at the output rate, not the input rate. Invisible thinking is charged at the most expensive price the model has.

Three traps the usage object hides

The first trap is the one above: invisibility. Nothing in the answer itself hints at how much thinking happened. Two answers of identical length can cost wildly different amounts, because one took 300 reasoning tokens and the other took 30,000. If your code logs only the visible text, or only total tokens, you cannot tell them apart. The fix is to read the field OpenAI actually provides: output_tokens_details.reasoning_tokens in the usage object. Our cost-tracking middleware tutorial shows how to log one line per call with the full usage breakdown — extend it to record reasoning tokens separately, and the invisible line on your bill becomes a column you can sort.

The second trap is the output cap. The max_output_tokens parameter limits everything the model generates: reasoning tokens, visible answer tokens, and non-visible formatting tokens together. OpenAI's guide warns that if generation hits the cap, you get a response marked incomplete — and that this can happen before any visible output tokens are produced. Read that carefully: you can pay for the input and for thousands of reasoning tokens and receive nothing usable at all. A low output cap on a reasoning model does not save money the way it does on a chat model; it creates paid calls that return no answer. Set the cap with the reasoning reserve in mind, not the answer length you expect.

The third trap is the default effort. Reasoning models expose a reasoning.effort setting — none, minimal, low, medium, high, xhigh, and max depending on the model — and the default is not "as little as possible." GPT-5.5, for example, defaults to medium effort. GPT-5.6 and GPT-6 models add a separate pro reasoning mode that performs more model work than standard mode, billed at the model's standard token rates. If you never touch these settings, you are running at a middle-to-high thinking budget on every call, including the easy ones. And on GPT-5.6 models, the default reasoning context setting renders reasoning from earlier turns into the next sample, so a long conversation carries its earlier thinking forward as context. None of this is wrong — it is how reasoning models earn their quality — but every default here points toward more thinking, and more thinking is billed at the output rate.

How to keep reasoning tokens from eating your bill

Start by measuring the ratio, not the total. For each feature, log reasoning tokens and visible output tokens separately for a week, and compute the reasoning share the way the worked example above does. A feature with a reasoning share above 80 percent is a feature where the model is doing far more thinking than writing; that is where effort tuning pays. A feature with a low, stable share is fine at its current setting. This is the same measure-first discipline behind our per-user spending guard: you cannot control a cost line you cannot see, and reasoning tokens are the least visible line on an OpenAI invoice.

Then match effort to the task, deliberately. Use minimal or low effort for classification, extraction, and simple lookups — tasks where the answer is short and the thinking should be too. Reserve medium and high effort for the genuinely hard work: debugging, planning, and multi-step agentic tasks. OpenAI's own guidance says lower effort favours speed and lower token usage, while higher effort is for cases where quality justifies the extra latency and cost. Test the lower setting first and only raise it when your own evaluation shows a clear quality gain, not because the default felt safe.

Finally, treat reasoning tokens as part of the price of the model, not as an overhead to ignore. When you compare a reasoning model against a non-reasoning one, do not compare output rates alone — compare the full output line, reasoning included, for the same task. That comparison is the honest version of the argument in our piece on why per-token pricing misleads: you pay for effort, not results, and reasoning tokens are the purest form of that. The models are worth their price when the thinking improves the answer. The gotcha is only that the thinking is billed invisibly, at the output rate, whether or not you ever look at the usage object. Once you do look, the bill stops being a mystery — and the effort dial becomes the cheapest optimisation you have. Our OpenAI pricing guide lists the current rates to run this math against for the model you actually use.