Thinking moved inside the model. Access did not.
A model gets a fixed number of layers per token, so a long chain of reasoning has to be written down to be computed. Chain-of-thought prompting asked for that; agent architectures bought it one call at a time; thinking models now do it themselves. That forces a question the usual framing hides: which of the boxes we drew were reasoning, and which were something else?
- Why writing steps down adds depth: arithmetic, equations, LIS and edit distance
- The school worksheet as a model of chain, router, RAG, supervisor and multi-agent
- Which architectural moves thinking absorbed, and which it never can
- A 13-minute local test: three calls cost 1.25x for the same right answers
A model can only compute as far as it can write. Thinking models learned to write for themselves, and that changes which of our agent boxes still earn their place.
Remember the worksheets from school. A problem at the top, and underneath it a row of printed boxes. Box 1: write down what you know. Box 2: write down what you need to find. Box 3: do the calculation. Box 4: check your answer.
The teacher was not being fussy. Children who fill in the boxes get more problems right than children who jump straight to the answer, because the boxes make them go one step at a time. Showing your work works.
Language models turned out to be the same. In 2022, adding the sentence “Let’s think step by step” to a prompt took one model from 17.7% to 78.7% on a set of arithmetic word problems, and from 10.4% to 40.7% on a harder one.1 Nothing about the model changed. It was simply asked to fill in the boxes before writing the answer.
Then, from late 2024, came the thinking models. They do the step-by-step part on their own, before answering, without being asked. So we all say the obvious thing: a thinking model is a chain-of-thought model that thinks longer. And that is true.
Why the boxes work
Before we ask what happens to the worksheet, it is worth knowing why it worked at all. The answer is simpler than it sounds, and in 2023 it was proven.2
A language model writes one token at a time, a word or a piece of a word. To produce each token, it runs everything written so far through a fixed stack of layers, once. A few layers in a small model, around a hundred in a large one. However hard the question, that stack is the whole budget of thinking the model gets before it commits to the next token. It is a student allowed a fixed number of seconds per digit, and no scratch paper.
Some problems fit in that budget no matter how big they get. Counting votes is one: hand the ballots to a thousand counters, then add up their subtotals. A few rounds, however many ballots. Other problems are chains, where every step needs the answer to the step before. Take this:
(7 + 5) ÷ (6 + 4 × 3 − 2 × 7)
We cannot divide until the second bracket is finished, and we cannot finish the bracket until the multiplications are done. Make the expression longer and the chain gets longer. A fixed stack of layers can only follow a chain so far.
Feng and colleagues turned that intuition into theorems. They took four ordinary tasks. Two are school mathematics: evaluating arithmetic expressions and solving systems of linear equations. Two are textbook dynamic programming. Longest increasing subsequence asks for the longest run of numbers we can pick from a list, left to right, each bigger than the last; in 5, 2, 8, 6, 3, 6, 9, 7 it is four (2, 3, 6, 9). Edit distance asks for the fewest insertions, deletions and replacements that turn one word into another; kitten into sitting takes three.
Then they asked what a transformer with a fixed number of layers can do if it must write the answer immediately. For arithmetic and equations the answer is bleak: as the input grows, the model would have to grow faster than any polynomial in the length of the input. For dynamic programming in general, they found a problem of the same family that no such model of reasonable size can answer directly. The proofs rest on an assumption computer scientists widely believe and have not proven: that some problems really are sequential, and no fixed number of parallel rounds can shortcut them.
Now let the model write its steps down:
(7 + 5) ÷ (6 + 4 × 3 − 2 × 7)
= 12 ÷ (6 + 4 × 3 − 2 × 7)
= 12 ÷ (6 + 12 − 2 × 7)
= 12 ÷ (18 − 2 × 7)
= 12 ÷ (18 − 14)
= 12 ÷ 4
= 3
Nothing on any line is hard: one small operation, and a copy of everything else. The trick is where each line goes. Every token the model writes is fed back in as input, so the next token gets another full pass through the layers. The depth that matters is no longer the number of layers. It is the number of layers times the number of steps written down. The paper proves that a fixed transformer of five layers can evaluate arithmetic expressions of any length this way, and four layers solve linear equations by eliminating one variable per line. Dynamic programming works the same way: the steps are the cells of the table, each filled in from cells already written.
Then they trained small transformers on all four tasks, once on bare answers and once on worked solutions, and tested them on the hardest sizes:
| Task, hardest size tested | Answer directly, 5 layers | Write the steps, 3 layers |
|---|---|---|
| Arithmetic, 6 operators | about 50% | about 100% |
| Linear equations, 5 variables | about 0% | about 100% |
| Longest increasing subsequence, 100 numbers | about 55% | about 100% |
| Edit distance, strings of about 20 | about 64% | about 100% |
Values read off the paper’s Figure 2 and rounded.
A shallower model that writes its steps beats a deeper model that doesn’t, on every task. And the direct models behaved exactly as the theory predicts: extra layers helped them, and longer inputs hurt them. The step-writing model trained on expressions of up to 15 operators still did well on 16 to 18, which suggests it learned the procedure, not the answers.
A fair reading has limits. These are small models trained from scratch on synthetic tasks, and the theorems describe what a fixed depth can express, not what a large model does in practice. A hundred-layer model handles short chains in its head; the argument bites when the chain is longer than the stack. But the direction is the point. Writing the work down is not about showing it. It is about giving the work somewhere to happen.
That is also the obvious sentence at full strength. A thinking model was trained, not prompted, to write its own scratch before answering, as much as the problem needs. Longer thinking is literally more depth. “A chain-of-thought model that thinks longer” is not a slogan. It is the mechanism.
It also explains what we built in between. For a year or two, models could not be trusted to write long scratch on their own. So engineers bought the extra steps from outside, in code, one call at a time. That is what the classic agent architectures are:
- A chain is a worksheet with numbered boxes. Plan, then solve, then check, each step a separate call, in an order an engineer fixed in advance.
- A router is the line that says “if your answer to question 1 is yes, go to page 3.”
- RAG is the formula sheet stapled to the back.
- A supervisor is the teacher who reads each box, hands it back, and says “do this one again.”
- Multi-agent is the group project: one problem, split across several desks.
Different frameworks use different names. Anthropic’s catalogue says prompt chaining, routing and orchestrator-workers,3 and LangGraph says chain, router and supervisor. The shape is the same: “LLMs and tools are orchestrated through predefined code paths.”3
Now the student has changed, and the reasoning patterns that came out of training thinking models are “self-reflection, verification, and dynamic strategy adaptation.”4 Look at that list again. It is box 4, the supervisor, and the router.
So here is the question the obvious sentence cannot answer, even at full strength. Let us change one thing it quietly keeps fixed: who draws the boxes. We have a student who now does the worksheet in their head. What happens to the worksheet?
Two answers we cannot accept
Take the obvious sentence literally, and there are two ways to read it.
Reading one: thinking is just longer chain-of-thought, so nothing changes. Keep the chain. But follow what happens. We hand the thinking model box 1: “make a plan.” It thinks through the whole problem, plans, and very likely solves it privately, then writes down only the plan, because that is all we asked for. Box 2 is a fresh call. The model re-reads the problem, thinks through it again, and executes a plan it did not choose in the context it would have wanted. Box 3 does it a third time. We are paying a student to solve the problem three times, and forcing them to follow our order of steps instead of their own. That is not “nothing changes.” That is paying extra for a worse method.
Reading two: thinking replaces the architecture, so delete all of it. Hand the student a blank page. But the problem mentions a constant that is only on the formula sheet. No amount of thinking produces a value the student never saw. Extra steps over the same page cannot produce a value that is not on the page; they only produce a more carefully argued guess. And the group project did not exist because each student was slow at reasoning. It existed because one desk could not hold every page at once, and because four hands write faster than two.
We cannot accept either reading. The first pays for thinking twice. The second throws away things thinking never supplied. So the obvious sentence was carrying an assumption nobody stated: that every box on the worksheet was there for the same reason.
It wasn’t. The boxes were there for two different reasons, and only one of them moved inside the model.
| Architecture | The move it froze into code | Did thinking absorb it? |
|---|---|---|
| Chain | Decompose into steps, in a fixed order | Yes, and the model’s own order adapts to the problem. What stays: a checkpoint where code must run between steps |
| Router | Choose the approach | Mostly. Choosing the method moved inside. Choosing the price tier, or which tools a request may touch, did not. Those are decisions about cost and permission, not reasoning |
| RAG | Look it up | No. Thinking cannot recall what was never in the context |
| Supervisor | Check the work, send it back | The checking, yes. Self-verification is exactly what training produced. What stays: a fresh context for the checker, one that did not write the answer it is judging |
| Multi-agent | Split across desks | No. Separate context windows and parallel calls are capacity, not thought |
Read down the last column and a rule falls out, and the mechanism from the paper tells us why. Writing tokens buys a model more steps of computation. That is all it buys. Decomposing, choosing and checking are steps, so thinking absorbed them. A formula sheet is information, a second desk is capacity, a signature is authority, and no number of extra steps produces any of them. The boxes that held a reasoning step can come off the worksheet. The boxes that held a formula sheet, a second desk, or a signature stay. Thinking moved inside the model. Access did not.

A better reader still needs the key to the room where the book is kept. Photo by Susan Holt Simpson on Unsplash.
Extra steps are all that thinking buys. The boxes that carried information, capacity or accountability were never the model’s to take.
Counting the cost, together
Reading one, “keep the chain”, makes a prediction we can check at home. If a thinking model solves the whole problem every time we call it, then splitting the work into three calls should cost about three times the thinking, and buy no extra correct answers.
Let us test it on our own machine: a small open model, five problems, no API
key, no bill. Budget an hour; the run itself took thirteen minutes on a
laptop graphics card. Install Ollama, then run
ollama pull qwen3:1.7b and pip install ollama. Qwen3 is a thinking model:
it writes its scratch first, then its answer, and the 1.7-billion-parameter
version fits on an ordinary laptop.
Step one: problems we already know the answer to. We write little warehouse stories. Crates arrive, crates ship, and sometimes crates get strapped into pallets with the leftovers thrown away. That last move is a division that drops the remainder, which is exactly where a hurried reader slips. The program keeps the true count while it writes the story, so grading is exact.
import random
def make_problem(rng):
crates = rng.randint(20, 80)
story = [f"A warehouse opens Monday with {crates} crates."]
for day in ["Monday", "Tuesday", "Wednesday", "Thursday"]:
move = rng.choice(["trucks", "ship", "pallets"])
if move == "ship" and crates > 10:
n = rng.randint(1, crates // 2)
crates -= n
story.append(f"On {day}, {n} crates are shipped out.")
elif move == "pallets" and crates >= 15:
size = rng.randint(3, 5)
crates //= size
story.append(f"On {day}, every {size} crates are strapped into one pallet "
f"and the leftovers are thrown away. From then on, "
f"each pallet counts as one crate.")
else:
trucks, each = rng.randint(2, 6), rng.randint(5, 15)
crates += trucks * each
story.append(f"On {day}, {trucks} trucks arrive with {each} crates each.")
story.append("How many crates are in the warehouse at the end of Thursday?")
return " ".join(story), crates
rng = random.Random(4444)
problems = [make_problem(rng) for _ in range(5)]
print(problems[0])
The first problem it prints is: “A warehouse opens Monday with 53 crates. On Monday, every 4 crates are strapped into one pallet and the leftovers are thrown away…” The answer is 13. Worth doing once by hand, with a pencil. We will need a few boxes of our own.
Step two: ask the model two ways. Both ways use the same thinking model with thinking switched on. The only difference is who draws the boxes. In the first, the model gets the problem and does everything itself. In the second, we draw the boxes for it: one call to plan, one to solve, one to check.
from ollama import chat
MODEL = "qwen3:1.7b" # any thinking model you have pulled
def ask(prompt):
reply = chat(model=MODEL, messages=[{"role": "user", "content": prompt}],
think=True, options={"num_ctx": 12288})
return reply.message.content, reply.eval_count
FINAL = "End with a line of the form ANSWER: <number>."
def one_call(problem):
return [ask(f"{problem}\n\n{FINAL}")]
def three_calls(problem):
plan, t1 = ask(f"{problem}\n\nList the steps to solve this. Do not solve it.")
work, t2 = ask(f"{problem}\n\nPlan:\n{plan}\n\nCarry out the plan. {FINAL}")
check, t3 = ask(f"{problem}\n\nSolution:\n{work}\n\nCheck every step and fix any mistake. {FINAL}")
return [(plan, t1), (work, t2), (check, t3)]
eval_count is how many tokens the model generated for one reply, thinking
included. That is our cost. Locally we pay it in minutes instead of dollars,
but it is the same quantity a hosted API bills. And thinking is not cheap: the
4-billion-parameter Qwen3, asked what 17 + 25 is, wrote 860 words of scratch
first. Two settings keep the run honest. num_ctx gives the scratch room;
at Ollama’s default of 4,096 tokens a long think gets cut off mid-thought. And
before running everything, call ask once and time it. If one call takes
more than two minutes, your machine is running the model on its processor
rather than its graphics card; try a smaller model.
Step three: run both and count. For each way of asking, we add up the
tokens, count the right answers, and divide. One practical wrinkle: small
models trained on maths competitions often ignore our ANSWER: line and write
\boxed{13} instead, so the parser accepts both.
import re, time
def final_answer(text):
found = re.findall(r"(?:ANSWER[:*\s]*|\\boxed\{)(-?\d+)", text)
return int(found[-1]) if found else None
for name, method in [("one call", one_call), ("three calls", three_calls)]:
correct = tokens = 0
start = time.time()
for problem, truth in problems:
steps = method(problem)
tokens += sum(count for _, count in steps)
correct += final_answer(steps[-1][0]) == truth
minutes = (time.time() - start) / 60
print(f"{name:12} correct {correct}/{len(problems)} "
f"tokens per correct answer {tokens / max(correct, 1):,.0f} {minutes:.1f} min")
Here is what came back on my laptop:
| Right answers | Tokens | Tokens per right answer | Time | |
|---|---|---|---|---|
| One call | 3 of 5 | 25,938 | 8,646 | 6.1 min |
| Three calls | 3 of 5 | 32,443 | 10,814 | 7.1 min |
qwen3:1.7b through Ollama 0.32.15 and ollama 0.6.2 for Python, on an
RTX 3050 Ti laptop GPU with 4 GB, default sampling, 25 September 2026.
The chain cost a quarter more and bought no extra right answers. But look at the number we predicted: three times the thinking. It was 1.25 times, and the log of every call shows why. The planning call did almost all the work, around 3,600 tokens on average, and it usually reached the final number even though we told it not to solve anything. The solve and check calls that followed averaged about 1,000 tokens each. They mostly copied.
Two more things in that log matter. The check step never changed an answer: five times out of five it agreed with whatever the solve step had written, including both wrong ones. A checker that reads the answer before judging it is not much of a checker. And the two ways got different problems wrong. The chain fixed one problem the single call missed and broke one it had solved. Run the same problem twice and a small model will sometimes answer differently, so five problems can show us the shape of the cost, not a winner.
Your numbers will differ. Here is how to read them:
- Three calls cost more for the same number of right answers. That is what we got. The boxes bought nothing the model was not already doing.
- They cost about the same. Reading one was less wrong than it looked, and the chain has to earn its place some other way.
- Three calls get more right, again and again. For your model and your problems, the boxes still carry steps the model does not take on its own. Keep them.
A 1.7-billion-parameter model on a laptop is not the model behind your product, and five problems is not a benchmark. The point of the hour is to see, on your own screen, what one extra box costs, and to catch a checker agreeing with every answer it is shown.
What the new picture hides
The division table has a blind spot, and it is the most important box on the original worksheet.
The teacher did not print the boxes only to help the student think. The boxes also let the teacher see the thinking. When the answer was wrong, the teacher could point at box 2 and say “here.” A chain gives us the same thing: every intermediate output is a string we can log, read, and test.

Someone is clearly at work in there. What they are doing is another matter. Photo by Valentin on Unsplash.
A thinking model does its work behind frosted glass. The raw reasoning is usually not returned at all, only a summary or nothing. And where reasoning is visible, it is not a faithful record. In one study, models given a hint that changed their answer mentioned the hint in their reasoning only 25% of the time for one model and 39% for another.5 The worksheet in the student’s head is not just hidden from us. It is not guaranteed to be the worksheet that was actually used.
So there is a third kind of box the table missed. Besides reasoning and access, some boxes exist for audit. When we delete a chain because the model now plans for itself, we also delete the only place where a person could see the plan. For low-stakes work that is a good trade. For work where someone has to explain a decision afterwards, the box stays, and it stays on purpose, not because the model needs it.
Our experiment hides something too. It measures tokens on problems with one right number. It says nothing about the tasks where an agent’s intermediate steps are the only thing a human can check, which are the tasks where the architecture matters most.
Back to the worksheet
A student who can do the worksheet in their head does not need the printed boxes to think. We should stop printing those boxes, because they now cost more than they help.
But the same student still needs the formula sheet stapled to the back. They still get a second desk when the problem does not fit on one. And the teacher still wants to see the work, only now the teacher has to ask for it deliberately rather than getting it for free.
Anthropic’s own advice on agents was already “finding the simplest solution possible, and only increasing complexity when needed.”3 Thinking models changed what counts as simple. The chain, the router and much of the supervisor were reasoning we did on the model’s behalf. The retrieval, the second desk and the signature were never ours to hand over.
References
- Kojima et al., Large Language Models are Zero-Shot Reasoners, NeurIPS 2022
- Feng et al., Towards Revealing the Mystery behind Chain of Thought: A Theoretical Perspective, NeurIPS 2023
- Anthropic, Building effective agents, 19 December 2024
- DeepSeek-AI, DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning
- Anthropic, Reasoning models don’t always say what they think, 3 April 2025
- Ollama and Qwen3, the local runtime and model used in the experiment
Notes
Keep exploring
For the loop that runs around a reasoning model once it acts in the world, read The Reasoning Loop Is a Game Loop That Learned to Think. For the audit box as a working design, with a human approving the steps that are hard to undo, read Your Agent Is a Contractor, Not a Chatbot.
Hero photo: Yuriy Vertikov on Unsplash. Article photos: Susan Holt Simpson and Valentin on Unsplash.
Footnotes
-
The model was InstructGPT (text-davinci-002); the benchmarks were MultiArith and GSM8K. Wei et al. (2022) introduced chain-of-thought prompting with worked examples; Kojima et al. showed that the single sentence was enough. ↩
-
The impossibility results (Theorems 3.1 and 3.2) are for log-precision transformers of bounded depth and assume TC⁰ ≠ NC¹, the complexity-theory form of “some problems are inherently sequential”. The constructions (Theorems 3.3 and 3.4) use depth 5 and 4, with a hidden size that does not grow with the input. The direct-answer counterexample for dynamic programming is context-free grammar membership (Theorem 4.8). The experiments use hidden size 256 and 4 heads, five runs per setting; the accuracies in the table above are read off the paper’s Figure 2 and rounded. ↩
-
The workflow patterns named there are prompt chaining, routing, parallelization, orchestrator-workers and evaluator-optimizer, distinguished from agents, “systems where LLMs dynamically direct their own processes and tool usage.” ↩ ↩2 ↩3
-
The quoted phrase is from the paper’s current abstract. ↩
-
The two models were Claude 3.7 Sonnet (25%) and DeepSeek R1 (39%), averaged across hint types. ↩