Route Coding Tasks by Risk: A Claude Agent Playbook for Sonnet 5 and Opus 4.8

A coding agent is not a single tool. It is a worker with a particular attention span, cost profile, and appetite for ambiguity. Treating every task as a reason to reach for the largest available model is as inefficient as assigning every production incident to the architecture team. Conversely, using a faster model for a migration with irreversible data consequences can turn a small saving into a long recovery.

The practical question is not, “Which Claude model is better?” It is: which model is appropriate for this unit of engineering work, given its uncertainty and blast radius?

For teams working with Claude Sonnet 5 and Claude Opus 4.8, a useful operating model is to route work according to four signals:

1. Problem ambiguity — Is the request explicit, or must the agent discover the real problem?
2. System coupling — Does the change stay local, or does it cross application, infrastructure, data, and security boundaries?
3. Failure cost — Is an incorrect answer a broken test, a noisy pull request, or corrupted production data?
4. Verification strength — Can CI prove the change is correct, or does correctness require architectural judgment?

This turns model selection from brand preference into an engineering control.

Think in lanes, not a single default#

Sonnet 5 is often the natural model for the high-volume lane: implementation tasks with a bounded goal, clear repository conventions, and strong automated verification. It is the model to consider when you want an agent to move briskly through well-lit terrain.

Opus 4.8 belongs in the deliberation lane: tasks where requirements are incomplete, local changes conceal system-wide effects, or the agent must compare several plausible approaches before editing code. Its value is not merely generating longer responses. It is spending more effort on the parts of software work that are easy to skip: identifying assumptions, tracing dependencies, and recognizing when a request should be challenged rather than implemented literally.

This distinction is best understood through examples.

A ticket says: “Add pagination to GET /orders, following the pattern used by GET /customers.” The API has integration tests, the persistence layer already supports LIMIT and OFFSET, and the expected response contract is documented. This is an excellent Sonnet 5 task. Give it the files, the established pattern, acceptance criteria, and commands to run. The agent’s job is execution.

A ticket says: “Make order history faster for enterprise tenants.” That is not yet an implementation task. It may involve query plans, tenant isolation, caching, pagination semantics, indexes, API behavior, and data-volume assumptions. Start with Opus 4.8. Ask for investigation, competing designs, measurements required, and a staged implementation plan. Only after narrowing the work should implementation move into the faster lane.

The key insight is that model routing can change during a single feature. Opus can frame the problem and define safe boundaries; Sonnet can implement discrete, testable slices inside those boundaries.

A practical routing matrix#

Use Sonnet 5 by default when most of the following are true:

• The requested outcome is concrete and unambiguous.
• The change has a recognizable precedent in the repository.
• The relevant files and subsystem are already known.
• Tests can validate behavior reliably.
• A failed attempt is cheap to revert.
• The task is primarily editing, wiring, refactoring, or writing focused tests.

Typical examples include:

• Adding a validated field to a TypeScript DTO and React form.
• Implementing a REST API endpoint that matches existing endpoint conventions.
• Updating CI configuration after a known runtime version change.
• Refactoring duplicated C# mapping code with passing unit-test coverage.
• Generating unit tests for an established service contract.
• Fixing a narrowly scoped bug with a reproducible failing test.

Route to Opus 4.8 when one or more of these conditions dominate:

• The prompt describes a symptom rather than a solution.
• The correct behavior is distributed across code, database schema, documentation, and deployment configuration.
• The agent must reconcile conflicting requirements.
• A change affects authorization, tenant boundaries, financial calculations, data retention, or migrations.
• The repository lacks clear conventions or adequate tests.
• The agent needs to reason about trade-offs rather than follow an established pattern.

Typical Opus work includes:

• Designing a safe PostgreSQL migration for a large, live table.
• Investigating a race condition spanning Node.js workers, Redis locks, and background jobs.
• Reviewing whether a proposed caching layer invalidates authorization assumptions.
• Planning a .NET service extraction from a tightly coupled application.
• Diagnosing a CI/CD failure that differs across runners, environments, or deployment stages.
• Performing a pre-implementation design review for a cross-service feature.

The blast-radius rule#

A helpful routing shortcut is to ask one question: What is the worst plausible effect if the agent is confidently wrong?

If the answer is “a test fails,” Sonnet 5 is usually a sensible first choice.

If the answer is “customers can see another tenant’s data,” “a deployment path becomes unreliable,” or “we may lock a database table during peak traffic,” raise the task to Opus 4.8 and require explicit reasoning before changes are made.

This is not a claim that a larger model eliminates risk. No model can substitute for review, access control, staging environments, backups, or observability. Instead, Opus is better positioned for work where the agent must slow down and surface uncertainty. The operational safeguards still belong to the engineering system.

For high-risk changes, make the agent produce an artifact before it produces a patch:

• assumptions and unanswered questions;
• affected services, tables, and interfaces;
• rollback plan;
• verification plan;
• non-goals;
• risks that require human approval.

That artifact is often more valuable than the first code diff. It converts hidden reasoning into something reviewers can inspect.

Design the handoff between models#

The strongest workflow is rarely “ask Opus to do everything” or “use Sonnet for everything.” It is a controlled relay.

Start with Opus 4.8 for exploration. Provide the issue, relevant architecture notes, logs, schemas, and constraints. Ask it to map the system and recommend the smallest safe change. Require it to distinguish facts found in the repository from assumptions.

Next, turn its output into a bounded implementation brief for Sonnet 5. The brief should name the target files, invariants that must remain true, interfaces that cannot change, commands to run, and acceptance tests. Sonnet becomes much more effective when it receives a narrow contract rather than a broad product request.

Finally, use Opus again selectively as a reviewer for changes with high conceptual risk. It can inspect the diff against the original invariants, identify missing edge cases, and ask whether the implementation solved the stated problem or merely satisfied the most obvious tests.

This three-stage pattern resembles ordinary engineering practice:

1. investigate and design;
2. implement a bounded change;
3. review against system intent.

The models are different participants in that process, not interchangeable autocomplete engines.

Make verification the deciding factor#

The model choice should also reflect how much your repository can prove. Strong automation expands the range of work you can safely give to Sonnet 5. A project with deterministic tests, linting, type checking, contract tests, database migration checks, and GitHub Actions previews has guardrails that catch many implementation mistakes.

Weak automation requires more judgment upstream. If a legacy system has sparse tests and undocumented deployment behavior, even a seemingly simple request may deserve Opus-led investigation. The issue is not that implementation is difficult; it is that feedback arrives late and may be ambiguous.

Before assigning an agent task, state the verification command and success condition. For example:

This instruction does more than improve execution. It reveals whether the task is truly bounded. If the team cannot describe how success will be established, the work likely belongs in the investigation lane first.

Avoid prestige routing#

The most common failure in model selection is prestige routing: using Opus 4.8 for every task because it is more capable, or using Sonnet 5 everywhere because it is faster and cheaper. Both choices hide an important distinction between complex code and complex decisions.

A large but repetitive code change may be ideal for Sonnet. A ten-line configuration modification may demand Opus if it alters authentication, network exposure, or production rollback behavior.

Measure outcomes rather than token counts alone. Track:

• time from task assignment to merge;
• number of review revisions;
• test and CI failure rate;
• escaped defects by task type;
• human time spent clarifying prompts;
• cost per accepted change, including rework.

Over time, these metrics reveal your organization’s real routing boundaries. They will differ between a mature TypeScript monorepo with comprehensive CI and a mixed estate of .NET services, PostgreSQL databases, and manually operated infrastructure.

The operating principle#

Use Claude Sonnet 5 where the path is known and feedback is fast. Use Claude Opus 4.8 where the path must be discovered, the stakes are high, or the right answer depends on system-level trade-offs.

Then make the choice explicit in your agent workflow. Label tasks as implementation, investigation, design review, or high-risk change. Define required inputs and verification for each label. Escalate when ambiguity or blast radius rises.

The result is not simply lower model cost or better code generation. It is a more disciplined engineering process: fast execution where certainty exists, deeper reasoning where uncertainty matters, and a clear boundary between what an agent can propose and what your delivery system must prove.