Opus and Sonnet on a billing refactor

A billing refactor is a useful place to work with Claude Opus 5.5 and Claude Sonnet 5.5 on the same change. Consider moving invoice calculations out of request handlers into a shared service. The extraction looks mechanical until rounding, retry behavior, and transaction boundaries become visible. Two sessions can help, provided each has a bounded job and the repository carries the decisions between them.

Start with a provisional split: give Opus the initial design review and Sonnet the first implementation slice. Adjust that split when the output warrants it. The useful distinction is responsibility: one session examines behavioral boundaries; the other produces a patch against an agreed contract.

Write the invariants before requesting a plan. “Preserve behavior” leaves too much room for interpretation. Record the observable rules: round each line before summing, retain the existing error response for an invalid tax region, and ensure a retried request cannot create a second invoice. Include where each rule is established in code or tests. Ask the reviewing session to identify missing rules and distinguish confirmed behavior from assumptions.

Keep that review grounded in a narrow set of files. Supply the handler, calculation helpers, transaction wrapper, and relevant tests first. Ask for additional dependencies only when a specific uncertainty requires them. A large repository dump makes it harder to see whether a conclusion rests on inspected code or a plausible convention.

Turn the design into a handoff artifact. Before switching sessions, save a short repository note containing the proposed service interface, transaction ownership, error mapping, and unresolved questions. Add the base commit and exact verification commands. The implementation session should be able to explain the intended change from that note and the source files, without needing the earlier conversation.

• Define which files the first patch may change.
• State which externally visible behaviors must remain stable.
• Identify assumptions that need confirmation before editing.
• Specify the tests that demonstrate the extraction preserves those behaviors.

This artifact also limits accidental redesign. If the task is extracting calculations, changing the rounding policy belongs in a separate decision. Ask the implementation session to surface adjacent issues in its report and keep the patch within the agreed scope.

Implement one complete path first. Move a single invoice calculation through the new service, including its error handling and transaction behavior. Inspect the diff before extending the pattern to other handlers. This gives the reviewing session something concrete to challenge: an interface, a call site, and evidence that the path still behaves as expected.

For tests, target the reasons the extraction could fail. An ordinary invoice may pass even if rounding moved from individual lines to the final total. A retry test may be ineffective if it never exercises the persistence boundary. Request cases with inputs that distinguish the old behavior from a plausible mistake, and inspect whether the assertions actually detect that mistake.

Make the second review independent. Give the reviewing session the diff, the invariants, and the test results. Ask it to trace transaction ownership and error propagation from the entry point. Request findings with file locations, a concrete failure scenario, and the evidence behind the concern. Keep the implementation session’s explanation available for follow-up, but let the first review rest on the patch itself.

Separate worktrees help when both sessions edit. Give each a clear file boundary and integrate deliberately. Parallel edits to the same service contract tend to create reconciliation work; parallel inspection of distinct risks can be useful.

Keep routing stable while evaluating the workflow. Vana API provides an OpenAI-compatible endpoint at https://api.vanaapi.com and also supports the Anthropic Messages and Gemini native protocols. For a Claude Code workflow, this lets you keep the provider endpoint consistent while changing the selected model. Create a Vana API account to try this handoff on a bounded refactor, with usage billed per real token and no monthly fee.

Record input and output tokens, elapsed time, review findings, and human corrections for each pass. Count the context sent again during handoffs. Those measurements reveal whether the extra review catches meaningful defects and whether a shorter handoff would make the next refactor easier to finish.