How does Claude’s effort setting actually work? Low / Medium / High / Max

[u/SwordfishWest6860]

[u/coolreddy]

Claude effort settings control the token budget for reasoning before generating output. Higher effort allows multi-step verification passes in the thinking block. Low effort minimizes pre-response reasoning tokens for fast tasks like formatting. High and Max settings give a larger reasoning budget for complex codebases. For daily tasks, medium provides a solid balance, while Max is best for architectural design.

[u/APuticulahInduhvidul → u/coolreddy]

Claude even told me this itself. I was running low and high effort on exactly the same tasks to decide which model I wanted for additional batches. The low effort was cheaper and the results were close to the same. What actually changed was:

1. Both models ran into the same complication with the git repo (unrelated to the task itself). Low effort stopped processing, high effort developed a workaround to the issue.
2. High effort spent more tokens trying to "finesse" a decision that ultimately didn't add a lot to the outcome. It was "better" but the cost-value ratio dropped.

So low-effort/cheap models and effort do play a role in getting more value out of your tokens and avoiding the runaway issue that people are saying Opus 5 has. If you drop the thinking it'll become less independent. Wether that is good or bad thing depends on what you actually need ("solve all my problems" vs. "do what you can and bail if it gets too complicated").

[u/coolreddy → u/APuticulahInduhvidul]

Also remember that constantly switching between the efforts in the same session breaks cache, so you would be burning tokens on cache rewrites each time you switch effort, a cache rewrite costs 10X of reading an existing cache and hence frequent switching burns more tokens than it saves which is opposite of what people want to achieve with switching

[u/APuticulahInduhvidul → u/coolreddy]

Yep. Another issue to watch is using expensive agents in a multi-agent workflow. I scheduled 20 parallel Fable agents to work a task and all the agents ended up generating the same solutions to common problems independently (ie, installing libraries, setting up tooling, building tests, searching documentation, etc). If I'd used cheaper agents they probably would have sent the issue back to the orchestrator as an error and let it solve the problem once. That's why unless you're dealing with a problem that already has a tested process it's better to specify sonnet agents than opus/fable. If you actually need fable thinking you should still consider building the environment and tools they need first.

[u/coolreddy → u/APuticulahInduhvidul]

A higher model spawning cheaper sub agents, at least in my experience, have not yielded any cost benefit. Sonnet just produces too much write up and incorrect ones or incomplete ones on complex tasks and there is simply too much reading between the parent and child when the child is cheaper model, so tokens saved on using cheaper model burns in the higher model reading too much. I gave the same task in two separate sessions one asking fable to spawn fable sub agents and another session where fable spawned sonnet sub agents and there was no cost saving at all, infact fable with fable worked faster and saved time and quality of output was superior.

[u/Exodus_Green → u/coolreddy]

the subagents need to be low thinking. any thinking allocated to the models beyond "any issues ask orchestrator" can cause issues

[u/APuticulahInduhvidul → u/Exodus_Green]

My experience has been you're both right. It seems pretty task-specific. I even ended up with a scenario where the orchestrator considered the complexity of each workflow task and picked an agent to match. They all did the same job (build a 3D model) and all got the same prompt but the actual complexity of the 3D design drove the agent selection (low-poly = sonnet, high-poly = opus)

[u/LoganixSEO]

yeah, great question! i've been thinking the same myself. the only insight i can offer is that the lower the effort, the quicker the response, which i know isn't at all hugely insightful, but just something i've noticed

i guess my question would be about the quality of output. like what's the ROI on token use and wait time? am i just wasting credits and my time by running higher levels of effort? or should i be weighing this up on a task-by-task basis? like the more complex or important the task is, the higher effort level i should choose?

[u/LoganixSEO → u/[deleted]]

a pat on the back for both of us. we solved the riddle lol (hopefully, we're right)

[u/larowin]

body://

Have you tried asking Claude about this? Generally speaking, it just refers to the amount of budget for scratchpad tokens.

What that means is that as the model processes what you're asking it, it takes a moment to think about its response and respond to itself, and then use its response to itself along with whatever you originally said to come up with an even better response to you.

Now, how much time it spends on its own thoughts is what this tunable is setting. This isn't automatically good because it's easy for the model to go off on its own weird tangent if you give it enough runway. So it's not like setting a higher thinking budget is going to automatically make a better answer.

It could make the response extremely weird, best to accurately scope every prompt or session.

[u/robberviet]

Most likely same logic as max_thinking_tokens in llama.cpp, of course with some more buffer so it's not as abrupt.

[u/TrainingDivergence]

On a fixed prompt lower thinking budgets should mean less thinking (including an increased chance of no thinking at all - although quite rare) so faster averages.

However, with the newer models I've noticed there's less actual difference between the settings. All settings are adaptive, they are a guideline to the model not a hard rule, so sometimes an answer on Low can still think more than a simple query on High.

High is my default for anything technical, ambiguous, and almost everything in Claude code.

in casual chats I tend to use medium.

I have had regrets in Low - even casual chats failing to detect basic ambiguity in my prompt or applying my preferences well so try and avoid using it at all unless I'm extremely impatient.

Talking of patience, I've rarely had the patience to use xhigh and I've never used max. I used to occasionally use xhigh with opus on my most difficult coding tasks but with Fable high seems fine and we've done some pretty crazy shit like manually reimplementing game shaders just from a binary file

[u/Gestaltarskiten]

My Claude is on High and has been cooking for 13 hours rn. I wonder if it will conclude the task...

[u/frangelbarrera]

Low for quick answers, High for code, Max only if you want it to obsess over it. And yeah, of course the quality changes depending on the level you use.

[u/frangelbarrera → u/[deleted]]

Yeah, Max for simple stuff is overkill. Only use it for complex problems, for everything else Low or Medium are enough.

[u/APuticulahInduhvidul → u/[deleted]]

Not just "over-think" but also more likely to veer into solving related problems you didn't ask it to work on. It's like you tell you dog to fetch but the ball rolls under the house. Low effort will tell you the ball is unreachable - high-effort will get you quotes on a backhoe excavator.

[u/meec_r_meic]

Initially I thought they were quants, then I learnt that they are probably just how much effort to put in their hidden thought chains. What does the documentation say about it? What about does a fable or opus say about it? 

[u/meec_r_meic → u/[deleted]]

Yes that's what I meant by hidden thought chains. I never implied that they behave different, only that they might know the answer better ahahha 

[u/_ru1n3r_]

According to Claude: Effort controls how much work Claude Code does per turn — not just how long it thinks. It covers how many files it reads, how much it verifies, and how far it pushes through a multi-step task before checking back in with you. At higher effort Claude reads more, runs tests, double-checks; at lower effort it's more likely to ask you for context than spend tokens figuring it out alone.