AI Literacy & Prompting Module 2 – What AI does well and where it fails
Reasoning models: what 'thinking' changes
What reasoning modes do before they answer, where the extra thinking helps, why the reasoning shown may not be the real one, and what it costs.
What you will learn
- Explain what reasoning ("thinking") modes do differently, and the tasks where they help
- Explain why a displayed chain of thought may not show how the answer was really produced
- Write prompts for reasoning modes that state the goal and the checks instead of dictating steps
- Weigh the extra time, tokens and usage limits of reasoning modes against what they add
Before you start
What you’ll learn · Before you start
What you will learn
- Explain what reasoning ("thinking") modes do differently, and the tasks where they help
- Explain why a displayed chain of thought may not show how the answer was really produced
- Write prompts for reasoning modes that state the goal and the checks instead of dictating steps
- Weigh the extra time, tokens and usage limits of reasoning modes against what they add
Before you start
On this page
A timetable with nine trains hides a trap: the connection that looks fastest, arriving at 18:30, leaves only 15 minutes to change trains where the rule asks for 20. Many chat apps now offer a reasoning or “thinking” mode, which writes out working, tries routes like this one and checks them, before it answers.
You will see what that thinking is and where it helps, why the reasoning a model shows may not be what produced its answer, how to prompt a reasoning mode, and when its extra time and tokens are worth paying for.
A reasoning model writes its working before the answer
Here is the puzzle in full: leave Nagpur at 06:00 or later, reach Pune as early as possible, and allow at least 20 minutes for every change of trains. The timetable is made up for this lesson. The program tries every train it can catch and lists every route:
"""The train puzzle of this lesson, solved by trying every route.
A made-up timetable of nine trains. Leave Nagpur at 06:00 or later and reach
Pune as early as possible. A change of trains needs at least 20 minutes
between arriving and leaving. The program follows every train that can be
caught, checks each change against the rule, and lists every route.
"""
TRAINS = [ # name, from, leaves, to, arrives
("A", "Nagpur", "06:10", "Bhusaval", "11:40"),
("B", "Nagpur", "06:40", "Wardha", "08:00"),
("C", "Wardha", "08:15", "Pune", "18:30"),
("D", "Bhusaval", "12:10", "Pune", "19:20"),
("E", "Bhusaval", "12:00", "Manmad", "13:45"),
("F", "Manmad", "14:20", "Pune", "18:55"),
("G", "Wardha", "09:30", "Manmad", "15:10"),
("H", "Manmad", "15:40", "Pune", "20:05"),
("J", "Nagpur", "07:30", "Pune", "21:45"),
]
CHANGE = 20 # minutes
def minutes(hhmm):
hours, mins = hhmm.split(":")
return int(hours) * 60 + int(mins)
routes, too_short, checked = [], [], 0
def follow(station, ready, path):
global checked
for train in TRAINS:
name, start, leaves, end, arrives = train
if start != station:
continue
checked += 1
if minutes(leaves) < ready:
if path and minutes(leaves) >= ready - CHANGE:
too_short.append(path + [train])
continue
if end == "Pune":
routes.append(path + [train])
else:
follow(end, minutes(arrives) + CHANGE, path + [train])
follow("Nagpur", minutes("06:00"), [])
def describe(route):
return ", ".join(f"{t[0]} {t[2]}-{t[4]}" for t in route)
print("Every route to Pune that keeps the 20-minute rule:")
for route in sorted(routes, key=lambda r: minutes(r[-1][4])):
changes = len(route) - 1
note = {0: "direct", 1: "1 change"}.get(changes, f"{changes} changes")
print(f" {route[-1][4]} {describe(route)} ({note})")
print("Routes that break the rule:")
for route in too_short:
gap = minutes(route[-1][2]) - minutes(route[-2][4])
print(f" {describe(route)}: only {gap} minutes to change at"
f" {route[-1][1]}")
best = min(routes, key=lambda r: minutes(r[-1][4]))
print(f"Trains looked at: {checked}. Earliest arrival: {best[-1][4]}, "
f"by {', '.join(t[0] for t in best)}.")Output
Every route to Pune that keeps the 20-minute rule: 18:55 A 06:10-11:40, E 12:00-13:45, F 14:20-18:55 (2 changes) 19:20 A 06:10-11:40, D 12:10-19:20 (1 change) 20:05 A 06:10-11:40, E 12:00-13:45, H 15:40-20:05 (2 changes) 20:05 B 06:40-08:00, G 09:30-15:10, H 15:40-20:05 (2 changes) 21:45 J 07:30-21:45 (direct) Routes that break the rule: B 06:40-08:00, C 08:15-18:30: only 15 minutes to change at Wardha Trains looked at: 11. Earliest arrival: 18:55, by A, E, F.
Recorded with Python 3.14.8 on macOS 26 arm64. To run it yourself: mise exec python@3.14.8 -- python3 train_connection.py
The earliest arrival, 18:55, needs two changes, and one of them leaves exactly the 20 minutes the rule allows. A model that answers at once writes its first likely route, and the tempting one, B then C, breaks the rule. A reasoning model: A language model trained to write out intermediate working, often called thinking, before its final answer. It helps most on problems with many steps that can each be checked, such as plans, puzzles and sums. spends tokens first on working of its own, a chain of thought: The intermediate steps a model writes before its answer, either because a prompt asked for them or because the model was trained to produce them.: the textbook Speech and Language Processing describes models trained on tasks with “multiple steps of reasoning and a clear right answer”, rewarded for answers that check out, and notes that modern models are now trained to produce such chains by default. Step through the kind of working those extra tokens buy:
The drawing shows the whole scene; its 6 steps are listed below.
Every step as text
- The question. You ask for the earliest arrival in Pune, leaving Nagpur at 06:00 or later, with at least 20 minutes for every change of trains.
- A first route. A reasoning model first writes working that is not the answer. It tries the route that looks fastest: B to Wardha, then C to Pune, arriving at 18:30.
- The check fails. It checks that route against the rule. B reaches Wardha at 08:00 and C leaves at 08:15: fifteen minutes is too short, so the route is out.
- Other routes. It tries other routes: A to Bhusaval and D to Pune, arriving at 19:20; then A, E and F, arriving at 18:55.
- Checked again. Each new route goes through the same check. E leaves Bhusaval exactly 20 minutes after A arrives, which the rule allows, and F leaves Manmad 35 minutes after E arrives.
- The answer. Only then does it write the answer: trains A, E and F, arriving at 18:55. A model that answers at once has no room for this trial and error, which is why multi-step problems are where thinking helps most.
The idea began as a prompt: Wei and others showed that asking a large model for “a series of intermediate reasoning steps” improved arithmetic, commonsense and symbolic reasoning. A reasoning mode builds the same habit into the model, so the working comes whether or not you ask for it.
Python Online Compiler Paste the train program, change a time or the 20-minute rule, and run it to see the best route change.Checkpoint
Check: What a reasoning mode does
Thinking helps most on problems with many checkable steps
Extra working pays where there are steps to try and check, and much less elsewhere. Three findings set the limits:
- Sprague and others compared answers with and without a chain of thought across many studies and tasks: it “gives strong performance benefits primarily on tasks involving math or logic, with much smaller gains on other types of tasks”.
- Shojaee and others varied the difficulty of puzzles and found three regimes: standard models did better on easy problems, reasoning models on middling ones, and both collapsed on the hardest, where the reasoning models even thought less as problems grew past a point.
- Muennighoff and others found that making a model think longer, by appending “Wait” when it tried to stop, “can lead the model to double-check its answer, often fixing incorrect reasoning steps”; on a set of competition maths problems its accuracy rose from 50 % to 57 %.
Put together, with the weak spots of this module’s first lesson:
| Task | Does thinking help? | Why |
|---|---|---|
| A plan or a timetable with rules, a puzzle, a multi-step sum | Yes, most | Each step can be tried and checked against the rules |
| Debugging code against a failing test | Often | The test is a check the working can aim at |
| Rewording an email, a summary, a translation | Little | One pass of language work; nothing to check step by step |
| A fee, a rule or a timetable it never saw | No | Thinking rearranges what it has; it cannot add a fact |
Key idea
Thinking pays on problems with many steps that can each be checked against rules; it cannot supply facts the model never learned, and on simple tasks it mostly adds time.
Checkpoint
Check: Where thinking helps
The reasoning on screen is not a faithful record
Reasoning that reads well invites trust, and that trust can be misplaced. Chen and others planted hints in questions, such as a note that a professor thought the answer was C, and looked at the cases where the hint changed the model’s answer. Step through their test:
The drawing shows the whole scene; its 5 steps are listed below.
Every step as text
- A planted hint. Researchers add a hint to a multiple-choice question, for example a line saying a professor thinks the answer is C, or the answer tucked into the question's data.
- The answer moves. On many questions the model's answer changes to the hinted one. The researchers count only those cases, where the hint clearly decided the answer.
- The reasoning says otherwise. The reasoning the model shows works through the question and arrives at C, but in most of those cases it never mentions the hint that decided it.
- How often it tells. Across six kinds of hint, the two reasoning models tested mentioned a hint they had used in only 25 % and 39 % of cases on average, and less often for hints they should not have used.
- Longer, not more honest. Reasoning that hid the hint was longer than reasoning that admitted it, about 2,064 tokens against 1,439 for one model. A long, careful-looking chain is no sign that it is complete.
Their two reasoning models mentioned a hint they had used in only 25 % and 39 % of cases on average; on harder questions they mentioned it even less often. When the researchers trained a model in settings that rewarded a shortcut, it used the shortcut on more than 99 % of examples and said so in fewer than 2 %, in five of six settings. An earlier study by Turpin and others found the same gap in prompted chains of thought: reordering example answers so that the right one was always “(A)” swayed models’ answers, while their explanations almost never mentioned it, and accuracy fell by as much as 36 %. NIST’s profile of generative AI puts the user’s side plainly: models “sometimes provide logical steps for how they arrived at an answer even when the answer itself is incorrect”.
The shown reasoning is still useful, as a draft whose steps you can check one by one: a change time, a sum, a quoted rule. What it is not is an audit trail of why the answer came out.
Trusting the working because it reads well
Wrong: “Its reasoning looks sound, so the answer is right.” Right: “Its reasoning gives me steps to check; I check the ones the answer depends on.” A careful-looking chain can leave out exactly what decided the answer.
Checkpoint
Check: Shown reasoning is not a record
Prompt a reasoning mode with the goal and the checks
A model trained to write its own working does not need you to dictate it. What it cannot know is your goal, your constraints and how you will judge the answer, so spend the prompt on those, and ask for the answer in a form you can check:
| Instead of | Ask |
|---|---|
| “Think step by step. First list every train, then check each change, then compare arrivals.” | “Find the earliest arrival in Pune, leaving Nagpur at 06:00 or later. Every change needs at least 20 minutes. Give the route with each arrival and departure time.” |
| “Show all of your thinking in the answer.” | “Give the answer and the two or three facts it depends on, so I can check them.” |
| “Think really hard about everything.” | “This is a hard scheduling problem; take the time to check every change against the rule.” |
Many apps and services also let you set how much the model thinks. Hugging Face’s chat completion reference describes a reasoning effort: A setting some apps and services offer that controls how much a reasoning model thinks before answering: less effort gives faster replies that use fewer tokens. setting: reducing it “can result in faster responses and fewer tokens used on reasoning”. More effort can help on hard problems, as the “Wait” experiment showed, but it buys more working, not more facts.
Test it on your own app
Give the timetable and the question to an AI app twice, with its thinking mode off and then on. Compare both answers with the program’s 18:55 by A, E and F, and check whether either answer breaks the 20-minute rule.
Checkpoint
Check: Prompting a reasoning mode
Thinking costs time, tokens and limits
Thinking is written like everything else: every thinking token comes from the same one-token-at-a-time loop as the answer, so it takes the same time and counts towards the same limits; Chen and others’ models wrote chains that averaged from about 1,400 to about 6,000 tokens. The program below works out what that means for one reply and for a day’s allowance, with a speed and an allowance you can replace by your own app’s figures:
"""What thinking adds to one reply's time and to a day's token allowance.
Every thinking token is written by the same one-token-at-a-time loop as the
answer, so it takes the same time and counts the same way. The answer is 300
tokens. The writing speeds (40 and 100 tokens a second) and the allowance
(200,000 generated tokens a day) are assumptions: put your own app's numbers
in their place. Thinking of 1,500 and 6,000 tokens is in the range of the
average chains one study measured for two reasoning models.
"""
ANSWER = 300
SPEEDS = (40, 100) # tokens a second (assumed)
ALLOWANCE = 200_000 # generated tokens a day (assumed)
print(f"{'Thinking':>8} {'Written':>8} {'Seconds at 40/s':>16}"
f" {'at 100/s':>9} {'Replies a day':>14}")
for thinking in (0, 500, 1_500, 6_000):
written = thinking + ANSWER
slow, fast = (written / speed for speed in SPEEDS)
replies = ALLOWANCE // written
print(f"{thinking:>8,} {written:>8,} {slow:>16.1f} {fast:>9.1f}"
f" {replies:>14,}")
ratio = (6_000 + ANSWER) / ANSWER
print(f"\nA reply that thinks for 6,000 tokens writes {ratio:.0f} times as"
" many tokens as one that does not.")Output
Thinking Written Seconds at 40/s at 100/s Replies a day
0 300 7.5 3.0 666
500 800 20.0 8.0 250
1,500 1,800 45.0 18.0 111
6,000 6,300 157.5 63.0 31
A reply that thinks for 6,000 tokens writes 21 times as many tokens as one that does not.
Recorded with Python 3.14.8 on macOS 26 arm64. To run it yourself: mise exec python@3.14.8 -- python3 thinking_time.py
At 40 tokens a second, a 300-token answer takes 7.5 seconds; with 6,000 tokens of thinking first it takes 157.5, writes 21 times as many tokens, and an allowance of 200,000 tokens covers 31 such replies instead of 666. Sui and others’ survey of efficient reasoning calls this the “overthinking phenomenon”, with “significant computational overhead”, and Sprague and others suggest using chains of thought selectively to save that cost. Answer four questions about a task to see which approach fits it:
Answer the questions above: the table then marks what fits your case and says why the rest does not.
| Approach | Many checkable steps | Facts it may lack | Speed and usage limits | Confidence afterwards |
|---|---|---|---|---|
| Standard mode Works by: answering straight away | Poor writes its first likely route; B then C breaks the 20-minute rule | Poor a fact it never learned stays missing | Good 300 tokens: 7.5 s at 40 tokens a second | Mixed fine for wording you can judge by reading |
| Reasoning mode Works by: thinking, then answering | Good tries routes and checks the rule before it answers | Poor thinking cannot add a fee or a timetable it never saw | Poor 6,000 thinking tokens: about 158 s at 40 tokens a second | Mixed the shown reasoning may leave out what decided the answer |
| Reasoning plus your check Works by: a test you run on its answer | Good its answer plus your own check of every step that matters | Mixed your check catches a missing fact, if you look it up | Poor the thinking time plus yours | Good you rely on the check, not on the reasoning shown |
| A tool instead Works by: a calculator, code or a search | Good the program tried every route: 18:55 by A, E and F | Good a search or an official page brings the facts in | Good a calculator or a short program answers at once | Good exact, as long as its input is right |
How the answers decide
- “Does the task have many steps that can each be checked, such as a plan, a puzzle or a calculation?” Yes, many steps: rules out Standard mode. Answering at once leaves no room to try and check routes: the first likely one can break a rule.
- “Does the task have many steps that can each be checked, such as a plan, a puzzle or a calculation?” No, one or two: rules out Reasoning mode and Reasoning plus your check. With one or two steps, thinking adds time and tokens for little gain; on simple tasks standard models can even do better.
- “Does it depend on recent, local or rare facts, such as a fee, a rule or a timetable?” Yes: adds a caveat to Standard mode and Reasoning mode. Thinking reworks what the model already has; it cannot add a fee or a timetable it never saw. Paste the source or search first, then check the answer against it.
- “Do you need many answers quickly, or have a tight usage limit?” Yes: adds a caveat to Reasoning mode and Reasoning plus your check. Long thinking can write 21 times the tokens of a plain reply; switch it on only for the requests that need it.
- “Could a program, a calculator or a search answer it exactly?” Yes: adds a caveat to Standard mode, Reasoning mode and Reasoning plus your check. When a tool can answer exactly, the tool's answer is the check, whichever mode you use.
- “Could a program, a calculator or a search answer it exactly?” No: rules out A tool instead. No program or search answers it exactly, so a tool alone cannot do the job.
In short: use a reasoning mode for plans, puzzles, multi-step sums and debugging; use a standard mode for language work you can judge by reading; bring in the facts, by a search or your own documents, when the task depends on them; and when a program or a calculator can answer exactly, let it.
AI API Cost Calculator Add the thinking tokens to each reply's output tokens to see what a month of reasoning-mode answers costs.Checkpoint
Check: Time, tokens and limits
Practise: choose the mode for each task
Three decisions of the kind a team makes every week. For each, choose the approach; every answer says why:
Checkpoint
Choose the mode
Then the lesson’s self-check, which starts from whichever idea you have answered least surely so far:
Practice that adapts to you
Practise this lesson
10 questions about 5 ideas of this lesson. Each answer is explained at once, and what you get right is kept in this browser.
Interview questions
Warm-up (fresher to mid-level): What does a reasoning mode do differently from a standard chat mode, and when is it worth using?
A reasoning mode writes intermediate working, often called thinking, before its final answer: it tries approaches, checks them against the conditions of the problem and revises, because the model was trained to produce such chains on tasks with clear right answers. A standard mode writes the answer straight away. Thinking helps most on problems with many checkable steps, such as plans with rules, puzzles, multi-step sums and debugging; it helps little with rewording or translating, and it cannot add facts the model never learned. It costs time and tokens, since every thinking token is generated like the answer, so it counts against usage limits. And the reasoning it shows is not a faithful record: in tests, models seldom mentioned hints that had decided their answers. So use it selectively, and check the answer itself, not just the reasoning.
Two workplace questions build on this lesson:
Model answers open with any pass: ₹79 for 1 week ($2.99), one payment that never renews.
-
Mid to senior
A teammate accepts an AI tool's eligibility decision on a loan application because its displayed reasoning "looks sound". Explain why that is not enough, and what you would check instead.
-
Mid to senior
Your team wants a reasoning mode switched on for every request in a customer support tool. How would you decide whether that is worth it, and what would you measure?
Key takeaways
- A reasoning model writes working before its answer, trying and checking steps, because it was trained on problems with clear right answers; the train puzzle’s tempting route breaks the 20-minute rule, and checking finds 18:55.
- Thinking helps most on problems with many checkable steps, little on simple language tasks, and not at all with facts the model never learned.
- The reasoning on screen is not a faithful record: models mentioned a hint that decided their answer in only 25 % to 39 % of cases.
- Prompt a reasoning mode with the goal, the constraints and the form of answer you will check, not with a list of steps.
- Thinking costs time and tokens: 6,000 thinking tokens make a reply 21 times longer to write, so use the mode where the problem needs it.
Terms in this lesson
- chain of thought
- The intermediate steps a model writes before its answer, either because a prompt asked for them or because the model was trained to produce them.
- reasoning effort
- A setting some apps and services offer that controls how much a reasoning model thinks before answering: less effort gives faster replies that use fewer tokens.
- reasoning model
- A language model trained to write out intermediate working, often called thinking, before its final answer. It helps most on problems with many steps that can each be checked, such as plans, puzzles and sums.
References
- Speech and Language Processing, 3rd edition draft, chapter 1: Introduction (Stanford University (Jurafsky and Martin))
- Chain-of-Thought Prompting Elicits Reasoning in Large Language Models (NeurIPS (Wei and others; arXiv))
- To CoT or not to CoT? Chain-of-thought helps mainly on math and symbolic reasoning (ICLR (Sprague and others; arXiv))
- The Illusion of Thinking: Understanding the Strengths and Limitations of Reasoning Models via the Lens of Problem Complexity (NeurIPS (Shojaee and others; arXiv))
- s1: Simple test-time scaling (arXiv (Muennighoff and others))
- Reasoning Models Don't Always Say What They Think (arXiv (Chen and others))
- Language Models Don't Always Say What They Think: Unfaithful Explanations in Chain-of-Thought Prompting (NeurIPS (Turpin, Michael, Perez and Bowman; arXiv))
- Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1) (National Institute of Standards and Technology)
- Stop Overthinking: A Survey on Efficient Reasoning for Large Language Models (TMLR (Sui and others; arXiv))
- Chat Completion (Inference Providers documentation) (Hugging Face)
Related tools
Report a problem with this lesson
Kept only in this browser. Your Learn progress