When effort controls landed, I did the confident, wrong thing: I cranked thinking to the top on a lead-classification job, because surely more reasoning means better results. It did not. Classifying a lead as A, B, or C is not a problem that rewards deliberation, so I spent extra tokens and extra seconds per call across thousands of leads and got the exact same answers I would have gotten cheap and fast. I paid for a philosopher to do a filing job.
That taught me the whole lesson of this feature: thinking is a cost, not a virtue. Extended thinking and effort are powerful on the right problems and pure overhead on the wrong ones. This guide is how to tell the difference and set the dial where it belongs.
What extended thinking and effort are
Extended thinking lets Claude work through a problem before it commits to an answer, reasoning in steps rather than replying in one pass. Effort is the control on how much of that it does. Turn it up and Claude spends more reasoning on hard problems; keep it modest and it answers more directly. Together they let you tune reasoning depth to the task.
The important framing is that this is a resource you are spending, not a quality setting you max out. Reasoning takes tokens and time. On a problem that needs it, that spend buys a genuinely better answer. On a problem that does not, it buys nothing but a bigger bill and a slower response.
Effort is a dial, not an on switch
The mistake I made, and most people make, is treating this like a toggle: thinking on, because on sounds better than off. It is a dial, and the whole skill is setting it per task. Simple, mechanical work sits at the low end. Most everyday work sits in the middle. Hard, multi-step reasoning sits at the high end. The right setting is the lowest one that still gets the answer right.
This mirrors the model choice: you do not default to the most powerful model out of nervousness, and you do not default to maximum thinking either. Both instincts feel safe and both quietly torch your budget. Match the effort to the difficulty, the same way you match the model to the task.
- Classify, extract, reformatLow effort, fast, cheap
- Draft, summarize, most workDefault
- Multi-step reasoning, hard analysisMore thinking
When more thinking actually helps
Deeper thinking earns its cost on problems where the answer depends on working through steps. A multi-part analysis where each conclusion feeds the next. A judgment call that has to weigh several factors against each other. A tricky bit of reasoning where the obvious first answer is often wrong. On these, the extra reasoning is the difference between a shallow answer and a right one.
The tell is whether you yourself would need to stop and think. If a smart colleague would pause, reason it out, and check their logic before answering, that is a task where thinking helps. If they would answer instantly without deliberation, it is not.
A concrete GTM example: a next-best-action recommendation that has to weigh deal stage, recent activity, and fit together is a real reasoning task, and thinking sharpens it. The same account, merely tagged by industry, is recognition, and thinking adds nothing. Same account, two tasks, two different dial settings, because the difficulty, not the subject, decides.
When it is pure waste
On the flip side, a huge amount of GTM work is pattern recognition, not reasoning, and thinking does nothing for it. Classifying a lead into a tier. Extracting a name and title from a signature. Reformatting text into a shape. Tagging a message by intent. These are fast, direct tasks, and adding reasoning to them just adds latency and tokens for an identical result.
This matters because these are exactly the tasks you run at volume. A little waste per call is nothing on one call and a real bill across fifty thousand. The high-volume, simple jobs are the ones where keeping effort low pays off the most, precisely because they run so many times.
TipIf the task is classify, extract, or reformat, keep effort low. Those are recognition tasks, not reasoning tasks, and deliberation buys you nothing but latency and tokens.
How to set it
You set thinking and effort as parameters on the request, per call, so different jobs can run at different depths against the same model. The exact parameter names and options move as the API evolves, so check the docs for the current shape, but the practice is stable: pick the level per task type and apply it consistently across that job.
The workflow that works is to set a sensible default for a job, then adjust based on results. If a hard analysis is coming back shallow, turn effort up and see if it improves. If a simple job runs the same at low effort as high, leave it low. You are calibrating, not guessing once and forgetting.
A quick way to calibrate a job
If you are unsure where a job's dial belongs, do not agonize, test it. Take a handful of real examples, run them at low effort and again higher, and compare two things: did the answers get better, and how much more did they cost. Most of the time the comparison is decisive within ten samples, either the higher setting clearly earns its cost or it plainly does not.
This beats reasoning about it in the abstract, because your intuition about which tasks need thinking is often wrong, mine certainly was on that classification job. The sample tells you the truth cheaply, and once you have calibrated a job type you set it and move on. You are not re-deciding per call, you are deciding per kind of work, once, with evidence.
Thinking, tools, and agents
In an agentic loop, thinking interacts with tool use, and it is genuinely useful there: reasoning about which tool to call next, or how to interpret a tool's result, is exactly the kind of multi-step problem where deliberation helps. So agents often warrant more thinking than a one-shot classification, because the work is inherently sequential and decision-heavy.
But the same discipline applies. An agent doing hard research and planning wants real reasoning; an agent whose steps are all simple lookups does not need to deliberate over each one. Set the depth to the hardest genuine reasoning in the loop, not to the vague sense that agents are complex so they need maximum thinking.
Where it goes wrong
The dominant failure is the nervous default: leaving thinking high everywhere because it feels safer, then watching the token bill and latency climb for no gain on the tasks that did not need it. High effort is not a safety margin, it is a cost you are choosing to pay whether or not it helps.
The mirror-image failure is starving a genuinely hard task of the reasoning it needs to save a few tokens, and getting a confidently shallow answer. Both come from setting the dial by habit instead of by task. The fix is the same in both directions: look at the actual difficulty of the work, and set effort to match it.
- Maximum thinking everywhere out of nervousness, paying for reasoning that changes nothing.
- High effort on high-volume simple jobs, where the waste multiplies across every call.
- Starving a hard task of reasoning to save tokens, getting a shallow, confident answer.
- Setting the dial once by habit instead of matching it to each task type.
The GTM version
The GTM split is clean once you see it. The high-volume recognition work, scoring, tagging, extraction, enrichment shaping, runs at low effort, because it is pattern-matching and running it at depth would just tax every one of thousands of calls. The rare, high-stakes reasoning, a territory analysis, a complex account strategy, a thorny prioritization, gets the deep thinking, because there the extra reasoning genuinely changes the answer.
Spend the reasoning budget where judgment lives and keep it low where recognition is all you need. That single habit is worth real money at volume and a better answer where it counts. Which of your jobs is quietly running a philosopher to do a filing task?
How to set it up
Sort the task: recognition or reasoning
Before setting anything, decide which kind of task it is. Would a smart colleague answer instantly, or stop and reason it out? Instant means low effort; genuine deliberation means turn it up.
Set effort on the request
Set thinking and effort per call so different jobs run at the right depth. Check the docs for the current parameter shape, then apply it consistently across the job:
TipKeep effort low on anything you run at volume. A little waste per call is invisible on one and a real bill across fifty thousand.
Turn it up only where it pays
For the rare hard job, a territory analysis, a complex prioritization, raise the effort and confirm the answer actually improves. If it does not change at high effort, drop it back down.
Measure before you commit
Run a sample of a job at two effort levels and compare both the answers and the token usage. Let the comparison, not a hunch that more is better, decide where the dial sits for that job.
Frequently asked questions
What is extended thinking?
It lets Claude reason through a problem in steps before answering, rather than replying in one pass. Effort controls how much of that reasoning it does, so you can tune depth to the task.
Does more thinking always mean a better answer?
No. On genuinely hard, multi-step problems it helps; on simple recognition tasks like classification or extraction it changes nothing and just costs latency and tokens. It is a dial to match to the task, not a quality setting to max out.
When should I turn effort up?
When the task needs real reasoning: multi-step analysis, weighing several factors, problems where the obvious first answer is often wrong. If a smart colleague would pause and think, turn it up.
When should I keep effort low?
On fast, direct tasks: classifying, extracting, reformatting, tagging. These are pattern recognition, and deliberation adds cost without improving the result, which matters most because you run them at volume.
How do I set thinking and effort?
As parameters on the request, per call, so different jobs run at different depths against the same model. The exact parameter names move as the API evolves, so check the docs for the current shape.
What does more thinking cost?
Latency and tokens. Reasoning takes time and produces tokens you pay for, so higher effort is a real cost you should only spend where it changes the answer.
Should agents use more thinking?
Often yes, because choosing tools and interpreting results is genuinely multi-step. But set the depth to the hardest real reasoning in the loop, not to a blanket sense that agents are complex.
What is the GTM rule of thumb?
Low effort for high-volume recognition work like scoring and extraction; high effort for the rare, high-stakes reasoning like territory analysis. Spend the reasoning budget where judgment lives.
Sources & further reading
Claude ships fast. This page was last reviewed Aug 23, 2026; verify time-sensitive details against the official docs above before relying on them.