Cloud architecture
Pull request event
-> queue with commit SHA
-> isolated review worker
-> diff and repository policy
-> Claude or GPT API
-> verifier and deduplicator
-> review comment store
-> Git provider review API
The worker should not have write access to the repository. It needs the diff, selected files, test commands, and policy text. A separate publisher uses a short-lived token with the smallest review permission.
Model routes
| Review class | Candidate ID | Guard |
|---|---|---|
| Cross-module or security-sensitive | claude-opus-5-5 | Require evidence before publication |
| Routine TypeScript or Go diff | claude-sonnet-5 | Keep the rubric and fixture set current |
| Independent second opinion | gpt-6.1-sol | Mark findings by model ID |
| Narrow lint-style check | gpt-6-luna | Do not turn a weak result into a blocking review |
The live Claudexia catalog checked on October 4, 2026 contains these IDs. A model route can change when your evaluation changes. See current model details before a rollout.
Protect the job from duplicate events
Pull request systems can send several events for one commit. Build an idempotency key from repository, pull request number, commit SHA, and review policy version. Store it before calling the model. If the key already exists, return the previous result.
Give every job a deadline. A stuck model request should move to a retry queue or a human review state. It should not keep a worker and a pull request lock forever.
Context limits and data policy
Start with the changed files. Add the owning module's interface or test only when the reviewer needs it. Remove secrets, customer records, and private credentials before the prompt is built. Keep the original diff in the source-control system and store a hash in the review log when full retention is not allowed.
The repository may contain instructions written by an attacker. Mark the diff as untrusted data. Review rules belong in a protected system prompt or configuration file, not in a comment that the model can treat as policy.
Verification and publication
Ask for structured findings with a path, line, consequence, reproduction, and fix. Then verify each finding with a test, a source trace, or a contract check. Discard findings that cannot be tied to a concrete failure mode.
Publish one review per commit. Deduplicate by path, line, and finding fingerprint. If a finding is uncertain, leave it as a non-blocking note or send it to a maintainer queue. Do not let an unverified model response change the branch.
Observability that helps
Record commit SHA, policy version, model ID, queue time, model latency, parse status, number of findings, verified findings, and publication status. Keep the data needed to reproduce a result without copying private source into every log line.
Alert on queue age, repeated provider failures, malformed output, and a sudden change in verified-finding rate. A model can return HTTP 200 and still produce a result that fails your contract.
A rollout plan
Run the worker in report-only mode first. Compare its findings with human reviews for several releases. Add an automatic block only for categories with a low false-positive rate and a reproducible verifier. Keep a manual bypass for outages and false positives, with an audit record.
After a model update, replay the fixture set before sending traffic to the new route. Keep the prior model ID available until the new route has a stable review signal.
FAQ
Can cloud review run without storing source code?
It can store a hash and the review result while sending the necessary diff to the model provider. The exact retention plan depends on your data policy and provider terms. Decide it before launch.
Which model should block a merge?
Use a route that has passed your own verification fixtures, then block only for findings with a reproducible consequence. The model name alone is not a merge policy.
How do I avoid duplicate review comments?
Use an idempotency key for the job and a finding fingerprint for comments. Check the commit SHA before publishing.
Does a cloud worker need repository write access?
No. Give the worker read access to the required files. Keep review publication in a separate step with a narrowly scoped token.
Where do I compare Claude and GPT routes?
Use the AI review pipeline guide for the stages and the models documentation for the current IDs.