Why frontier models spend different amounts of computation on different problems
A developer asks an AI model to rename a field in a configuration file. A few seconds of reasoning is enough. The next request is different: inspect a production failure, connect logs from several services, understand a recent code change, find the likely root cause, propose a fix and explain the risk of deploying it.
Treating both requests as the same kind of inference would be wasteful. One is routine; the other may require the model to explore several explanations, reject weak ones, check evidence and revise its conclusion.
Modern reasoning is not only about whether a model can solve a hard problem. It is also about how much computation should be spent, when, and whether the extra work is worth its cost.
A Short Reminder: What Reasoning Means Here
In this book, reasoning means the additional internal computation a model uses to work through a problem before producing or committing to an answer or action. It does not mean the model reasons exactly like a person, and it does not mean every internal step is visible to the user.
One distinction matters throughout. The answer we see is an output. The model's internal computation is not the same thing as the explanation it later writes about how it reached that answer.
The Same Model Can Spend Different Effort
OpenAI exposes this directly in GPT-6 Astra. Its API supports reasoning-effort levels named low, medium, high, xhigh and max, and OpenAI allows the level to be changed during an ongoing conversation without rebuilding the unchanged beginning of the prompt.
That tells us something important about frontier-model design: reasoning is increasingly treated as a controllable resource. A routine task can use a lower setting, and a difficult investigation can be given more inference-time effort. The model remains the same model, but the amount of work performed for the request changes.
Why More Reasoning Can Help
Consider a software incident with three plausible causes: a database migration introduced an incompatible schema change, a network timeout caused retries that duplicated work, or an authentication change rejected requests from one service. A shallow answer may notice the most obvious error message and stop there. More reasoning effort lets the model compare hypotheses, look for contradictory evidence, inspect the order of events, and ask whether the explanation accounts for all the symptoms.
This is especially useful when a problem has several properties at once: multiple steps, incomplete evidence, dependencies between decisions, or a high cost if the answer is wrong.
But More Compute Is Not the Same as More Intelligence
If a model can be asked to reason more, it is tempting to assume maximum reasoning should always be used. That would be poor system design. Deeper inference costs latency and tokens, some problems do not improve after additional work, a model can spend effort exploring possibilities that do not matter, and more reasoning does not guarantee that a wrong starting assumption will be corrected.
The goal is not maximum reasoning. It is sufficient reasoning for the difficulty and risk of the task.
Reasoning Becomes a Scheduling Problem
Once reasoning effort is variable, an AI system has to make a scheduling decision. A support workflow might classify a case as routine, begin with lower reasoning, then escalate when logs disagree, security is involved or confidence remains low.
Reasoning is then no longer just a property of the model. It becomes part of orchestration: the surrounding system decides when to spend additional intelligence.
Reasoning Can Be Distributed Across a Workflow
A system does not have to spend the same effort at every stage. Astra can begin a task at a lower reasoning level, and an application can increase the effort when the work reaches a difficult stage; OpenAI documents this as a configuration update that preserves the existing conversational prefix and cache, and Anthropic documents the equivalent for Fable 5.1 as a per-message effort change.
A sensible division looks like this:
- cheaper reasoning for triage and routine transformation;
- deeper reasoning for ambiguous or high-consequence decisions;
- tools for facts that should be measured rather than guessed;
- verification of important actions after execution;
- human review when the consequence exceeds the system's authority.
The intelligence of the workflow comes partly from the model and partly from deciding where to place the model's effort.
What Fable 5.1 Tells Us
Anthropic describes Claude Fable 5.1 as its most capable generally available model for ambitious coding, knowledge work and long-running asynchronous tasks. Its public material emphasizes root-cause analysis, planning, verification loops, code review, research and recovery when a step fails.
Anthropic documents the same kind of control. Fable 5.1 runs adaptive thinking that is always on, and its depth is steered with an effort parameter that takes the same five levels, low, medium, high, xhigh and max, with high as the default. Anthropic also documents changing effort part-way through a conversation with a per-message setting that preserves the prompt cache, currently in beta. Two vendors arriving at the same five-level control, and the same mid-conversation change, is itself evidence: reasoning effort has become a standard orchestration parameter rather than one company's feature.
The useful comparison therefore sits higher up: both companies are optimizing models for problems where a quick first answer is not enough, and where the model must sustain a line of work, inspect evidence, revise decisions and produce something that survives checking.
Reasoning and Tools Solve Different Problems
A model should not reason about a fact that a tool can verify directly. If the question is "Did the test suite pass?", the reliable action is to run the tests. If the question is "Which architectural change best explains why these tests began failing after the deployment?", reasoning becomes useful.
The rule of thumb: use reasoning to decide what evidence means, and use tools to obtain evidence that can be measured directly.
Self-Correction: Useful, but Easy to Misunderstand
Frontier models increasingly appear able to notice inconsistencies and revise their own work. Fable 5.1 is explicitly described as able to write tests to check its coding work; Astra is designed for end-to-end workflows that include building, operating and checking software.
Self-correction can improve results, but it is not proof of correctness. If the same model creates both a solution and a weak test, it can pass its own test while the real defect remains. Chapter 13 separates self-review, tool-based verification, independent model review and external ground truth for exactly this reason.
Where It Can Still Fail
Effort is spent on a wrong starting assumption. More reasoning deepens the error instead of correcting it.
A difficult problem is classified as routine. The system never escalates, and a shallow answer ships.
Reasoning replaces a measurement. The system pays for maximum effort when a direct tool check would have been better.
The explanation is not a faithful record. The model produces a convincing account that does not match its internal computation.
A self-check repeats the original blind spot. The same model verifies its own mistake.
The important change is not simply that frontier models can answer harder questions. Reasoning is becoming an adjustable system resource, much like memory, compute or parallelism in conventional software, and the advantage increasingly comes from knowing when to make the model work harder and when not to.
Reasoning is a budget, not a virtue.
Three Things to Remember, One Thing to Do
1. More reasoning can improve difficult work, but it does not guarantee correctness.
2. Variable reasoning turns inference-time compute into an engineering and cost decision.
3. Good systems combine reasoning with tools, verification and human authority rather than asking the model to think its way through everything.
One thing to do. Take one AI workflow you run today and label each step as routine or high-consequence. Assign lower effort to the routine steps, higher effort to the rest, and mark any step where the question is a fact a tool could check instead. That labeled list is the start of a reasoning schedule.
How much do you need? Architect: Use. Everyone else: Know.