Claude Code Effort or Model: Which One to Change First
Claude Code effort sets how hard the model tries before it calls a job done. The model sets how much it knows. When a result comes back wrong, one question tells you which of the 2 to change: did it not know enough, or did it not try hard enough?
Unfinished work is an effort problem. Wrong work is a model problem. Work you did not ask for is effort again, set too high. The first 2 look identical when you read the output, so a bigger model looks like the answer to both, and it only ever fixes one of them.
Key Takeaways
Effort is persistence, not intelligence. It sets how long the model works before deciding it is finished.
Skipped a file, never ran the test, stopped 3 files into a refactor. That is effort, and effort is the cheaper fix.
Ran to completion and landed wrong, usually a subtle bug or unfamiliar ground. That is the model.
The question runs backwards too. Work you did not ask for means effort is set too high.
Change one thing at a time, and change effort first.
If you want the short version, jump to the diagnostic.
What Claude Code effort actually is
Claude Code effort travels with your request and tells the model how thorough to be before it calls the job done. It is not a quality dial and it is not intelligence. It is persistence: how much work happens before the model decides the answer is finished.
Both levers are 1 command each in Claude Code. /effort changes how hard the model tries, /model changes which model is trying, and both take effect from your next message. Which effort levels you can pick depends on the model you are on, so /effort is also how you see the ones available to you and where you currently sit.
The default is usually right. Running on the highest setting is tempting precisely because you care about the task, and caring about the task is not the same as the task needing it.
Why high effort costs more than it looks
Running at high effort costs you later in the session, not on the turn itself. Higher effort produces more output tokens, and those tokens join the conversation the model reads on every later turn. Cached, they are cheap to read again, but they are still there and they still fill the context window. A long session at high effort carries more of them than the job needed.
How effort and the model differ
The model is the other lever and it works differently. A larger model does more computation on every single token, going in and coming out, so it multiplies everything else rather than adding to it. Effort changes how long the work runs. The model changes what every unit of that work costs.
Worth saying plainly, because the instinct runs the other way: a smaller model is not a worse model. It is a model doing less computation per token, which is exactly right for work you can describe precisely.
Did it not know enough, or did it not try hard enough?
Read the failure, not the output. The question is whether the model lacked what it needed to get there, or had it and stopped short.
What came back
What it means
What to change
It skipped a file you named
It stopped short
Effort, up
It never ran the test
It stopped short
Effort, up
It called it done halfway
It stopped short
Effort, up
It missed a subtle bug
It lacked the knowledge
Model, up
It was out of its depth
It lacked the knowledge
Model, up
It rewrote 9 files you never mentioned
It went too far
Effort, down
4 tells that mean effort
Effort failures share a shape: the work is correct as far as it goes, and it does not go far enough. Nothing in the output is wrong, which is what makes it read as a weak model. Concretely, in a Claude Code session:
It announced it was done without running anything. No test command in the transcript, no build, just a summary of what it changed.
A file you named in the prompt was never opened. You wrote the path. It is not in the tool calls.
The refactor stopped partway. 3 call sites updated, 2 left as they were, and nothing in the summary saying so.
It answered the easy half. A 2 part question came back with one part addressed thoroughly and the other acknowledged in a sentence.
Every one of those is a model that knew how and stopped. More capability does not fix any of them.
3 tells that mean the model
Model failures look different. The work runs to completion and lands in the wrong place.
The fix addressed the symptom in front of it and left the cause, in a bug whose cause sits in a different part of the system.
The framework was unfamiliar, so the answer is confidently written, fluent, and quietly wrong.
It repeated the same wrong approach after you corrected it, which usually means it does not have a second approach available.
Effort cannot repair any of those, because more persistence applied to a wrong understanding just produces more of the wrong thing.
When both look true
Change one thing at a time, and change effort first. It is the cheaper move and it is the more common answer. If the same failure comes back in the same place at a higher effort level, that is your evidence the ceiling is knowledge rather than persistence, and the model is the thing to move. Make either change at the top of a fresh session rather than part way through one, for the reason in timing.
Which model the job actually wants
Once the diagnostic says model, the question becomes which one. The useful way to hold them is as people you would hand a job to.
Model
Treat it as
Reach for it when
Haiku
The quick assistant
The job is small and mechanical
Sonnet
A really good generalist
You can describe the change precisely
Opus
The expert
There is a subtle bug or unfamiliar territory
Fable
The specialist who has seen problems nobody else has
The expert is not enough
What generalist work looks like
An edit you can describe precisely. A mechanical change. A question about code already sitting in the context. That is generalist work, Sonnet does it well, and it uses far less of your allowance for the same work. If you can write the instruction clearly enough that a careful person could follow it, the generalist is the right hire.
What actually calls for the expert
Subtle bugs and unfamiliar territory. Not "this matters to me" and not "this file is long". The test is whether the job needs judgment the instruction cannot carry, because judgment is the thing a larger model buys you.
When to turn Claude Code effort down
The diagnostic runs backwards, and that half gets far less use. Work you did not ask for is effort set above what the job needs, and it costs you on every turn that follows rather than arriving as free thoroughness.
The tells are as concrete as the other direction. A 1 line change comes back as a refactor of the surrounding module. A question gets answered with an implementation. Files you did not mention appear in the diff. A short task fills the session with exploration you have to read before you can approve anything.
There is a second reason to try a step down. On newer models a lower effort level is sometimes as good as an older model running at its highest, so an effort level you settled on for a model you no longer run is tuned for a problem you no longer have. On a larger model like Fable 5.1, medium is excellent, whatever the name suggests.
If you are seeing work you did not ask for, try one step down at the start of your next session before assuming your current setting was the floor.
Set both at the start, not in the middle
Effort sits ahead of your conversation, so on most models changing it mid session invalidates the cached prefix, and the next message reprocesses your history at full cost. Changing the model costs you the same thing for a different reason: the cache belongs to the model that built it, so a new one has nothing to reuse and reads your conversation fresh. Claude Code will usually warn you while the cache is still warm and ask you to confirm first, though it is worth knowing what the confirmation is actually protecting.
The habit that follows is small. Make the model and effort choice at the start of a session, or right after you clear, when there is nothing cached to lose. If you have to switch models mid task, run /compact first so the new model reads a short summary instead of everything. That timing is the whole argument behind prompt caching, and it is the reason this choice belongs at the top of a session rather than in the middle of one.
Fable 5.1 is the exception on effort. It is the one model where changing the effort level mid session leaves the cache intact.
Subagents carry their own settings
A subagent runs in its own context and takes its own model and its own effort level, separate from the session that called it, and that holds for any custom subagent you have defined. A Haiku or Sonnet subagent is a good place to send heavy digging, because the reading happens over there and only the conclusion comes back. A subagent is not free, and that one job can use more of your allowance than doing it inline. What you win is a main conversation that stays small, so every turn after it is cheaper.
If this is the part of Claude Code you want to work through properly rather than tune by feel, that is most of what the workshop covers.
FAQ
Should I just run Claude Code on the highest effort setting?
No. Higher effort produces more output tokens, and those stay in the conversation the model reads on every later turn. They are cheap to read again once cached, but they still fill the context window, so a long session at high effort carries more of them than the job needed. The default is usually right, and on newer models a lower setting is sometimes as good as an older model at its highest.
How do I know whether it is the model or the effort?
Ask whether the result was wrong or unfinished. Unfinished work, a skipped file, a test never run, a job abandoned halfway, is effort. Work that ran to completion and landed wrong, usually a subtle bug or an unfamiliar framework, is the model.
Is a smaller model a worse model?
No. A smaller model does less computation per token, which is the right amount for a precisely described edit, a mechanical change, or a question about code already in the context. Reserve the larger model for subtle bugs and unfamiliar ground. Each model has a shape of job it fits.
Does changing the effort level break the prompt cache?
Yes on most models. The effort setting is part of what gets cached, so changing it means the next message reprocesses your whole conversation at full cost. Fable 5.1 is the exception and changes effort mid session with the cache intact.
Can a subagent run at a different effort level than my session?
Yes. A subagent has its own context and takes its own model and effort setting, custom subagents included. That makes it a good place to send noisy work at a smaller model while the main conversation stays small.
Where do I read more on how effort behaves?
The effort parameter is documented directly, including per model recommendations and how effort interacts with tool use. The reference is written for people calling the API rather than working in Claude Code, so it explains the behavior underneath rather than the CLI in front of it.
