Uber's CTO burned the company's full 2026 AI coding budget in four months. That is not a story about expensive models. It is a story about a billing mechanic almost nobody thinks about when they first turn on a reasoning model.
The mechanic: reasoning models write an invisible draft before they answer. That draft - the "thinking" or "reasoning" tokens that OpenAI's o-series, Google's Gemini Thinking models, and Claude's extended thinking generate - is billed at the same rate as ordinary output tokens. Most of it never appears in your application.
A short, clean answer can be sitting on top of a reasoning-token bill several times its size, and unless you're reading the right field in the API response, you won't see it coming.
This is not a niche concern for teams running research workloads. It is now the default mode for most capable models, and GitHub moved all Copilot plans to usage-based billing on June 1, 2026, replacing premium request units with AI Credits calculated from token consumption - including input, output, and cached tokens - at the published API rate for each model. That change made the math visible to millions of developers for the first time. Many did not like what they saw.
What reasoning token costs actually look like in production
On Claude with extended thinking enabled, a single complex request can legitimately spend 20,000-40,000 thinking tokens before outputting 500 visible tokens. At Opus rates, that is $0.50-$1.00 in thinking tokens alone, per call.
That math compounds fast in agentic workflows. Modern AI systems increasingly use multi-turn reasoning, tool use, and chain-of-thought processing that multiply the tokens generated per user interaction by 5-50×. An AI agent that plans, executes, and verifies may generate 10,000+ tokens per task versus 500 tokens for a simple Q&A response.
A single o3 call can burn 50,000 output tokens of chain-of-thought before producing a one-paragraph answer.
At $60 per million output tokens, that is $3 per complex call - negligible in testing, devastating at 10,000 calls per day.
The real-world data from teams who have watched their bills confirms this shape. One team used Claude Opus with extended thinking enabled for 40-character text snippets. Average request: 30 input tokens, 18 visible output tokens, 1,200 thinking tokens. Actual cost per call: $0.030. Expected cost: $0.001. Actual was 30× expected.
The inverse is also true. One team used Claude Opus extended thinking for 2,500-token legal document analysis. Thinking averaged 15,000 tokens, output averaged 1,800. Total cost per call: ~$0.43. First-attempt accuracy went from 72% (non-reasoning) to 94%, cutting human review hours dramatically. The cost was real but so was the ROI. The problem is not that reasoning is expensive. The problem is deploying it indiscriminately.
What the GitHub Copilot billing shift actually reveals
GitHub announced that all Copilot plans transitioned to usage-based billing on June 1, 2026, with every plan now including a monthly allotment of AI Credits calculated from token consumption - input, output, and cached - at the listed API rates for each model.
Subscription prices did not move, but the unit of measurement did - and for power users running agentic workflows, that quietly turned a predictable monthly bill into a usage meter that can spike fast.
The exposure is concentrated in agent mode. One developer in the community thread estimated that agentic coding sessions - where Copilot plans, researches, and executes multi-step tasks - routinely consume $30 to $40 per session. A Pro user with $10 per month in credits hits their ceiling in a single working session.
The model-price spread is huge. GPT-5.5 output is 24× GPT-5.4 nano output. A careless model picker is now a billing bug.
The deeper issue the Copilot change surfaced is structural. Only 43% of organizations track AI spend by customer and just 22% track it by transaction. The other 78% are making model selection, caching strategy, and routing decisions without data on whether those decisions are working. That was a manageable gap when pricing was flat. It is not manageable when every model selection is a billing decision.
Where to actually cut the bill without cutting quality
The right framework is task routing, not model downgrading. Reasoning tokens pay for themselves on genuinely hard problems and burn money on everything else.
Match effort to how much reasoning the task needs, not how important it feels. Recall, extraction, reformatting, and simple edits need almost none - use low or minimal effort. Multi-step problems with real depth, like architecture, tricky debugging, or algorithms, are where high effort earns its cost.
Concretely, a routing schema for a team-facing AI assistant might look like this:
| Task type | Reasoning mode | Rationale |
|---|---|---|
| Lookup, classification, formatting | Off | Zero quality gain, full thinking-token cost |
| Code review (single file) | Low | Light reasoning, catches obvious issues |
| Architecture review, debugging | Medium-High | Multi-step logic justifies the spend |
| Legal/compliance analysis | High with hard cap | Accuracy gap over non-reasoning is proven |
| Translation, summarization | Off | Non-reasoning models are equally accurate |
A few specific controls worth setting now:
OpenAI: use
reasoning_effort: "low"or"medium"instead of leaving it at"high"for chat-style tasks. Reasoning effort controls how many hidden thinking tokens a model spends before answering, and those tokens bill at output rates. Use low or minimal effort for recall, extraction, and formatting; keep medium as your default; reserve high or max for architecture, hard debugging, and genuine multi-step reasoning.Anthropic Claude: omit the thinking parameter entirely, or set
thinking.typeto"disabled"for tasks that don't need it.Gemini: set
thinking_config: {thinking_budget: 0}in your generation config for non-reasoning tasks.Monitor the right field: monitor billed reasoning tokens directly from usage fields - OpenAI's
completion_tokens_details.reasoning_tokens, Claude'soutput_tokens_details.thinking_tokens- rather than assuming the visible response length reflects the real cost.
The single least obvious trap: defaults are creeping toward high effort. Check your config and override it for the classes of task that never needed it. A team that enabled reasoning six months ago and never revisited the config may be running high-effort thinking on every Slack summary, every standup digest, every one-line lookup.
Reasoning model token costs: common questions
What are thinking tokens and are they actually billed?
Thinking tokens are the tokens a model generates internally to work through a problem step by step before producing its final answer. They're generated by models with extended-reasoning modes - OpenAI's o-series, Google Gemini's Thinking models, and Claude models with the thinking parameter enabled - and are billed at the model's output-token rate, whether or not you ever see them.
Can prompt caching offset reasoning token costs?
Input tokens get 50-90% discounts when cache-hit (Claude, DeepSeek, Gemini). Thinking tokens are per-request stochastic - no cache, full price every time. Caching helps with system prompts and large context, but it does not reduce reasoning spend at all.
How much do reasoning tokens cost compared to visible output?
One thinking token costs exactly what one visible output token costs.
A task that spends 4,000 thinking tokens before a 500-token answer costs roughly 9× what the bare answer would. The multiplier scales with task complexity and the effort setting.
Which tasks should never use reasoning mode?
Reasoning models shine on multi-step problems - math, code generation, legal analysis. For translation, classification, short-form summarization, extractive QA, and simple RAG, non-reasoning models are faster, cheaper, and just as accurate.
How does the GitHub Copilot change affect teams using agent mode?
Users with intense agentic usage will likely see an increase in costs because those features consume more compute.
Once an assistant is metered by tokens, your cost discipline has to live in your own instrumentation, defaults, and caps - not in the vendor's pricing page. Set per-user and org-level budget controls immediately; the fallback model safety net is gone.