Reasoning Tokens vs Output Tokens: What Costs More

Reasoning tokens usually cost the same as output tokens when a model bills them that way, which means “thinking harder” can quietly move your bill into the expensive part of the rate card. The practical takeaway is simple: if you only watch visible output, you’re missing part of the spend.

Why reasoning tokens are not just “extra output”

For developers, the important distinction is not philosophical, it’s billing. A model can spend tokens internally to plan, verify, or chain steps before it emits a final answer. Those internal tokens are often charged like output tokens, not like input tokens, so they can be materially more expensive than the prompt itself.

That matters because many workflows are built around a cheap prompt and a small response, but the model may do a lot of invisible work in between. If your agent is debugging code, comparing files, or iterating on a patch, the reasoning budget can dominate the total cost even when the final answer looks short.

That’s also why a blended view is helpful. The AI Cost Index gives you a quick way to compare model economics without pretending every token behaves the same. And if you want the broader market context, the State of AI page shows how these costs fit into the current landscape.

Input, output, and reasoning: the billing shape that matters

Think of a request as three buckets:

• Input tokens, what you send in.
• Output tokens, what the model returns.
• Reasoning tokens, internal work that may be billed like output depending on the provider and model.

The core trap is assuming the output line in a dashboard is the whole story. It usually isn’t. If a model uses a lot of reasoning tokens, the cost profile starts to look more like a long completion than a short chat reply.

Here’s the mental model I use: input tokens set the floor, output tokens set the ceiling, and reasoning tokens decide how fast you hit it.

A worked example with real token math

Let’s use a concrete example with a model we can price exactly: gpt-4o at $2.5 input and $10 output per 1M tokens. Say your agent sends 120,000 input tokens and produces 30,000 visible output tokens, plus 50,000 reasoning tokens that are billed at the output rate.

The arithmetic looks like this:

Input cost = (120,000 / 1,000,000) * $2.5 = $0.30
Output cost = (30,000 / 1,000,000) * $10 = $0.30
Reasoning cost = (50,000 / 1,000,000) * $10 = $0.50
Total = $1.10

Now compare that with the same prompt and visible answer but no reasoning tokens:

Input cost = $0.30
Output cost = $0.30
Total = $0.60

Same visible behavior, nearly double the bill. That’s the part people miss when they ask why a “small” task costs more than expected.

If you want to sanity check a model’s economics before you run a real workload, the live catalog at /models is the place to look. It’s much easier to reason about spend when the rate card is explicit.

Which is cheaper, reasoning or output?

In billing terms, reasoning is usually not cheaper. If it is charged at the output rate, it costs the same as visible generation. That means the expensive part of the request is not the answer you see, it’s the work you don’t see.

Here’s a small comparison using only the prices we can state exactly:

The exact policy for reasoning tokens depends on the model and provider, but the pattern is consistent: output-side tokens are where the bill gets steep. That’s why a model with a modest input rate can still surprise you once it starts thinking hard.

For a broader value-for-money lens, the value view is useful because it helps you compare cost against capability instead of staring at price in isolation.

Where developers get blindsided

The biggest surprises usually come from agentic workflows, not one-shot prompts. A coding agent may read a large context, inspect multiple files, revise its plan, and regenerate patches more than once. Each loop can add hidden reasoning overhead.

• Long context, because the model has more to inspect before it answers.
• Multi-step tool use, because each step can trigger more internal deliberation.
• Retry loops, because failed attempts still burn tokens.
• Verbose completions, because visible output is only part of the total.

This is why two developers can use the same model and see wildly different bills. One is asking quick questions. The other is running a coding agent that keeps the model in a long planning loop.

It also explains why cost per task is often more useful than cost per message. A task can succeed after one short response, or it can take several internal passes before the agent lands the patch. The token count alone doesn’t tell you which happened.

How to track this without guessing

You don’t need to infer any of this from a monthly invoice. Run npx mytokentracker and it reads the usage logs your coding agents already keep locally, then prints a 30-day cost table at API prices. No account is needed for that, and the usage data never leaves your machine.

If you want a dashboard, create a free account and run npx mytokentracker init. It asks for the API token, uploads history, then syncs every 30 minutes. It works with Claude Code, Codex, GitHub Copilot CLI, Antigravity, OpenCode, Amp, Qwen Code, and more. Only daily totals per agent and model are uploaded, never prompts, code, or file names.

That makes it possible to answer the question that actually matters: which agent, model, and use-case is burning tokens, and is the spend coming from input, output, or the invisible thinking in between?

MyTokenTracker also supports drop-in wrappers for OpenAI, Anthropic, Gemini, and Mistral, plus a single POST to the events API for other providers. So if you’re building your own workflow, you can capture cost, input/output/cache/reasoning tokens, latency, and success without duct tape.

FAQ

Are reasoning tokens always billed separately?

No. Sometimes they’re exposed as a distinct field, sometimes they’re folded into output-like billing. The key point is that they are not free just because you don’t see them in the final answer. Check the provider’s model-specific behavior and verify it in your own logs.

Why is my bill higher when the answer looks short?

Because the model may have spent a lot of hidden tokens planning, checking, or iterating before producing that short answer. A concise response does not imply a cheap request. If the model did a lot of internal work, the cost can still be high.

What’s the best way to compare models on this dimension?

Compare them on total task cost, not just the visible completion. Use live pricing from /models, then track actual usage with a tool that records reasoning and output separately. That gives you a real picture instead of a guess.

If you want to see your own reasoning-heavy workflows instead of estimating them, install MyTokenTracker and start with the logs your tools already keep locally.