Opus and Sonnet on the Same Refactor

Using two models on one refactor works best when each has a clear job. In this walkthrough, Claude Opus 5.5 handles the initial design and an independent review, while Claude Sonnet 5.5 implements small, testable changes. These are workflow assignments, not a claim that either model is always better at a particular task.

The example is a service that calculates order totals. Pricing rules are mixed into an HTTP handler, and the goal is to extract them without changing observable behavior.

§ Step 1: Establish a clean baseline

Start from a clean branch. Run the existing tests, record the commands and results, and inspect the working tree. If tests already fail, document those failures before asking either model to edit anything.

Write a short refactor brief that both models will receive:

• Goal: Move order-total calculation into a dedicated module.
• Preserve: Response fields, rounding behavior, discount precedence, and error handling.
• Exclude: New pricing rules, dependency upgrades, and unrelated cleanup.
• Verify: Unit tests for calculations and integration tests for the handler.

This brief is the shared contract. Without it, a reasonable-looking improvement can quietly become a behavior change.

§ Step 2: Prepare the model connection

Vana API provides one endpoint that supports OpenAI-compatible requests as well as Anthropic Messages and Gemini native protocols. It works with Claude Code and other supported clients, so you can keep your development environment while changing which model handles a task.

Create a Vana API account, generate an API key, and follow the configuration instructions for your chosen client. Select the exact model identifiers shown in the service rather than guessing identifiers from display names. Keep credentials out of prompts, source files, and committed configuration.

Before starting, confirm the selected model in the client. When switching models, provide an explicit handoff; do not assume a new session inherits the previous conversation.

§ Step 3: Ask Opus for a bounded plan

Give Opus the brief, the handler, relevant helpers, and existing tests. Ask for a plan before any edits: “Identify the smallest extraction that preserves behavior. List invariants, likely edge cases, files to change, and tests needed. Do not implement yet.”

Review the proposal yourself. For this example, a suitable boundary is a calculation function that accepts normalized order data and returns the existing totals structure. Database access and HTTP response construction should remain outside it.

Reject unnecessary architecture. One extracted module is easier to verify than a new hierarchy of pricing strategies introduced during a behavior-preserving refactor.

§ Step 4: Give Sonnet one implementation slice

Pass Sonnet the approved plan, shared brief, and relevant files. Begin with characterization tests for current behavior, especially awkward cases such as empty orders, overlapping discounts, and rounding at fractional boundaries.

Then request the extraction: “Move the calculation into the agreed module. Preserve operation order and existing error behavior. Avoid unrelated formatting. Run the specified tests and report their actual results.”

Inspect the diff after each slice. If the change expands unexpectedly, stop and narrow the task. A small patch makes both human review and the second model's review more useful.

§ Step 5: Use Opus as an independent reviewer

Give Opus the original brief, the diff, and test output. Ask it to look for behavioral differences rather than defend its earlier plan: “Find concrete regressions or missing coverage. Cite affected code and explain a failing input. Separate confirmed issues from uncertainties.”

Pay particular attention to arithmetic order, mutated objects, exception timing, and defaults. An extraction can pass ordinary tests while changing one of these details.

Send actionable findings back to Sonnet for a focused patch. Require a regression test where practical. Treat model findings as hypotheses until supported by code inspection or execution.

§ Step 6: Verify and close the loop

Run the relevant suite, linting, and type checks yourself or through an authorized tool session. Confirm that reported commands actually ran. Review the final diff for scope creep, then summarize what moved, what stayed unchanged, and any remaining uncertainty.

Vana API bills by actual token usage with no monthly fee. Keep each handoff focused: include the contract, current diff, relevant files, and verification results rather than repeatedly sending the whole repository.

The useful outcome is not agreement between two models. It is a small, understandable refactor whose behavior is supported by tests and whose remaining risks are explicit.