When to Use Claude Code With Opus — and When Not To

Most writing about Claude Code reads like a pitch: point Opus at any problem and watch it dissolve. That framing does the tool a disservice, because the teams that get the most out of it are precisely the ones who know its limits. Knowing when not to reach for an agentic coding tool is what makes the times you do reach for it pay off. A senior engineer's judgment is mostly a catalog of when not to do things, and agentic AI is no exception.

This post is the honest version: where Claude Opus inside Claude Code clearly wins, where a cheaper model or a plain script wins instead, and how to read a task before you spend on it.

Where does Claude Opus in Claude Code clearly win?

Opus earns its keep on problems that are hard to reason about and span more context than a human comfortably holds. Debugging an intermittent failure across several services, where the cause and the symptom live in different files, is a sweet spot — the 1M-token context window lets the agent hold the whole picture and trace the path. So is a refactor that touches dozens of files with subtle interdependencies, where consistency matters more than any single edit.

It also wins on unfamiliar terrain. Dropped into a codebase you have never seen, Opus can map the architecture, explain how a subsystem works, and locate where a change belongs far faster than manual exploration. The common thread is reasoning over breadth: tasks where understanding the system is the hard part, and writing the code is the easy part once you understand it. If you find yourself about to spend an hour just building enough context to start, that hour of comprehension is exactly the work the agent does best, and handing it over is almost always the right call.

When should you reach for something cheaper or simpler?

Plenty of work does not need a frontier reasoning model, and using one is quiet waste. Mechanical edits with an obvious pattern — renaming a symbol across a repo, reformatting, applying a known codemod — are better served by Sonnet 4.6, Haiku 4.5, or a deterministic script the agent writes once and you rerun forever. If the transformation is regular, the right tool is often not an LLM at all but the small program an LLM can produce in seconds.

flowchart TD
  A["Task arrives"] --> B{"Deterministic & repeatable?"}
  B -->|Yes| C["Write a script once, rerun free"]
  B -->|No| D{"Needs deep reasoning or wide context?"}
  D -->|No| E["Use Sonnet or Haiku"]
  D -->|Yes| F{"Stakes high / irreversible?"}
  F -->|No| G["Run Opus, verify the diff"]
  F -->|Yes| H["Opus + human approval gate"]

There is also a class of work where you should not use an agent at all, regardless of model. Decisions with real ambiguity about what to build, requiring stakeholder context the agent cannot have, belong to humans. No amount of context window substitutes for a conversation with the customer or a judgment call about priorities that only a person accountable for the outcome can make. The agent can draft, summarize, and prototype options, but the choice of direction is yours. Delegating judgment you have not yet formed yourself is how teams end up confidently shipping the wrong thing.

What are the honest failure modes?

Agentic coding has real weaknesses, and pretending otherwise erodes trust faster than the failures themselves. On a task that is genuinely underspecified, the agent will fill the gap with plausible assumptions and proceed confidently in a direction you did not intend — the unbounded session that burns tokens chasing a moving target. The defect is in the scoping, not the model, but it costs real money and time.

The other failure mode is verification debt. An agent can produce a large, convincing diff that passes a shallow look but contains a subtle error — a wrong edge case, a missed null path. The faster the agent produces output, the more tempting it is to skim the review, and that is exactly when bugs slip through. The discipline that makes the tool safe is treating its output like a capable but unsupervised junior's: trust, then verify, every time.

How do you decide in practice?

A workable heuristic has three questions. First, is the task deterministic and repeatable? If yes, write a script. Second, does it need deep reasoning or wide context? If no, route to Sonnet or Haiku. Only if a task is non-deterministic and reasoning-heavy does Opus become the right default — and even then, high-stakes or irreversible work should carry a human approval gate.

The meta-skill is reading a task before committing spend. A minute of classification up front prevents both kinds of waste: paying Opus prices for mechanical work, and sending an underbaked spec into an unbounded run. Teams that internalize this stop treating the tool as a hammer and start treating it as one instrument in a kit, reached for when the problem actually fits its shape.

How does this change for greenfield versus legacy work?

The same task can sit on different sides of the line depending on the codebase it lives in. On a mature legacy system, the agent's ability to hold wide context and trace through tangled dependencies is exactly the superpower you want, because the hard part is understanding what already exists. Opus shines when dropped into code nobody fully remembers, mapping the terrain and locating where a change safely belongs without a human re-learning the whole subsystem first.

Greenfield work flips the calculus. When there is little existing context to reason over, the bottleneck is no longer comprehension but decision — what to build, which abstractions to commit to, how the pieces should fit. Those are judgment calls the agent cannot make for you because they depend on intent you have not yet expressed. The right move on a blank slate is to let the agent prototype options quickly and cheaply, then make the architectural choices yourself, rather than handing it a vague goal and accepting whatever direction it confidently invents.

What about the alternatives?

The honest alternatives are not exotic. For repetitive transformations, scripts and codemods are faster, free to rerun, and perfectly reliable. For lighter agentic work, smaller Claude models cost less and respond faster. For genuinely novel design decisions, a human with the right context still outperforms any agent, because the hard part is knowing what to want, not how to express it.

None of this diminishes Claude Code with Opus — it sharpens it. The tool is at its best when it is the deliberate choice for hard, broad, non-deterministic problems, and at its worst when it is the reflexive default for everything. Drawing that line clearly is the difference between a team that is genuinely accelerated and one that is just spending more.

It also helps to remember that these choices are not mutually exclusive within a single task. A realistic workflow often blends all three: you use Opus to understand a thorny problem and design the fix, have it write a deterministic script for the repetitive part of the change, and reserve the genuinely ambiguous decisions for yourself. Treating the question as "agent versus script versus human" for the whole task is a false binary. The skill is decomposing a task into its parts and routing each part to the cheapest tool that can do it well — which, more often than people expect, means the agent does the thinking and a plain script does the grinding.

Frequently asked questions

When is Claude Opus overkill in Claude Code?

On mechanical, pattern-driven work — renames, formatting, known codemods — and on anything deterministic enough to script. These belong on Sonnet, Haiku, or a small program the agent writes once. Reserve Opus for hard reasoning over wide context.

Should I ever avoid agentic coding entirely for a task?

Yes — for decisions with genuine ambiguity about what to build that depend on stakeholder context the agent lacks. The agent can draft and prototype options, but the directional choice is human work. Delegating unformed judgment is how teams ship the wrong thing well.

What is the most common failure mode?

Underspecified tasks that send the agent into a confident but wrong, unbounded run, and verification debt where a convincing diff hides a subtle bug. Both are managed by scoping with an acceptance criterion up front and reviewing output like a junior engineer's PR.

Is a script ever better than an LLM here?

Often. If a transformation is regular and repeatable, a deterministic script is faster, free to rerun, and fully reliable. The smart move is to have Opus write that script once rather than re-running the model on every instance, which captures the agent's reasoning in a form you can audit, version, and reuse indefinitely at no further token cost.

Bringing agentic AI to your phone lines

CallSphere makes the same deliberate trade-offs when applying agentic AI to voice and chat — using the right model and the right guardrails so assistants answer every call and book real work 24/7. See it live at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.