The Two-Model Coding Agent: Designing a Sonnet 5–Opus 4.8 Relay

A coding agent does not need one model for an entire task any more than a production system needs one process for every workload.

That distinction matters because software work changes character as it progresses. A task may begin as repository discovery, become a narrow implementation change, encounter an ambiguous failure, and end with a design review. Treating every phase as a single-model problem creates two predictable failures:

• Running the most capable model for every action makes routine work slower and more expensive than necessary.
• Running the faster model for every action can turn an apparently small change into a sequence of confident but shallow decisions.

A better approach is to design a model relay: a deliberate handoff between Sonnet 5 and Opus 4.8 based on the kind of reasoning currently required.

This is not a claim that one model is universally “better.” It is an operating model for coding agents. Sonnet 5 maintains forward motion through high-volume engineering work. Opus 4.8 enters when the agent must reconcile competing constraints, inspect a system-wide consequence, or recover from uncertainty that is no longer cheap to ignore.

Think in modes of work, not task labels#

Labels such as “feature,” “bug,” and “refactor” are too broad to decide which model should act. A bug can be a missing null check, or it can expose an invalid domain model. A refactor can be a mechanical rename, or it can alter consistency guarantees across services.

The useful unit is the reasoning mode.

Sonnet 5: the momentum engine#

Sonnet 5 is well suited to work with a clear local objective and a practical feedback loop. It can keep an agent moving through the repository without making every small action feel like an architectural summit.

Typical Sonnet 5 work includes:

• Mapping a repository’s structure and finding relevant files
• Reading nearby implementations to identify conventions
• Making constrained edits with an explicit acceptance condition
• Generating tests for already-understood behavior
• Resolving straightforward compiler, linter, or formatting failures
• Updating repetitive call sites after an interface change
• Summarizing command output, diffs, and test results
• Preparing a concise implementation brief for a deeper review

The defining trait is not simplicity. It is verifiability. If the agent can make a change, run a targeted check, inspect the result, and revise with little ambiguity, Sonnet 5 is a strong default.

For example, consider adding an optional pageSize parameter to a REST endpoint. If pagination conventions already exist elsewhere in the codebase, Sonnet 5 can find the analogous endpoint, trace the request through validation and data access, make the localized changes, and run the related tests. This is valuable work, but it does not necessarily require the deepest available reasoning at every command.

Opus 4.8: the ambiguity resolver#

Opus 4.8 earns its place when the problem cannot be safely solved by extending a visible pattern. Its role is not merely to write harder code. Its role is to examine the assumptions under the code.

Escalate to Opus 4.8 when the agent needs to:

• Compare multiple plausible designs with meaningful trade-offs
• Reconstruct an implicit business invariant spread across modules
• Evaluate concurrency, transactional, caching, or idempotency behavior
• Diagnose failures where tests, logs, and code tell conflicting stories
• Review a large diff for unintended coupling or abstraction damage
• Decide whether a local fix masks a broader system defect
• Plan a migration across public contracts, schemas, or service boundaries
• Challenge an implementation plan before it becomes expensive to reverse

Imagine a request to prevent duplicate invoice generation. A local guard clause may appear sufficient. But the deeper question is whether duplicates arise from retries, concurrent workers, at-least-once message delivery, a missing unique constraint, or an unclear state transition. That investigation crosses application logic, database guarantees, queue semantics, and operational behavior. It is a natural point for Opus 4.8.

The relay model uses Opus selectively because its output is most valuable when it changes the shape of the work, not just the wording of a patch.

Build a handoff artifact, not a vague escalation#

The most wasteful agent transition is: “This is complicated; ask Opus.” The second model then repeats discovery, rereads unrelated files, and spends context budget rebuilding a picture the first model already had.

Instead, have Sonnet 5 produce a compact handoff artifact. Treat it as a technical brief for a senior engineer joining midway through an investigation.

A useful handoff includes:

This format changes the role of Opus 4.8. It does not have to rediscover the system. It can assess the competing designs, identify missing evidence, and specify the invariant that the implementation must preserve.

After that, Sonnet 5 can return to implementation: add the constraint, adapt error handling, write focused tests, and verify migration behavior. Opus 4.8 can then perform a final review of the resulting diff.

The pattern is a relay, not a one-way promotion:

1. Sonnet 5 explores and implements.
2. Opus 4.8 resolves uncertainty or validates a consequential decision.
3. Sonnet 5 executes the approved direction.
4. Opus 4.8 reviews only when the residual risk justifies it.

Use explicit escalation signals#

A coding agent should not switch models based on intuition alone. Define observable signals that mean local iteration has stopped being reliable.

Good escalation signals include:

• Two reasonable implementations satisfy the visible tests but differ in system behavior.
• A fix requires changes across more than one bounded context or deployable service.
• The agent cannot state the invariant that the code is meant to protect.
• A test failure survives two targeted hypotheses.
• The change touches authorization, financial calculations, data retention, or externally consumed APIs.
• The implementation depends on timing, ordering, retries, or concurrent execution.
• The diff is growing because the original assumption appears wrong.

The key phrase is can’t state the invariant. If an agent says, “I changed this because it matches a neighboring file,” that may be acceptable for a mechanical edit. It is not enough for business-critical behavior. Opus 4.8 should be asked to turn implicit expectations into explicit, reviewable statements.

For example:

For a given external payment reference, the system must create at most one settled payment record, regardless of message retries or concurrent consumer execution.

Once that statement exists, implementation choices become testable. A unique index, an idempotency table, transaction boundaries, and error translation can all be evaluated against it.

Keep verification independent of model choice#

Neither Sonnet 5 nor Opus 4.8 should be the final authority on whether a change is correct. The repository’s verification system must remain independent:

• Type checking and compilation
• Unit and integration tests
• Migration validation
• Static analysis and formatting
• Contract tests for public APIs
• Focused concurrency or retry tests where relevant
• CI/CD checks in a clean environment

This protects against a common failure mode: a model generates a persuasive explanation for a change that has not actually been demonstrated. A strong agent workflow converts model reasoning into executable evidence.

For high-impact decisions, capture the invariant in a test name or acceptance scenario. For example:

That sentence is more than documentation. It becomes a durable boundary against future regressions, regardless of which model writes the next patch.

Measure the relay by outcomes#

Do not optimize this workflow around token counts alone. Measure whether the relay reduces expensive rework.

Track a small set of practical signals:

• Time from task start to a passing, reviewable change
• Number of failed implementation attempts before convergence
• Frequency of reverted or heavily revised agent-authored changes
• Defects found after merge rather than during CI
• Percentage of Opus 4.8 escalations that changed the implementation plan
• Review comments attributable to missed invariants or hidden coupling

If Opus 4.8 rarely changes Sonnet 5’s plan, the escalation criteria may be too broad. If issues repeatedly emerge after a Sonnet-only implementation, the criteria may be too narrow. The goal is not maximal use of either model. The goal is to place deeper reasoning precisely where it prevents a costly wrong turn.

The practical default#

Start with Sonnet 5 for discovery, bounded implementation, and fast verification loops. Escalate to Opus 4.8 when the agent encounters ambiguity with durable consequences: system invariants, architecture boundaries, concurrency, data integrity, or conflicting evidence. Then return to Sonnet 5 with a decision brief and a concrete implementation plan.

That division gives a coding agent two useful qualities at once: speed when the path is clear, and caution when the path disappears.

The strongest model-selection strategy is therefore not a permanent choice between Sonnet 5 and Opus 4.8. It is the ability to recognize when coding has stopped being an editing problem and has become a reasoning problem.