Article 3 of 6 · September 2026
Why "show your work" is physics, not manners
Article 3 of 6 · the one rule that makes a model smarter, and why it works · after Andrej Karpathy
This article retells one section of Andrej Karpathy's Deep Dive into LLMs like ChatGPT, the one he titles "models need tokens to think". It is short, it is his, and it is the single most practical thing in the whole lecture. If you read only one article in this series, read this one.
1. A fixed amount of thinking per word
Start with a fact about the machine that nobody tells you in the chat window.
Every word the model writes costs roughly the same amount of thinking, and he is careful about the word roughly: a longer conversation makes each word a little more expensive, but not by much. Inside, the text passes through a stack of layers, and Karpathy's point is that the stack is finite and fixed. His toy model has three layers; a big production model has on the order of a hundred. Whatever the number, each new word gets one pass through that stack and no more. There is no way to pause and think harder before a hard word.
That one fact has a consequence that changes how you should ask questions. Karpathy puts it plainly: you cannot cram a whole problem into a single word. If an answer requires several steps, the steps have to be spread across several words, because each word can only carry a small amount of work.
2. The apples, two ways
His example is a school problem. Emily buys three apples and two oranges. Each orange costs two dollars. The total is thirteen dollars. What does an apple cost?
Two answers, both correct, both ending in three dollars.
The first says: "The answer is $3." Then it explains why. The second says: the oranges cost four dollars, thirteen minus four is nine, nine divided by three is three, so an apple costs three dollars.
Karpathy asks his audience to pause and think about which one is worse, and why. Then he explains. In the first answer, all of the arithmetic had to happen inside the single word that produced "3", because the model writes left to right and that word came first. Everything after it is a story told after the fact, since the answer is already sitting on the page. In the second answer the work is spread out: every step is small enough for one word, and by the time the model reaches the end, the earlier steps are on the desk in front of it, where it can read them.
Those intermediate steps are not written for you. In his words: "these are not for you, these are for the model". If the model does not write them, it cannot reach the answer.
Try it now. Give the apples problem and ask for the answer in a single word. With these small numbers, it managed in his run. Now make the numbers nasty. Karpathy uses 23 apples and 177 oranges. Ask for a one-word answer and it gets it wrong; his run produced 5. Then say "never mind the limit, solve it as usual" and it works through the steps and reaches 7. Same model, same question. The only difference is how many words it was allowed to think in.
3. Counting dots
The same physics explains a failure that looks like stupidity.
Karpathy pastes a field of dots into the chat and asks how many. The model answers 61. The real count is 177. Why so wrong? Because the model tried to answer in a single word, and counting a long string of dots is far too much work for one word. Worse, the dots arrive as chunks, not as individual dots, so the model is guessing the count of chunks whose contents it cannot see.
Then he adds two words: "use code". Now the model does not count. It copies the dots into a tiny program, and the program counts. The answer comes back as 177. His explanation is worth remembering because it is a general rule: the model is bad at counting and very good at copying, and a program is very good at counting. Break the job so that each part goes to the thing that is good at it.
The same applies to spelling. Ask it to print every third letter of "ubiquitous" and it fails, because it sees three chunks, not ten letters. Ask it to use code and it gets it right. The famous question about the r's in strawberry is the same failure twice over: letters it cannot see, and counting it cannot do in one word.
4. The hole in the cheese
Not every failure has such a clean cause, and Karpathy is honest about that.
For a long time, models insisted that 9.11 is bigger than 9.9. Ask several times and the answer flips. He says it is a head-scratcher even for people who know how the models work, and he passes on what a research team told him, with the caveat that he has not read their paper: inside the model, the neurons that respond to Bible verses light up. In a Bible, chapter 9 verse 11 does come after 9 verse 9. The model gets distracted by a pattern that has nothing to do with numbers.
His picture for this is Swiss cheese. The model is excellent across an astonishing range of subjects, and then, in some unpredictable spots, there is a hole. It can solve olympiad mathematics and then fail to compare two decimals. You do not want to fall through a hole without noticing. His advice is the plainest in the lecture: check their work, use them as tools, and be responsible for the product of your work yourself.
5. What the thinking models did with this
Here is the twist that turns a limitation into a feature.
In article 2, the third stage of training was practice problems: the model tries thousands of solutions, and the ones that reach the right answer are reinforced. When labs ran this at scale, the model discovered on its own what this article has been saying. Its answers grew longer. It started to write inner monologues: let me re-check that, wait, that is not right, let me try another way. Karpathy shows the traces. Nobody wrote them; the model found that spreading its thinking over many words makes it right more often. That is what a "thinking" model does before it hands you a clean answer.
So "show your work" was never a teacher's manners. It is what the machine needs, and given the chance to practise, the machine chose it.
Many products now show you only a summary of that working, or nothing at all. The habit still applies: ask for the steps, and when a product will not show them, treat the clean answer as unchecked.
What to do tomorrow
- Never ask for a bare answer to anything with steps. Ask it to work through the problem, or use a thinking model and let it work through it itself.
- Counting, arithmetic, spelling, lists to be checked: say "use code". Let a program do the part the model cannot.
- When it is suddenly, absurdly wrong, you found a hole in the cheese. Re-ask a different way, hand the job to a tool, or check it yourself. Do not conclude it is stupid, and do not conclude it is right next time.
- You own the result. It is a tool that thinks a fixed amount per word. The responsibility for the answer stays with you.