What Gemini "thoughts" tokens cost developers

Gemini “thoughts” tokens are not a side note, they’re part of the bill. If the model spends more tokens thinking, you pay output-rate pricing on that thinking, so the real cost of a request can jump fast even when the final answer is short.

Why thoughts tokens matter more than most devs expect

When you compare models by headline price, it’s easy to focus on input tokens and assume the response is the only expensive part. That breaks down with reasoning-heavy workflows, because the model can generate a lot of internal thinking before it emits the final answer. If those thoughts are billed like output tokens, the cost profile starts looking less like “prompt size” and more like “how hard the model had to work.”

For developers, the practical takeaway is simple: a short user-visible response does not mean a cheap request. A debugging prompt, a refactor plan, or a multi-step code generation task can create a much larger bill than the final text suggests. That’s why cost tracking needs to separate input, output, cache, and reasoning tokens instead of collapsing everything into one number.

If you want the broader market view, the AI Cost Index is a better starting point than any single model page, because it shows how frontier and budget pricing compare in blended terms. It’s also a reminder that “cheap” and “expensive” are workload-dependent, not just model-dependent.

The billing math: a worked example

Let’s use a simple example to show why thoughts tokens can dominate a request. Suppose you send 12,000 input tokens to a model and it produces 3,000 visible output tokens plus 5,000 thoughts tokens. If thoughts tokens bill at the output rate, then your effective output volume is 8,000 tokens.

Now apply a model with pricing of $0.3 input per 1M tokens and $2.5 output per 1M tokens. The arithmetic looks like this:

Input cost  = (12,000 / 1,000,000) * $0.3  = $0.0036
Output cost = (8,000 / 1,000,000) * $2.5   = $0.0200
Total       = $0.0236

That’s 2.36 cents for one request. If you ignored the thoughts tokens and only counted the visible 3,000 output tokens, you’d estimate:

Visible-only output cost = (3,000 / 1,000,000) * $2.5 = $0.0075

That undercounts the request by more than 3x. The point is not that every prompt will look like this, it’s that reasoning-heavy prompts can make the invisible part of the response materially more expensive than the visible part.

For a broader sense of how model pricing varies, the live model prices page is the place to check current input and output rates across providers. If you’re comparing value rather than raw price, the value-for-money view is usually the more useful lens.

What this means for common coding workflows

In practice, thoughts tokens show up where you’d expect a model to reason harder: complex debugging, architecture decisions, long context synthesis, and agentic loops that ask the model to inspect, plan, revise, and retry. These are exactly the tasks developers like to automate, which is why the cost surprise is so common.

• Debugging sessions: more hidden reasoning when the model needs to trace cause and effect across files.
• Refactors: larger output isn’t the only cost, because the model may internally work through multiple candidate changes.
• Agent loops: each step can add another chunk of thinking, even if the final response is brief.
• Long-context prompts: more input often means more analysis, which can push the total bill up from both sides.

That’s why “tokens per request” is a weak metric on its own. A request with modest visible output can still be expensive if the model has to reason deeply to get there. For teams shipping AI features, the better question is not “How many tokens did we send?” but “How many tokens did the model actually use to finish the job?”

It also helps to think in terms of workload categories. A quick autocomplete, a code review comment, and a multi-step architecture critique all burn tokens differently, even if they share the same model. If you track them together, you lose the signal that tells you where the bill is really coming from.

Small comparison: where the budget disappears

Here’s a simple comparison of how different pricing structures behave when output-heavy or reasoning-heavy usage starts to dominate. These are the exact per-1M-token figures provided in the current pricing data.

The table doesn’t tell you which model is “best” for your app, because that depends on task quality and latency too. But it does show the shape of the problem: once output-like tokens become the main driver, the input number stops being the whole story. That is especially true for tasks where the model spends a lot of time thinking before it answers.

If you want a quick market snapshot, the State of AI page is useful context for how these pricing patterns fit into the broader ecosystem.

How to track this without guessing

The easiest way to stop guessing is to measure actual token usage from the tools you already use. MyTokenTracker is built for that workflow: run npx mytokentracker and it reads the usage logs coding agents already keep locally, then prints a 30-day cost table at API prices. No account is needed for that local check, and usage data never leaves the machine.

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

For teams building directly into code, the drop-in wrappers also help you see where the bill comes from. Python wrappers include track_openai, track_anthropic, track_google, and track_mistral, while Node uses trackOpenAI and the equivalent helpers. Any other provider can be supported with a single POST to the events API.

That matters because the right unit of analysis is not just tokens, it’s tokens by provider, model, platform, and use-case. MyTokenTracker captures cost, input/output/cache/reasoning tokens, latency, and success, so you can finally answer questions like “Which agent is burning budget?” and “Which workflow has the worst cost per successful task?”

Open data is available under CC BY 4.0, and there’s also a public data and API layer if you want to build your own dashboards or analysis. For the raw catalog, check the live prices in /models.

FAQ

Do thoughts tokens always cost the same as output tokens?

In the pricing model discussed here, yes, thoughts tokens bill at the output rate. That’s why hidden reasoning can move the bill much more than people expect, especially on tasks that require multi-step analysis or long internal deliberation.

Why does a short answer sometimes cost more than a long one?

Because the visible answer is only part of the work. If the model spends a lot of internal tokens reasoning before it responds, the total billed usage can be higher than a longer but simpler completion.

What should I monitor first if I’m trying to control spend?

Start with input, output, and reasoning tokens broken down by model and use-case. Then look at latency and success rate, because the cheapest request is useless if it fails or takes too long. If you want a quick way to see this in practice, run npx mytokentracker and inspect the 30-day table on your machine.

Try it locally with MyTokenTracker install instructions.