---
title: "The Effort Dial Is an Architecture Decision, Not a Setting"
description: "Claude Opus 5 ships with a low, medium, high effort toggle, and most teams set it once globally and forget it. In an agent loop, effort is a per-step decision, and treating it as a global default costs you money on the mechanical steps and reliability on the one step that mattered."
image: "https://foundrysoft.co/api/og?type=article&title=The+Effort+Dial+Is+an+Architecture+Decision%2C+Not+a+Setting&cat=AI+Engineering&rt=14+min+read&au=Varun+Raj+Manoharan&dt=2026-08-14"
url: "https://foundrysoft.co/blog/effort-dial-agent-architecture"
---

AI Engineering 2026-08-14 14 min read

# The Effort Dial Is an Architecture Decision, Not a Setting

Claude Opus 5 ships with a low, medium, high effort toggle, and most teams set it once globally and forget it. In an agent loop, effort is a per-step decision, and treating it as a global default costs you money on the mechanical steps and reliability on the one step that mattered.

![Varun Raj Manoharan](https://foundrysoft.co/images/about/founder.webp)

Varun Raj Manoharan Founder & Principal Engineer

Claude Opus 5 AI Agents Reasoning Models LLM Cost Agent Architecture

## Key takeaways

-   An effort dial is a per-call decision, not a project setting. In a thirty-step agent loop, most steps are mechanical routing and formatting where extra reasoning buys nothing, and two or three steps carry the entire outcome.
-   Setting high effort globally is the expensive way to hide bad context engineering, because a model that has to reason its way past a badly assembled prompt will usually succeed often enough that you never fix the prompt.
-   Setting low effort globally fails silently. The loop still completes, the output still looks structurally correct, and the quality drop lands on the one step where judgment was actually required.
-   You cannot choose effort per step until your traces are tagged by step type. Instrument first, measure completion rate and cost per step class, then set the dial from the data rather than from intuition.

Claude Opus 5 landed on 24 July 2026 with a feature that reads like a minor convenience in the release notes: you can toggle how much effort the model spends on a task, across low, medium, and high. The pricing did not move. Opus 5 costs $5 per million input tokens and $25 per million output tokens, the same as Opus 4.8 before it. What changed is that you now decide, per call, how hard the model works before it answers.

Most teams will set that dial once, in a config file, and never touch it again. In an agent loop that instinct is wrong twice over: the effort dial is not a setting but an architecture decision, and the right value differs across almost every step in the loop.

## What the dial is actually buying

The mechanism is not mysterious. A higher effort setting means the model spends more tokens working through the problem before it commits to an answer. You are paying for deliberation, and you are paying for it in output tokens, which on Opus 5 are five times the price of input tokens.

That pricing asymmetry is the whole reason this matters. Effort does not make your input cheaper or your context shorter. It makes the model produce more of the most expensive kind of token. When you flip the dial to high across an entire agent, you are not making a modest quality-for-cost trade. You are multiplying the expensive half of your bill across every step of the loop, including the steps that were never going to benefit.

Anthropic is not alone here. OpenAI's GPT-5.6 family, released 9 July 2026, includes an ultra mode within Sol that lets the system work harder on a task and delegate to submodels. Google has signalled an updated Deep Think mode for Gemini 3.5 Pro, though as of this writing that model remains in limited preview on Vertex AI and has not launched publicly, so treat anything specific about it as unconfirmed. The pattern across providers is clear enough regardless: reasoning depth is becoming a runtime parameter rather than a property of the model you picked.

## Why per-step is the right granularity

Think about what a real agent loop is made of. Say it reads a file, greps for a symbol, calls an internal API, validates the response against a schema, decides whether the result answers the question, and either loops again or writes a summary. Thirty steps of that is a normal working session.

Now sort those steps by whether reasoning depth changes the outcome.

The overwhelming majority are mechanical. Formatting a tool call against a known schema does not get better when the model thinks harder about it. Neither does extracting a field from a JSON response, deciding that a 404 means the record is missing, or appending a result to a working set. These steps have one correct answer that is fully determined by the input. Extra deliberation produces the same answer, more slowly, at five times the token price.

A small number of steps are entirely different. Deciding whether the evidence gathered so far is sufficient to answer. Choosing which of four plausible tools fits an ambiguous request. Reconciling two sources that disagree. Deciding to stop. These are the steps where the model is exercising real judgment, and where the difference between a shallow pass and a deliberate one shows up directly in whether the task completes correctly.

The arithmetic follows from that split. If twenty-seven of thirty steps are mechanical and three carry the outcome, running high effort everywhere means you are paying the premium on 90% of your calls to improve 10% of your results. Running low effort everywhere means you saved money on the 90% and degraded exactly the steps that decide whether the loop succeeds.

Neither global setting is defensible once you look at the loop this way. The dial wants to be set per call.

## Global high effort is an expensive way to hide bad prompts

There is a failure mode here that deserves a name, because it is comfortable and it does not look like a failure.

A team ships an agent, the outputs are inconsistent, someone turns effort to high, and the outputs get better. Problem closed. What actually happened is that the model is now reasoning its way past a context problem that is still there. The tool descriptions are ambiguous, or the system prompt contradicts itself in a way nobody noticed, or the retrieved chunks arrive in an order that buries the relevant one. A model given enough deliberation will often work around all of that.

This is a bad trade for two reasons beyond the bill. One: you have converted a fixable, permanent problem into a recurring cost. Fixing the tool description costs an afternoon once. Paying for the model to route around it costs you on every call, forever.

Two: the workaround is not reliable, it is just frequent. The model reasons past the ambiguity most of the time, and that is exactly the pattern that produces incidents nobody can reproduce. When it fails, it fails on the inputs where the ambiguity happened to bite hardest, and your logs show a model that usually handles this fine.

If turning effort up fixed your agent, the honest reading is that you have found a context engineering bug, not a tuning win. Turn it back down, find the bug, then decide where effort belongs.

## Global low effort fails quietly

The opposite default has a worse property: it does not announce itself.

An agent running low effort everywhere still completes. It still emits valid JSON, still calls tools in a plausible order, still produces a summary at the end that reads like a summary. Structural correctness is not what degrades. What degrades is the quality of the two or three judgment calls buried in the middle, and those do not surface as errors. They surface as a slightly wrong answer delivered with the same confidence as a right one.

This is why cost-cutting exercises that start with "turn effort down globally" tend to look like free money for about three weeks. The bill drops immediately and visibly. The quality cost accrues in a distribution of slightly worse outcomes that nobody is measuring, and it only becomes legible when a customer escalates something that should have been caught.

If you are going to reduce effort, reduce it on the steps you have classified as mechanical, and leave the judgment steps alone. That gets you most of the savings without the invisible tail.

## You cannot do this without tagged traces

Everything above assumes you know which of your steps are mechanical and which carry the outcome. Most teams do not, because their traces record calls, not step types.

The instrumentation is not complicated. Every call your agent makes gets a step class attached before it goes out: `tool_format`, `extract`, `route`, `sufficiency_check`, `synthesize`, whatever vocabulary fits your loop. That tag rides along into your traces alongside token counts, latency, and the eventual task outcome.

Once that exists, the analysis is direct. Group completed tasks by outcome, then look at which step classes differ between the successes and the failures. Step classes that look identical across both are mechanical, and they are candidates for low effort. Step classes where the failures show meaningfully different behaviour are your judgment steps, and they are where effort earns its price.

Then run the actual experiment. Hold effort high on the judgment classes, drop it to low on the mechanical ones, and compare task completion rate and total cost per task against your current baseline. You are looking for the configuration that holds completion rate flat while moving cost, or improves completion rate on the steps that matter without moving cost much.

I want to be careful here about what I am claiming. I am not going to tell you that a specific split produces a specific percentage saving, because that number depends entirely on the shape of your loop, how many steps it runs, and what fraction of them are mechanical. A loop that is twenty-eight mechanical steps and two judgment calls has a very different profile from one that is a five-step research task where three steps are judgment. The method transfers. The number does not.

## Where the dial interacts with model choice

One more interaction to think through, because it changes the calculus.

Opus 5 was positioned as coming close to the frontier intelligence of Fable 5 at half the price, and it took state-of-the-art on Frontier-Bench and GDPval-AA at launch, though it sits behind Mythos 5 on cybersecurity tasks. That is four Claude 5 models inside two months, following Mythos 5, Fable 5, and Sonnet 5 in June, and the pattern is not going to slow down.

The effort dial and the model tier are two knobs pointed at the same target. A cheaper model at high effort and a more capable model at low effort can land in a similar place on both quality and cost, and which one wins is an empirical question about your specific workload rather than something you can reason out from the spec sheet.

The practical consequence is that these two decisions have to be made together and measured together. A routing layer that picks a model per step but pins effort globally is only doing half the job, and so is an effort policy that assumes one model everywhere. If you have already built the step classification described above, you have the substrate for both, because the same tags that tell you where to spend effort tell you where to spend capability.

## What to do this week

Start with instrumentation, because nothing else is possible without it. Tag every model call in your agent with a step class and get those tags into your traces alongside cost and outcome.

Then classify. Go through a few dozen real traces and sort your step classes into mechanical and judgment. Do this by reading actual traces rather than by reasoning about your architecture diagram, because loops almost always contain steps nobody remembers adding.

Then set the dial from the classification, and only then. Low on mechanical, high on judgment, medium as the default for anything you have not classified yet.

And if you find yourself reaching for global high effort to fix a quality problem, stop and go read the prompt for that step first. The dial earns its keep. It is also the most expensive debugging tool you have available, and most of the time the bug it is hiding is one you could have fixed for free.

#### Related reading

[AI Agents Are About to Start Buying From You. Is Your Checkout Ready?

Agentic commerce protocols settled into a working stack this year: ACP for checkout, AP2 for payment authorisation, MCP and A2A underneath. Most merchant systems are built on assumptions that an agent breaks. Here is what to check before an agent tries to buy something.

Agentic Commerce AP2 AI Agents

](https://foundrysoft.co/blog/agentic-commerce-checkout-readiness)[The EU Just Gave You 16 More Months on AI Compliance. Do Not Spend Them.

The EU AI Act's high-risk deadline moved from 2 August 2026 to 2 December 2027. The transparency rules did not move. Here is what actually applies to your AI agents right now, and why the extension is a trap for anyone who treats it as free time.

EU AI Act AI Compliance AI Agents

](https://foundrysoft.co/blog/eu-ai-act-high-risk-delay-agents)[Three Tiers, One Loop: Routing Between Model Sizes Without Breaking Your Agent

GPT-5.6 shipped as Sol, Terra, and Luna on the same day. Tiered families make per-step model routing obvious in theory and expensive in practice. Here is what routing actually costs you in evals, caching, and debugging, and the two cases where it still pays.

GPT-5.6 Model Routing AI Agents

](https://foundrysoft.co/blog/model-tier-routing-agent-loops)

#### Next Article

[

Three Tiers, One Loop: Routing Between Model Sizes Without Breaking Your Agent

](https://foundrysoft.co/blog/model-tier-routing-agent-loops)

Available for new projects

## Let's build something great.

Have a project in mind? We are an elite software and AI development studio ready to bring your ideas to production. Let's talk about your roadmap.

Start a Project [See our work](https://foundrysoft.co/work)

```json
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "FoundrySoft",
  "url": "https://foundrysoft.co",
  "logo": "https://foundrysoft.co/logo.svg",
  "description": "FoundrySoft builds production-grade software and AI systems for US companies, from an India-based team of senior engineers.",
  "sameAs": [
    "https://github.com/foundrysofthq",
    "https://www.linkedin.com/company/foundrysoft",
    "https://www.instagram.com/foundrysoft/"
  ]
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "FoundrySoft",
  "url": "https://foundrysoft.co"
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "The Effort Dial Is an Architecture Decision, Not a Setting",
  "description": "Claude Opus 5 ships with a low, medium, high effort toggle, and most teams set it once globally and forget it. In an agent loop, effort is a per-step decision, and treating it as a global default costs you money on the mechanical steps and reliability on the one step that mattered.",
  "url": "https://foundrysoft.co/blog/effort-dial-agent-architecture",
  "mainEntityOfPage": "https://foundrysoft.co/blog/effort-dial-agent-architecture",
  "image": [
    "https://foundrysoft.co/images/blog/effort-dial-agent-architecture.webp"
  ],
  "datePublished": "2026-08-14",
  "dateModified": "2026-08-14",
  "keywords": "Claude Opus 5, AI Agents, Reasoning Models, LLM Cost, Agent Architecture",
  "author": {
    "@type": "Person",
    "name": "Varun Raj Manoharan"
  },
  "publisher": {
    "@type": "Organization",
    "name": "FoundrySoft",
    "logo": {
      "@type": "ImageObject",
      "url": "https://foundrysoft.co/logo.svg"
    }
  }
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://foundrysoft.co/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://foundrysoft.co/blog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "The Effort Dial Is an Architecture Decision, Not a Setting",
      "item": "https://foundrysoft.co/blog/effort-dial-agent-architecture"
    }
  ]
}
```