Claude Opus 5's Effort Setting and Long-Running Agents: What Changes for Developers
Anthropic's latest model doesn't just benchmark better. Its real impact is on the multi-hour, multi-session agent tasks that most AI models still can't sustain reliably.
Ten days after Anthropic shipped Claude Opus 5, the early picture is coming into focus. The model performs within 0.5% of the company's top-tier Fable 5 on coding benchmarks at half the cost, according to Anthropic's announcement. It more than doubles its predecessor Opus 4.8's performance on Frontier-Bench v0.1, again at lower cost per task. Those numbers matter. But the more consequential shift is what Opus 5 enables for long-running agents — the kind of autonomous, multi-step workflows that developers have been trying to make reliable for the past year with mixed results.
As we covered in our earlier Claude Opus 5 report, the model ships with a tunable effort setting, is live on GitHub Copilot and AWS Bedrock, and is now the default on Claude Max. But the deeper story is how Opus 5 fits into the broader infrastructure Anthropic has been building around sustained agent work, and what that means for how developers structure their automation.
The Long-Running Agent Problem, Explained
Most developers have hit the wall. You point an AI agent at a complex task — refactoring a module, migrating a database schema, debugging a flaky integration test suite — and it works well for a while. Then the context window fills up. The agent loses track of what it was doing. The next session starts cold, with no memory of prior progress, and the work drifts or regresses.
Anthropic's engineering team described this challenge directly in a November 2025 post on effective agent harnesses. The analogy they used: imagine a software project staffed by engineers working in shifts, where each new engineer arrives with no memory of the previous shift. That's what happens when an agent's context window resets.
Their solution, built into the Claude Agent SDK, uses two components: an initializer agent that sets up the environment on the first run, and a coding agent designed to make incremental progress in every session while leaving clear artifacts — notes, state files, checkpoints — for the next session to pick up. The SDK also includes compaction, which lets an agent work without exhausting the context window, but Anthropic acknowledged that compaction alone wasn't sufficient for sustained multi-window work.
Opus 5 doesn't eliminate these architectural challenges. But its efficiency gains change the math. If a model can accomplish more useful work per token, and if the cost per task drops meaningfully, then the economics of running agents for hours or days shift from experimental to plausible.
What Opus 5's Effort Setting Actually Does
The effort setting is the feature most likely to reshape day-to-day developer workflows. It lets you dial the model's reasoning intensity up or down, trading intelligence for speed and token cost. This existed in earlier Opus versions, but Anthropic's announcement shows Opus 5 delivers greater performance at a given cost than all other models at high, extra-high, and max effort levels on CursorBench 3.2.
For agent workflows, this is significant. Not every step in a multi-hour task requires peak reasoning. A model that can run at lower effort for routine file operations and ramp up for architectural decisions burns fewer tokens across a long session. That's not a theoretical benefit — it directly affects how many context windows you need and how much a sustained agent run costs.
Think of it as variable gear ratios. A model locked at max effort for every subtask is like driving in first gear on the highway. The effort setting lets developers (or the agent harness itself) shift gears based on task complexity.
The Boris Cherny Experiment: Rewriting an App Over Two Weeks with Claude
One of the most revealing examples of where long-running agents are headed came from Boris Cherny, head of Claude Code at Anthropic. In a Y Combinator Startup School interview flagged by Daring Fireball, Cherny described an experiment where he directed Claude to rewrite Anthropic's Electron-based desktop app in native Swift.
The setup was elaborate: Cherny used Claude Tag (Claude running in Slack) to spin up a macOS virtual machine via GitHub Actions, gave the agent access to an empty Swift codebase, and told it to compare its output pixel-by-pixel against screenshots of the Electron app. "Don't stop until you're done," he told it. At the time of the interview, the agent had been running for over two weeks.
What's instructive isn't whether the rewrite succeeded, but Cherny's framing of what makes these long-running tasks work. "The skill nowadays is less about prompt engineering and more about figuring out how do you give Claude a hard task that seems a little bit too hard," he said. "Then how do you make it possible for Claude to verify its work along the way? The verification is probably the single most important thing that people do not get right."
That emphasis on verification, not prompting, aligns directly with Anthropic's best practices documentation for Claude Code, which lists "Give Claude a way to verify its work" as the first recommendation, ahead of planning, context management, or environment configuration.
What This Means for Developer Workflows
The practical implications break down along a few axes.
Cost structure changes. Opus 5 matches Opus 4.8's pricing while delivering substantially better performance, according to Anthropic. For teams already running agent workflows, this is a straight upgrade. For teams that found Fable 5 too expensive for sustained use, Opus 5 at half the cost opens up workloads that were previously uneconomical.
Agent architecture matters more than model selection. The harness — how you structure context handoffs, checkpointing, verification loops, and environment access — is now the binding constraint, not raw model capability. Anthropic's Agent SDK provides a reference implementation, but teams building custom agent pipelines need to internalize the initializer-plus-incremental-progress pattern described in Anthropic's engineering post.
Verification is the new core skill. Cherny's point deserves repeating. The developers getting the most out of long-running agents aren't the ones writing the best prompts. They're the ones building robust verification — automated tests, visual diffing, CI checks — that the agent can use to self-correct. This is a meaningful shift in what "working with AI" means day to day.
Effort tuning requires experimentation. The effort setting is powerful but not self-configuring. Teams will need to develop intuitions (or automated heuristics) for when to run at high versus max effort. Anthropic's best practices documentation recommends aggressive context management and the use of subagents for investigation tasks — patterns that pair naturally with variable effort levels.
What Comes Next
Opus 5 doesn't solve the long-running agent problem. Context windows still reset. Compaction still loses information. Multi-day tasks still require careful architectural scaffolding. But the combination of better per-token efficiency, tunable effort, lower cost, and a maturing Claude Agent SDK infrastructure moves the needle from "interesting demo" to "viable production pattern" for a growing set of use cases.
The competitive pressure matters too: with Opus 5 available on GitHub Copilot and AWS Bedrock, developers aren't locked into Anthropic's own tooling. The model slots into existing workflows, which lowers the adoption barrier.
The real test will come over the next few months as teams push Opus 5 on sustained tasks in production — not two-week experiments, but ongoing agent workflows integrated into CI/CD pipelines, code review processes, and infrastructure management. The benchmarks say the model is ready. The tooling is catching up. The question now is whether developer teams are ready to restructure their workflows around agents that can actually sustain useful work across days, not just minutes.
