Most teams set the effort parameter once and treat it as a thinking length control. It also caps how many tool calls the model makes inside an agentic loop, which is where runaway cost actually comes from.
The effort parameter on Claude Opus 5 accepts five values, running low, medium, high, xhigh, and max, with high as the default. Most teams read that, conclude it controls how long the model reasons before answering, set it once at integration time, and move on. That reading is incomplete in a way that matters enormously to anyone running agents. Effort governs total token spend across three separate channels at once: the visible response, the extended thinking, and the number of tool calls the model will make inside an agentic loop before it stops.
That third channel is where the money is. A single request at max effort that thinks deeply and then answers costs a predictable amount, because the output has a natural length. An agent at max effort that reasons, calls a tool, evaluates the result, calls another tool, and iterates has no comparable ceiling, because the loop length is a function of how hard the task turns out to be rather than how long the answer needs to be. Teams that measured cost per request during testing and found it acceptable routinely discover the same configuration behaving very differently once the agent meets messy production data. Lowering effort on an agent does not only make it think less. It makes it try fewer times.
The practical consequence is that effort belongs in your per request payload, not in your client constructor. Classification, extraction, routing, and formatting are low effort work, and running them at the default high setting means paying for reasoning that changes nothing about the output you keep. Difficult architectural analysis, ambiguous debugging, and long horizon agent tasks are where xhigh and max earn their price. Because it is the same model at every setting, your prompts, your output schemas, and your evaluation harness all carry across unchanged, which is precisely what routing between a small model and a large one has always cost you.
Calibrate this rather than guessing at it. Take a representative sample of your actual traffic, run it at low, high, and max, and record two numbers for each task class: quality against whatever you already use to grade output, and total tokens consumed including thinking and tool calls. You will typically find a large block of traffic where low and high are indistinguishable on quality and separated by a multiple on cost, alongside a smaller block where max is the only setting that reliably gets the answer right. Route accordingly. Then rerun the calibration when the next model ships, because at four releases in under two months that will arrive sooner than your next procurement cycle.
Try it today
- Move the effort setting out of your client constructor and into the per request payload.
- Classify your traffic into task types: extraction, classification, drafting, deep analysis, agentic execution.
- Run a representative sample of each type at low, high, and max, recording quality score and total tokens including thinking and tool calls.
- Set a default effort per task type rather than one default per application.
- For agents specifically, pair the effort setting with an explicit maximum tool call budget so a hard task cannot silently become an expensive one.
