Which Model Should Handle Automated Code Review?

Automated code review needs a routing policy before it needs a favorite model. A documentation edit, a database migration, and a permissions change deserve different treatment. The useful question is which model can find actionable problems in each category, with enough evidence to justify a comment and at a cost your team can sustain.

Here is a practical walkthrough for building that policy, testing it against your repository, and running it through Quanta.

01 · Step 1: Define what the reviewer must catch

Start with a narrow review contract. Ask the model to identify defects introduced by the change, explain the failure condition, and cite the relevant file and lines. Require a concrete consequence, such as incorrect output, unauthorized access, or a failed deployment.

Specify that formatting preferences and speculative refactors belong outside this review. Allow an empty findings list. A reviewer that always produces a comment creates work even when the patch is sound.

02 · Step 2: Classify changes by risk and context

Build routing rules from repository signals before making a model call. File paths, changed symbols, diff size, and ownership metadata provide a useful first pass.

• › Routine changes: Small patches with local behavior and clear tests can enter your standard review route.
• › Context-heavy changes: Shared interfaces, dependencies, and behavior spanning several modules need broader repository context.
• › Sensitive changes: Authentication, authorization, billing, migrations, and destructive operations should trigger deeper review and human ownership.

Treat these classifications as starting points. A tiny patch can still remove a critical permission check, so line count alone should never determine the route.

03 · Step 3: Compare candidates on your own patches

Choose two candidates to evaluate, such as Claude Sonnet 5.5 and GPT-6 Astra. Treat their suitability as a question to test. Build a sample of historical patches containing confirmed defects, clean changes, and bugs that required knowledge beyond the diff.

Give each candidate the same review contract and evidence. Check whether it finds the real defect, supports the finding, and avoids inventing problems. Keep some patches outside prompt development so your final comparison includes unfamiliar examples.

Record actionable findings, missed defects, false alarms, elapsed time, and actual usage charges. Select the standard route from those results. Select an escalation route only if it demonstrates useful additional coverage.

04 · Step 4: Send the smallest complete evidence package

A diff rarely explains the whole change. Include the pull request description, applicable repository instructions, surrounding functions, and relevant tests. For an interface change, include important callers. For a migration, include the schema assumptions and deployment sequence.

Expand context when a specific dependency requires it. Preserve enough information to evaluate behavior while keeping unrelated files out of the request. Stable instructions and reusable context may benefit from caching where supported; verify how your chosen route handles cache usage.

05 · Step 5: Escalate on explicit review signals

Run the standard route first for eligible changes. Escalate when repository rules flag sensitive code, the first review identifies a potentially serious defect, or a finding depends on an unresolved interaction across files.

Send the escalation reviewer both the underlying evidence and the proposed finding. Ask it to test the claim, identify counterevidence, and explain whether the failure is reachable. Agreement between models is a signal to inspect, not proof of correctness. Keep consequential approval decisions with the responsible engineer.

06 · Step 6: Connect routing to measured spending

Quanta fits this workflow when you want several model routes under one pay-as-you-go balance. Configure your review service through an OpenAI SDK with the API base address https://api.quantarelay.com, then select the model assigned to each route. Open a Quanta account to put that policy into practice.

Every call is metered on real tokens, with cache writes and cache reads priced separately. Track those categories alongside ordinary input and output usage. Compare total review cost per patch, including retries and escalations, against the useful findings it produces.

07 · Step 7: Recheck the route as the repository changes

Sample accepted and dismissed comments regularly. Investigate missed defects and update the evaluation set when new failure patterns appear. Repeat the comparison when changing models, prompts, or context retrieval. Your routing policy should earn its place through observed review quality as the codebase evolves.