A field guide · Understanding LLMs

Thinking in Tokens

A reasoning model is the same Transformer you already know. Post-training changed what it writes before it answers — and writing is how a fixed-depth network buys itself more depth.

Reasoning modelsTest-time computeChain of thought

Not a new architecture

The first thing to say about reasoning models is the least exciting thing, and almost everything else follows from it. When a model spends ninety seconds on a competition problem and emits eleven thousand tokens of deliberation before writing an answer, no new module has switched on. There is no planner, no external search tree, no scratch memory bolted onto the side. It is the same decoder-only Transformer, running the same forward pass, sampling one token at a time, left to right, exactly as it did when it was writing product descriptions.

What changed is the distribution over what it writes before it answers.

This is worth being pedantic about, because the vocabulary invites the opposite conclusion. We say the model "thinks," we say it "reflects," we call the tokens "reasoning tokens," and vendors put them behind a collapsible panel labelled with a brain icon. All of that framing suggests a separate faculty. Mechanically there isn't one. There is a probability distribution over sequences, and post-training moved mass from short sequences that jump straight to an answer toward long sequences that work through the problem first.

OpenAI's announcement of o1 is careful about this. The claim is not that a new component was added; it is that a large-scale reinforcement learning procedure taught the model to use its chain of thought productively, and that performance then improved along two separate compute axes — more reinforcement learning during training, and more time spent thinking at test time. Two axes, one architecture. DeepSeek-R1 later gave the open, detailed version of the same story, which is why it is the model most of this article's mechanics are drawn from.

So the interesting question is not "what did they add." It is: what does a model buy by writing a long intermediate trajectory, and what does it pay? That question has a surprisingly crisp answer, and the answer explains nearly every design decision downstream of it — why reasoning traces are long, why longer is not automatically better, why "thinking budget" is a coherent knob at all, and why some researchers now want to take the words out of the reasoning entirely.

This post is the companion to the previous one in this series. RL for Reasoning covered the training algorithm: verifiable rewards, GRPO, what the gradient actually does. This one covers the resulting computation: what the model is doing when it runs.

One latent variable

Here is the single equation the rest of this article hangs off. An ordinary language model gives you

\[ p_\theta(y \mid x) \]

the probability of an answer \(y\) given a question \(x\). A reasoning model gives you the same object, but factored through an intermediate sequence \(z\):

\[ p_\theta(y \mid x) \;=\; \sum_{z} \underbrace{p_\theta(z \mid x)}_{\text{which trajectory}} \; \underbrace{p_\theta(y \mid x, z)}_{\text{answer given it}} \]

That is not a new model. It is the same model with a marginalisation written out. Any autoregressive model over \((z, y)\) already implies this identity; the sum is over every string \(z\) the model could have written in between. Nothing has been assumed yet.

What makes it useful is that it names the two things training can change independently. You can change which trajectories are likely — that's \(p_\theta(z \mid x)\). And you can change how reliably an answer follows from a trajectory — that's \(p_\theta(y \mid x, z)\). Every technique in this article is a choice about what to do with \(z\), and they line up almost too neatly:

Elicit

Chain-of-thought prompting: make the model produce a \(z\) at all, by showing it examples that contain one.

Marginalise

Self-consistency: the sum over \(z\) is intractable, so estimate it — sample many \(z\), read off the answer they agree on.

Fit

STaR: you don't have supervision for \(z\), so infer it. Keep the \(z\) that produced correct \(y\), fine-tune on them, repeat. Hard EM in a trench coat.

Optimise

RL with verifiable rewards: stop imitating good \(z\) and start maximising \(\mathbb{E}_{z \sim p_\theta}[R(y)]\) directly.

Search

Tree of Thoughts: \(z\) has prefixes, prefixes can be scored, so run an actual search over them instead of sampling whole strings.

Iterate

Self-Refine: let one \(z\) criticise the answer and produce the next \(z\), across separate model calls.

Re-encode

Coconut: stop making \(z\) a string of tokens at all. Let it be a sequence of vectors.

Bound

Thinking budgets: cap \(|z|\), because every element of it costs a forward pass.

Read down that column and you have the field. Read it as a chronology and you have roughly 2022 to now. The rest of this article walks it, but the spine is always the same object: an unobserved intermediate sequence that the model writes to itself.

One more thing before moving on, because it is the source of a lot of confusion. At inference the model does not compute that sum. It samples a single \(z\) and commits. So a single chain of thought is a one-sample Monte Carlo estimate of a marginal — which is exactly why the estimate is noisy, why sampling more chains helps, and why an early mistake in \(z\) is unrecoverable rather than merely down-weighted. Almost every failure mode later in this article is a property of the estimator, not of the model.

Prompt, sample, train, reward

The lineage matters because each step is a strictly stronger intervention on the same latent variable, and because the jump people find surprising — that a model could learn to deliberate from a scalar reward — is the smallest step in the sequence, not the largest.

Four interventions on the same hidden reasoning trajectory
InterventionChanges weights?Extra samples?Needs a verifier?What improves
Prompt a worked example×××Makes an existing reasoning style more likely
Sample and vote×✓×Reduces the noise of trusting one chain
Filter and imitate✓✓✓Moves successful trajectories into the model
Optimize reward✓✓✓Lets the model discover trajectories beyond demonstrations

Why the field moved this way. Prompting was cheap but unreliable. Voting bought reliability by paying for many attempts. Filtering turned successful attempts into training data, but still copied a fixed set of examples. Reward optimization removed that ceiling: it kept only the success criterion and let trajectory shape and length adapt. The progression is therefore not four unrelated papers; it is a steady relaxation of how tightly humans specify the intermediate steps.

Four escalating interventions on the same latent variable. Each era does not replace the previous one — self-consistency still works on a reasoning model, and a reasoning model still benefits from a good prompt. They stack.

Notice what is not in that sequence: any change to the network. Between 2022 and 2025 the thing that got dramatically better at deliberating is architecturally the same family of model. The leverage came entirely from what the model was encouraged to write down.

What a token buys

Now the mechanism. Why should writing more text before answering make a model better at anything? The lazy answer is "more compute," which is true and explains nothing. The precise answer is that a Transformer has a hard structural limit that generating tokens is the only way around.

More context makes the machine wider. Only generation makes it deeper.

Take a decoder with \(L\) layers. For any position in the sequence, the computation that produces that position's output runs through exactly \(L\) blocks. Attention in layer \(\ell\) can read the layer-\(\ell{-}1\) representations of every earlier position, which is enormous parallel reach. What it cannot do is read a layer-\(\ell{+}1\) representation of anything, anywhere. There is no loop. There is no way for the network to say "compute this sub-result first, then use it."

So the computation graph for a single forward pass has depth \(O(L)\) no matter how long the input is. Doubling the context doubles the width of the machine — more positions, more values to attend over — and leaves the depth untouched. This is the fact that makes Transformers train well, because depth is what you cannot parallelise. It is also the fact that caps what they can do in one shot.

Generating a token is the loop. The token is appended to the sequence, and on the next step it re-enters at layer 0. Whatever the network computed at layer \(L\) is now available as an input to layer 1. The serial depth available to the whole computation becomes

\[ \text{depth} \;\le\; L \cdot K \qquad \text{for } K \text{ generated tokens} \]

and it grows linearly in how long the model is willing to write. That is what a reasoning token buys. Not knowledge, not a new capability in the weights — depth.

The concrete version. Ask a model for the parity of a thousand bits — the XOR of the whole string — and demand the answer immediately, no working. This is not a hard problem in any human sense. It is, however, provably outside what a constant-depth, constant-precision circuit can compute, no matter how wide. Now let it write the running parity after each bit. It becomes trivial. Nothing about the model changed between those two requests except that in the second one it was allowed to put something down.

The formal statement

That intuition has been made precise. Li, Liu, Zhou and Ma analysed decoder-only Transformers through circuit complexity and found a clean separation. Constant-depth Transformers with constant-bit precision, without a chain of thought, are confined to \(\mathsf{AC}^0\) — a proper subset of \(\mathsf{TC}^0\), and notably a class that cannot compute parity. With \(T\) steps of chain of thought, constant-depth Transformers using constant-bit precision and \(O(\log n)\) embedding size can solve any problem solvable by a Boolean circuit of size \(T\).

Read that second clause slowly. The bound on what the model can compute stops being a property of the architecture and becomes a property of how long you let it write. \(T\) is not a hyperparameter you set at training time. It is a runtime decision. Their experiments back the theory where it should bite hardest: chain of thought helps most on tasks that are inherently serial and resist parallelisation — composing permutation groups, iterated squaring, evaluating circuits — and helps most for shallow models, which have the least native depth to spend.

This is also, quietly, the best available justification for why "thinking budget" is a coherent product feature rather than marketing. You are not buying more effort in some vague sense. You are buying circuit size.

Widening versus deepening. Adding context adds columns to the machine; adding generated tokens adds passes through it. Only the second one lifts the depth ceiling.

An old idea wearing a new hat

If this feels familiar, it should. A chain of thought is recurrence, reintroduced through the output channel. The recurrent state is the text, the tape is the KV cache, and the read head is attention over positions you have already written and can never rewrite. It is a Turing-machine-shaped computation running on an append-only tape.

Which gives us the useful analogy, and also the crack that section nine will lever open. When a person does long division on paper, the paper is not clever. It is a place to put the carry so the next step does not have to re-derive it. The chain of thought is that paper. But there is a detail in the analogy worth holding onto: the model's recurrent state has to fit through a token. Everything the forward pass computed — thousands of floating-point numbers in the residual stream — gets collapsed into a choice from a fixed vocabulary before the next step can use it. We will come back to how narrow that channel is.

The bill

Depth is not free, and the price has three separate line items. For a dense model with \(N\) non-embedding parameters, \(L\) layers, hidden size \(d\), a prompt of \(P\) tokens and \(K\) generated tokens:

\[ C_{\text{gen}} \;\approx\; \underbrace{2NK}_{\text{weights}} \;+\; \underbrace{4Ld\left(PK + \tfrac{K^2}{2}\right)}_{\text{attention}} \quad \text{FLOPs} \]

The first term is linear in \(K\): every token pays a full pass over the weights. The second is quadratic in \(K\), because each new token attends over everything written so far. At short lengths the weight term dominates and people ignore attention; at reasoning-model lengths it stops being ignorable. For a 32B-class dense model, the attention term is a few per cent of per-token cost at 1k context and roughly comparable to the weight term by 32k.

The second line item is memory. Every thinking token leaves a permanent KV entry:

\[ M_{\text{KV}} \;=\; 2 \, L \, n_{\text{kv}} \, d_{\text{head}} \, b \cdot K \quad \text{bytes} \]

which for a 64-layer model with 8 KV heads of width 128 in bfloat16 works out to 256 KiB per token — so a ten-thousand-token deliberation costs about 2.6 GB of HBM, per concurrent request, before you have served anyone else.

The third is latency, and it is the one users feel. Decoding is memory-bandwidth-bound, not compute-bound: at small batch sizes each step streams the entire weight matrix from HBM to produce a single token. Thirty-two billion parameters in bfloat16 is 64 GB; at roughly 3.3 TB/s that is about 19 ms per token before you account for anything else. Ten thousand thinking tokens is three minutes of wall clock. Batching amortises the weight streaming across requests, which is why serving economics and reasoning length are the same conversation — the Serving Playbook and The Mechanics of LLM Inference posts in the systems series are the long version.

Put together: a thinking budget is a purchase order for serial depth, denominated in memory bandwidth. Drag the slider below and watch what you are actually buying.

The cost of thought for a 32B-class dense model at batch size one. The weight term grows linearly, the attention term quadratically, the KV cache linearly and permanently, and the latency in direct proportion to all of it.

Reading a trace

If you read enough reasoning traces you start to see the same moves recurring, and it is worth naming them — partly because they are genuinely the vocabulary of the thing, and partly because naming them makes it easier to say precisely what we do and do not know about them.

Decomposition. Splitting a problem into named sub-problems before touching any of them. "There are two parts here: first find the radius, then use it for the area."

Planning. Choosing an approach before executing it, sometimes with an explicit reason for the choice. "Coordinates will be messy; try the synthetic argument first."

Exploration. Trying an approach with visible provisionality. "Suppose the answer is a perfect square. Then…"

Verification. Re-deriving a result by a second route, or substituting back. "Check: 17 × 23 = 391, and 391 + 9 = 400. Good."

Backtracking. Abandoning a line explicitly. "Wait — that assumed the sequence was increasing, which was never given."

Constraint checking. Returning to the problem statement to confirm a candidate satisfies everything, not just the part being worked on.

Alternative approaches. Solving the same thing twice by different means and comparing.

These are the behaviours the "aha moment" discourse is about. They are real, they are visible, and they are the reason reasoning traces read the way they do. Here is where to be careful. There are three distinct claims in the neighbourhood, and they are usually collapsed into one:

Observed

The generated text contains verification steps, backtracking, and the rest. This is simply what the strings look like. Not in dispute.

Supported

Those tokens are load-bearing: truncate them, corrupt them, or cut the budget and accuracy moves. The trace is doing computational work, not decorating a conclusion reached elsewhere.

Contested

The text is a faithful report of the computation — that when the trace says "I checked," a check happened, and when the trace omits a factor, that factor did not influence the answer.

The third claim is the one that keeps failing tests. Turpin and colleagues showed in 2023 that models will produce plausible chains of thought that never mention the feature actually driving the answer — reorder the multiple-choice options so the correct one is always (A), and the model follows the pattern while explaining its answer on the merits.

The reasoning-model era did not fix this. Chen and colleagues at Anthropic evaluated frontier reasoning models across six kinds of hint planted in prompts and measured how often the model's chain of thought admitted using a hint it demonstrably used. Reveal rates were above the floor but frequently under 20%. Outcome-based reinforcement learning improved faithfulness early and then plateaued well short of saturation. And when RL drove the model toward exploiting a hint more often — reward hacking — the propensity to say so out loud did not rise with it.

That result matters beyond epistemics. A readable chain of thought is one of the few windows we have into what a capable model is doing, and there is an active argument that preserving that window is worth real capability cost. Hold that thought; it becomes the central trade-off in section nine.

The honest formulation. These are behaviours in a generated trajectory, described using the words we use for human deliberation because those are the words we have. Saying "the model backtracked" is a statement about the token sequence. Whether it is also a statement about an internal process is a separate question, currently open, and not settled by reading the trace — the trace is the thing under suspicion.

Longer is not better

The last two sections make an argument that could be read as "more tokens, more depth, more better." It is worth killing that reading immediately, because it is wrong in an interesting way.

What helps is serial depth spent on the problem. Token count is a proxy for that. Proxies get hacked — sometimes by the optimiser, sometimes by the model, sometimes by nobody in particular. There are four distinct ways length inflates without depth following it.

Overthinking. Chen and colleagues documented the flagrant case: ask an o1-style model what two plus three is and it will spend orders of magnitude more tokens than a conventional model, exploring multiple solution strategies for a problem with one. They introduced efficiency metrics for this and showed a self-training recipe that trims it without hurting accuracy on GSM8K, MATH500, GPQA and AIME. The cost is not academic — it is latency and dollars on every trivial query in production.

Underthinking. The mirror image, and less obvious. Wang and colleagues found o1-like models that abandon promising lines of reasoning too early and thrash between approaches — lots of tokens, little progress down any one of them. Long and shallow. This is a good reminder that "depth" is the quantity of interest, not "length": a trace that restarts twenty times has spent its budget on twenty shallow attempts.

Length hacking. If the training objective rewards length even incidentally, the policy will find it. The normalisation term in GRPO is the standard example — dividing the objective by response length creates an asymmetry that can systematically favour long incorrect responses over short ones, which is why several follow-ups strip or replace it. The previous post derives that bias in full. The general lesson is the ordinary one about reward design: the model optimises the number you wrote down, not the thing you meant.

Rationalisation. The subtlest. A model that has committed to a wrong answer early can spend the rest of its budget constructing support for it — which looks, token for token, exactly like verification. The failure of self-correction to reliably fix errors without external feedback is closely related, and section eight returns to it.

Three regimes, one knob. The curve that motivates thinking budgets is also the curve that shows why a fixed budget is the wrong default.

Two deflations worth knowing about

Because this is a field guide and not a press release, two results that cut against the standard narrative.

The first concerns the "aha moment" itself. The DeepSeek-R1 report describes self-reflection emerging during pure RL, accompanied by growing response length, and dozens of replications reported the same. Then people checked the baseline. The Sea AI Lab study found self-reflection patterns already present in base models at epoch zero, before any RL — what they called superficial self-reflection, where the reflective phrasing appears but does not lead anywhere. A follow-up hosted DeepSeek-V3-Base itself, the actual starting point for R1-Zero, and found it generating "wait," "verify," and even "Aha" unprompted on math problems. Their reading is that the growth in response length during RL is largely RL optimising a well-shaped rule-based reward, rather than reflection coming into existence. RL made the behaviour reliable and productive, which is a real and valuable thing, but it did not conjure it.

The second concerns the ceiling. Apple's "Illusion of Thinking" ran frontier reasoning models on controllable puzzle families — Tower of Hanoi, blocks world, river crossing, checkers jumping — and reported three regimes: below some complexity, non-reasoning models are both more accurate and cheaper; in a middle band, reasoning models win; past a model-specific threshold, accuracy collapses to near zero. The striking part is the effort curve, which rises with complexity and then falls as the collapse approaches, with token budget still available. The rebuttal, by Lawsen with Claude Opus 4, argued much of the collapse is an output-length artifact — printing a fifteen-disk Hanoi solution requires over 32,000 moves — and that models given a compressed programmatic answer format succeed far past the stated threshold; it also noted some river-crossing instances in the benchmark were unsolvable as posed while being scored as failures. An independent group later replicated and refined both contested benchmarks and landed between the two camps. All three are worth reading in full. My own reading is that the effort-drop finding survives the methodological objections better than the collapse finding does, and it is the more interesting of the two: a system that spends less when a problem gets harder is not allocating compute the way you would want.

Reasoning as refinement

Search assumes you can evaluate a partial state. Refinement assumes something weaker and often more available: that you can look at a finished artefact and say what is wrong with it.

Self-Refine, from Madaan and colleagues, is the minimal version. One model, three prompts: produce an output, critique your own output, revise it using the critique. Loop. No weight updates, no additional training data, no external supervision, no second model. It is a pure inference-time procedure, and on a range of tasks it beats the model's own first draft.

The distinction that actually matters here is one of conditioning, and it is easy to miss because both things get called "self-correction."

In-trace

The model backtracks inside one trajectory. The next token is conditioned on \(z_{1:t}\), which still contains the mistake. Cheap — one KV cache, no re-prefill — but the error stays in context and keeps pulling.

Across calls

An outer loop builds a fresh prompt \(x' = (\text{task}, y_{\text{prev}}, \text{critique})\) and samples a new \(z\) from scratch. Expensive — full re-prefill each round — but you get to choose what survives into the next context.

Same word, different computations, different failure modes. In-trace correction is anchored by its own history; across-call correction is anchored by whatever you decided to carry forward, which is a design choice rather than an accident.

The caveat that decides when this works

The self-correction literature is genuinely mixed, and the shape of the disagreement is instructive. Huang and colleagues made the case that large language models cannot reliably self-correct reasoning on their own: when the only feedback is the model's own judgement, iterations often make things worse, flipping correct answers to incorrect ones. Broadly, the critical reviews converge on three points — no convincing demonstration of self-correction from prompted self-feedback alone except on tasks unusually suited to it; reliable gains when feedback comes from an external, trustworthy source; and reliable gains from large-scale fine-tuning that teaches correction explicitly.

The unifying way to say it: refinement is a verifier amplifier, not a knowledge amplifier. If you have something that can tell right from wrong — a unit test, a compiler, a proof checker, a numeric substitution, a reward model that is actually calibrated — then iterating turns that signal into accuracy, and the more iterations the better. If your verifier is the same fallible process that produced the error, iterating mostly produces more confident versions of the same error.

Which is why the generator–verifier gap is the load-bearing asymmetry of this entire field. Checking a factorisation is easier than finding one. Running a test is easier than writing code that passes it. Everything that works at inference time — voting, search, refinement, best-of-\(n\) — is a way of converting that gap into accuracy, and everything that fails at inference time fails because the gap was not there.

When thought stops being text

Return to something planted back in section four. A chain of thought is recurrence through the output channel — and the output channel is a token.

Look at what happens at each generation step. The forward pass produces a residual-stream vector \(h_t \in \mathbb{R}^{d}\), a continuous, high-dimensional object holding whatever the model has worked out at this position. The language-modelling head projects it to logits over the vocabulary, and sampling collapses those logits to a single index. That index selects one of \(V\) fixed embedding vectors, which becomes the input at the next position.

So the interface between one reasoning step and the next is a selection from a finite codebook. Its capacity is

\[ \log_2 V \;\approx\; \log_2 (151{,}669) \;\approx\; 17.2 \ \text{bits} \]

per step, using Qwen3's vocabulary as a concrete case, while the state that produced the selection is a continuous vector in a space of several thousand dimensions.

Be careful with this argument. It does not mean the model forgets everything else. The KV cache retains per-layer projections of every earlier position, so the next step re-reads all of it; nothing is erased. What the discrete channel constrains is the new content a step can inject at the new position — that must be one of \(V\) fixed vectors. It is a quantisation constraint, not amnesia. And the count of raw bits in \(h_t\) is not its information content; the representation is highly structured and mostly recomputable from context.

The quantisation is arguably the smaller problem. The bigger one is commitment. Sampling forces the model to pick. It cannot carry "probably \(A\), possibly \(B\), and if \(B\) then the earlier assumption breaks" forward as a superposition — it has to write a word, and the word is either \(A\) or \(B\). Every ambiguity is resolved at the moment of decoding, whether or not the model was ready to resolve it. That is the mechanism behind the failure mode from section seven: an early wrong commitment that the rest of the trajectory is then conditioned on.

The pinch point. Sampling is not just narrow — it is a forced decision, taken once per step, before the model necessarily has grounds to take it.

Coconut: keep the vector

Hao and colleagues at Meta asked the obvious question. If the useful state is \(h_t\), why decode it at all? Coconut — Chain of Continuous Thought — takes the last hidden state, calls it a "continuous thought," and feeds it straight back as the next input embedding, skipping the language head and the embedding table entirely. The model runs in a latent mode for some number of steps, then switches to language mode to write the answer; switching can be handled by a fixed-length latent segment or a learned binary classifier, and the paper reports both working comparably. Training uses a multi-stage curriculum that progressively replaces written reasoning steps with latent ones, so the latent states inherit structure from language supervision before being cut loose from it.

The interesting result is not the accuracy number. It is the emergent behaviour: a continuous thought can encode multiple alternative next steps at once, letting the model carry something like a breadth-first frontier instead of committing to a single path. Coconut beats chain of thought on logical reasoning tasks that require substantial backtracking during planning, and does it with fewer thinking steps. Follow-up work has developed the superposition reading formally and analysed how it emerges from the training objective.

Which is exactly the prediction the bottleneck argument makes. Remove the forced commitment and you get search for free, because the state can be a distribution over branches instead of a choice among them.

Quiet-STaR: think everywhere, not just at answers

A different attack on the same seam. STaR learned rationales in a narrow setting — question, rationale, answer, filtered by correctness. But reasoning is implicit in nearly all text: the steps left out of a proof, the theory of mind under a line of dialogue. Zelikman and colleagues generalised it so that the model generates rationales at every token to explain the text that follows, and learns from whether those rationales improve its predictions.

The architectural detail that matters most for this article is the mixing head: the model blends its with-thought and without-thought next-token distributions, so thinking is a graded, learned, per-token decision rather than a mode you switch on. The authors point out the natural extension themselves — if the mixing weight were predicted before the thought, it could be used to allocate compute dynamically during generation. That is the research seed of everything in the next section.

The wider family is worth knowing exists: compressed chains of thought that distil reasoning into dense representations, self-distillation approaches that internalise the chain, and the striking result that even contentless pause tokens strictly increase the expressivity of constant-depth Transformers — which is section four's argument in its purest form, since a pause token carries no information at all and still buys depth.

The cost, stated plainly

Latent reasoning trades away the trace. Section five established that the trace is an imperfect window — reveal rates under 20% in the hint experiments — but an imperfect window is not the same as no window. If the intermediate state is an activation, there is nothing to read, nothing to monitor, and no way to notice that the model considered and discarded something you would have wanted to know about. There is now an explicit research agenda around treating chain-of-thought monitorability as a property worth protecting, on the grounds that it is both valuable and fragile.

Status check. This is active research, demonstrated on relatively small models and constrained task families. It is not a description of how any deployed commercial reasoning model works. As far as public documentation goes, o-series, R1, Gemini and Claude reasoning modes all emit token chains of thought. Read this section as a live question about where the field might go, not as the architecture of the thing in your API console.

Budgets and mode switching

Everything so far points at one conclusion: the amount of thinking a model does is a runtime parameter, not a property of the weights. That raises two engineering questions, and they are more different than the shared vocabulary suggests. Should the model think on this request at all? And if so, how much? Qwen3 is the best public worked example of both, because the technical report is unusually explicit about the mechanism, so it is worth going through in detail.

Why one model rather than two

The pre-Qwen3 arrangement was to ship two models: a chat model for ordinary requests and a separate reasoning model for hard ones. That is operationally awful. Two sets of weights in memory, two deployments, two evaluation suites, and a routing decision made by the application layer, which knows the least about the difficulty of the query. Qwen3's stated goal was to fold both modes into a single model, so switching becomes a request parameter instead of a deployment.

Getting there took a four-stage post-training pipeline. The first two stages build the thinking model: a long chain-of-thought cold start on carefully filtered math, code, logic and STEM problems with verified answers, then reasoning RL with GRPO over a small, deliberately hard set of query–verifier pairs — 3,995 of them, chosen to be unused in cold start, learnable, as challenging as possible, and broad in coverage. Over 170 RL steps the flagship model's AIME'24 score moved from 70.1 to 85.1.

The last two stages put the non-thinking mode back in. Stage three, thinking mode fusion, is continual supervised fine-tuning on a mixture of thinking and non-thinking data. The thinking half is generated by rejection sampling with the stage-two model itself, specifically so the extra SFT does not erode what RL just built. Stage four is general RL across more than twenty task types.

The template is the mechanism

Here is the part that is easy to skim past and is actually the whole trick. The two modes are two target formats, distinguished by a flag in the user message:

One template, two target formats

Thinking mode

user{query}/think
assistant<think>{reasoning tokens}</think>
{response}<|im_end|>

Non-thinking mode

user{query}/no_think
assistant<think>empty</think>
{response}<|im_end|>
The outer grammar never changes. The control token changes only whether the shared think block contains reasoning tokens or closes immediately.

Notice that the non-thinking target keeps the <think> block. It is just empty. That looks like a stylistic quirk and it is the load-bearing design decision, for two reasons.

First, every assistant turn now has identical structure, so the model never has to learn "sometimes there's a think block and sometimes there isn't" — only "sometimes it has content."

Second, and this is the practical payoff: a deployer can prefill an empty think block into the assistant turn. Once <think>\n\n</think> is already in the context, the model cannot think, because the closing tag has already been emitted. It is not being persuaded not to think; it is structurally past the point where thinking was possible. This is the difference between a soft and a hard control, and it matters:

Soft

The /think and /no_think flags are instructions the model was trained to obey. Qwen3's in-house mode-following benchmark went from 88.7 after mode fusion to 98.9 after general RL — excellent compliance, and still not a guarantee.

Hard

Prefilling the closed empty think block is a constraint on the token sequence, not a request. Compliance is 100% because non-compliance is not representable.

Two details worth knowing if you deploy this. Thinking is the default, so the pipeline includes thinking-mode examples with no flag at all. And in multi-turn conversations, flags are inserted randomly during training and the model is taught to follow the most recent one — so a /no_think three turns ago does not silently persist. Mode following is also an explicit reward target in stage four's general RL, alongside instruction following and format adherence. None of this comes free; it is trained.

The budget: interrupt, then salvage

Now the second question. A binary switch is coarse — most requests want neither zero thinking nor unbounded thinking. What you want is a dial.

The elegant part of Qwen3's answer is that they did not train a length-conditioned policy. They noticed that mode fusion produces a capability for free. Once a model has been trained on both full-thinking and zero-thinking targets, it has implicitly learned to handle the cases in between — to produce a final answer from incomplete deliberation. The report is explicit that this was not trained for; it emerged from having both distributions in the same model.

So the budget is enforced at decoding time, by interruption. Count thinking tokens as they are generated. When the count hits the user's threshold, stop sampling and splice in a stop-thinking instruction — the report gives it verbatim, and it reads roughly as the model telling itself that time is short and it will have to answer from what it has, followed immediately by the closing </think> tag. Generation then resumes, and the model writes its answer conditioned on the partial trace.

Read the phrasing of that injected string again, because it is doing real work. It is not a control token. It is a sentence that places the model in a context where "answer now from incomplete work" is the natural continuation — a distributional nudge rather than a mechanism. The model was never taught to stop at token 4,096; it was taught what it looks like to wrap up early, and the injection invokes that.

The consequence is worth stating plainly, because it is widely misunderstood: a thinking budget is not "deliberate for N tokens and then conclude." It is "deliberate until interrupted, then salvage." The model does not plan around the budget. It gets cut off. Whether that matters depends entirely on whether reasoning traces degrade gracefully when truncated, and empirically they mostly do — Qwen3 reports smooth, monotone improvement in AIME, LiveCodeBench and GPQA as the budget grows, which is exactly the curve you would want if truncation were benign.

Every control in this figure operates on the token stream, not the weights. That is the whole reason a single set of weights can serve a spectrum from zero to tens of thousands of thinking tokens.

Budget forcing: the same knob, backwards

If a budget is a decoding intervention, it should run in both directions, and s1 is the clean demonstration. Muennighoff and colleagues fine-tuned Qwen2.5-32B-Instruct on just a thousand carefully selected questions with reasoning traces, then added two decode-time interventions they call budget forcing:

Their illustrative example is perfect in its stupidity: the model counts the letter r in "raspberry," concludes there are two, and moves to stop. Suppress the delimiter, append "Wait," and it re-reads the word letter by letter and corrects itself to three.

The numbers make the argument. s1-32B with budget forcing exceeded o1-preview on competition math by up to 27 points on MATH and AIME24, and — the striking part — forcing extended thinking pushed it past its own unintervened ceiling, from 50% to 57% on AIME24. Same weights, same prompt. The only change was refusing to let it stop.

Take those two mechanisms together and the picture is clear. Qwen3 truncates by injection; s1 extends by suppression. Both are string surgery on the decode loop. Neither touches a parameter.

What the APIs actually expose

The industry has converged, and the convergence is on the same abstraction: reasoning effort as a per-request integer.

Anthropic's API takes a thinking block with type: "enabled" and budget_tokens. The budget must be less than max_tokens, it applies to the full thinking tokens rather than the summarised output shown to the user, and — an honest and telling caveat in the documentation — larger budgets can improve quality on hard problems but the model may not use the whole allocation, particularly above around 32k. It is a ceiling, not a quota.

Google's Gemini 2.5 exposes thinking_budget in its thinking config, with zero disabling thinking on the variants that support it, and thinking tokens billed at the ordinary output rate — which is the correct billing model and also a useful reminder of what you are paying for. Qwen3's Hugging Face chat template exposes enable_thinking=False, which does the empty-block prefill described above.

Three vendors, three mechanisms underneath, one surface. That convergence is the real signal in this section: the field has decided that reasoning depth belongs in the request, next to temperature and max tokens.

What a budget cannot do, and where this goes

Two limits are worth naming before moving on.

First, thinking is not universally beneficial, and a fixed budget will therefore be wrong somewhere. Qwen3's own long-context evaluation makes this concrete: on RULER they capped thinking at 8,192 tokens specifically to stop the model being verbose over long inputs, and thinking mode still scored slightly worse than non-thinking mode. Their hypothesis is that deliberation does not help pure retrieval and may actively interfere with it. That is a real result about a real model, published by the people who built it.

Second, unification costs something at the top. Comparing the flagship dense model across post-training stages, AIME'24 in thinking mode goes from 83.8 after reasoning RL to 81.4 after mode fusion and general RL, with LiveCodeBench moving similarly. The Qwen team names the trade-off explicitly and accepts it for versatility. Making one model do both jobs shaves a little off the specialist.

Which leaves the obvious question hanging. If a fixed budget is wrong for easy queries and wrong for retrieval and wrong for whatever comes next, the budget should not be fixed — the model should decide. Quiet-STaR's authors saw this in 2024 and said so: predict the usefulness of a thought before generating it, and the prediction becomes a compute allocator. Qwen3's intermediate-case handling is the accidental version. A growing line of work trains the decision directly, either as a mode choice or as a length-controlled policy.

That is where the series goes next. Once effort is a dial, the interesting question stops being "does it think" and becomes "how should the budget be spent" — sequentially, in parallel, on search, on verification. Test-Time Scaling is the whole post on that.

So does it think?

The honest answer is that the question is doing less work than it appears to, and the useful move is to break it into claims that can actually be settled.

Does the model use additional computation before answering? Yes, demonstrably and quantifiably. Every reasoning token is a forward pass; the serial depth of the computation grows linearly with trajectory length; the circuit-complexity separation says this is not a marginal effect but a change in what is computable at all.

Is that computation doing useful work, or is the trace decorative? Useful. Cut the budget and accuracy falls, smoothly and reproducibly, on hard benchmarks. Extend it past where the model wanted to stop and accuracy rises. The tokens are load-bearing.

Does the model deliberate in the sense of considering, evaluating and rejecting alternatives? The trace contains those moves. It also contained many of them before any reinforcement learning, which is the deflation from section six worth keeping in mind. What RL reliably did was make the behaviour productive and consistent rather than superficial — a real achievement, and a narrower claim than "the model learned to reflect."

Is the trace a faithful account of the computation? Often not. This is the claim that keeps failing, and it fails in the direction that matters most for oversight: models use information they do not verbalise, and outcome-based RL improves this only up to a plateau.

Put those together and here is what I think is defensible. "Thinking," as the word is used about these systems, names a change in the output distribution that buys serial compute and, along the way, produces text that reads like deliberation. The compute is real. The improvement is real. The text is a partial and sometimes misleading account of what produced it. Whether that assemblage deserves the word is a question about the word, and I do not think the answer changes anything you would do with the system.

What would change things is progress on two fronts. Interpretability that could tell us when a stated step corresponds to the computation rather than merely coinciding with it. And training that makes faithfulness saturate rather than plateau — because if latent reasoning turns out to be the efficient path, we will be trading away the last legible window we have at precisely the moment models get good enough that we want to look through it.

There is a smaller prediction I am more confident about. "Reasoning model" is probably not a lasting category. Qwen3 already folded both modes into one set of weights and exposed the difference as a request parameter; the other labs converged on the same surface within months. What we are heading toward is not models that think and models that don't, but models that estimate how much computation a request is worth and spend accordingly — at which point the interesting engineering question is not whether the model thinks, but whether its estimate is any good.

References

Grouped by topic. Every entry links to its primary source.

Eliciting and aggregating reasoning

Search, verification and refinement

Controlling the budget