What 'thinking' actually means across models

Every major vendor now ships a reasoning mode. Anthropic calls it extended thinking. Google calls Gemini's variant thinking. OpenAI's is exposed as a reasoning effort setting. The marketing language is similar across all three. The actual mechanism is similar too. The cost profile and the right use case differ.

The shared mechanism

In all three implementations, "thinking" means the model produces a hidden reasoning trace before producing the user-visible answer. The trace can be very long — hundreds or thousands of tokens of internal monologue. You pay for those tokens (they count toward output cost on Anthropic and as "reasoning tokens" on OpenAI), and the user-visible answer arrives later because the trace is generated first.

The trace is real chain-of-thought. The model is allowed to backtrack, contradict itself, try multiple approaches, and discard the failures. The visible answer is only what the model ends up confident in.

This is different from prompt-engineered chain-of-thought (the "think step by step" pattern from the Foundation course). Prompt-engineered CoT is a single forward pass with the reasoning written into the visible output. Vendor-shipped thinking modes have a separate hidden phase, and the answer is post-thinking.

What each vendor calls it

Vendor	Mode name	Shape of the control	Pricing model
Anthropic	Extended thinking	thinking: { type: "enabled", budget_tokens: N } — a parameter on a normal Claude call. You set a token budget.	Thinking tokens billed as output tokens
OpenAI	Reasoning effort	reasoning_effort — a parameter on reasoning-capable models. You set a level, not a budget.	Reasoning tokens reported separately in usage
Google	Thinking	A thinking setting inside the generation config. Gemini 2.5 takes a token budget; the 3.x line takes a level.	Thinking tokens billed as output tokens

⚠ Prices change frequently. The values above are for illustration only and may be out of date. Always verify current pricing directly with the provider before making cost decisions: Anthropic · OpenAI · Google Gemini · Google Vertex AI · AWS Bedrock · Azure OpenAI · Mistral · Cohere · Together AI · DeepSeek · Groq · Fireworks AI · Perplexity · xAI · Cursor · GitHub Copilot · Windsurf.

The first thing to notice is that this table used to look different, and it will again. An earlier version of this lesson taught that OpenAI was the odd one out — that thinking there meant switching to an entirely separate model family, while Anthropic and Google exposed it as a flag. That was true of the o-series era. It is not a safe description of OpenAI's current line, where reasoning effort is a setting on the same model and can be turned down to nothing so the model behaves like a non-reasoning one. Google moved too, from a numeric token budget in the 2.5 generation to a named level in 3.x.

So the durable skill is not memorising three rows. It is knowing which two questions to ask of any vendor's reasoning mode, because the answers are what your code depends on:

1. Is it a separate model, or a setting on the model I already call? This decides whether enabling it is a one-line change or a routing change.
2. Do I control it with a token budget or a named level? A budget is a number you tune against cost. A level is a fixed menu. Code written against one does not port to the other.

Both answers live in the vendor's reasoning documentation — Anthropic, OpenAI, Google — and those pages are corrected when the shape changes. This one is not.

What has stayed true across every revision of all three: thinking adds a latency tax and a cost tax. Responses can take tens of seconds on hard problems against a second or two for the same prompt without it, and you pay for the hidden trace whether or not the visible answer changed.

When the latency and cost are worth it

The honest answer is: less often than the marketing suggests. Most production prompts are tone rewrites, classifications, summarisations, and structured extractions — tasks where the base model already has the answer in one forward pass. Adding thinking to those tasks is paying for a feature you do not use.

Thinking pays back when the task has true intermediate reasoning — multi-step puzzles, code generation that requires careful state-tracking, math word problems with several sub-calculations, planning tasks where the answer depends on a long chain of "if X then Y". The next two lessons run a logic puzzle through the three base models so you can see what "without thinking" looks like, then we compare to the cost of escalating to thinking mode.

Next: a logic puzzle across all three base models, no thinking enabled. The output gap is wider than you would expect. :::