Summary: OpenRouter published a Python tutorial on November 1, 2026, showing how to build an AI code reviewer that runs your changed files in a hosted Linux sandbox before you push or merge. The 233-line script uploads diffs via the Files API, lets the model reproduce suspected bugs with a shell tool, and returns fixes as patches you apply with a flag. Tested on a five-bug change, reviews took one to four minutes and cost $0.015 to $0.045 depending on model.
Why a diff-only reviewer guesses
Most AI reviewers read the diff and speculate about everything around it — what the imports resolve to, whether a suspected bug actually fails at runtime. OpenRouter’s tutorial argues the fix is to give the model real execution. The script uploads full changed files, test files, and the Git diff into a hosted Linux container, so the model can write and run a short check that proves a bug before reporting it.
That’s the same tradeoff I keep coming back to when building agentic tools: reading code is cheap but verification is what makes output trustworthy. I covered the mechanics of this pattern in what a hosted sandboxed shell changes for how you build agentic tools — this tutorial is a concrete, end-to-end application of it.
How the script is wired together
The reviewer combines three OpenRouter server tools and one function tool on the Responses API:
- Files API (beta) — uploads up to 19 files plus the diff, matching the 20-file limit per request.
- Shell tool (
openrouter:shell, beta) — copies uploads into a container’s home directory so any model can run Python and SQLite against your code. - Apply Patch tool (
openrouter:apply_patch, beta) — the model proposes fixes as V4A diffs; OpenRouter validates syntax automatically, but your application does the actual file write. submit_reviewfunction tool — a strict JSON schema for the final answer, becausetext.formatwithjson_schemawas not enforced on Claude Haiku 5.5 when tools were present in the request.
A detail worth copying for your own agents: the script exits 1 when a finding meets the severity threshold (--block-at, default high), so it drops straight into a Git pre-push hook or GitHub Actions as a gate. The full report goes to .git/ai-review.json so it never gets committed.
The findings come labeled
Every finding is marked either confirmed — with the command and output that proved the bug — or unconfirmed, for issues like leaks or races that a quick script can’t demonstrate. That distinction is the most useful design decision in the whole tutorial. It turns “the model thinks there’s a bug here” into “here is evidence,” which is what you need before letting CI block a merge.
The prompt also treats file contents as data, never instructions — a basic prompt-injection guard, since the model is reading arbitrary code.
Benchmark numbers from the tutorial
OpenRouter reports results from its own benchmarks on a five-bug change: Claude Haiku 5.5 averaged $0.0153 per review, while Claude Sonnet 5.5 fixed all five bugs in all three runs at $0.0447 and about 60 seconds. Four models were tested overall.
Limits to know before you run it
A few constraints from the guide matter if you’re planning to adopt this:
- The Files API, Shell, and Apply Patch tools only work on the global endpoint; in-region endpoints return 403.
- The Shell tool works on the Responses and Messages APIs but returns 400 on Chat Completions.
- Uploaded files are sent to your OpenRouter workspace and the model provider — keep secrets out and only review code you’re allowed to share.
- Patches are applied to a scratch copy locally, not in the sandbox, so the model’s checks ran against the original code. Run your tests after
--apply.
The takeaway: if you’ve been using AI review as a suggestion box, execution-backed review changes the unit of output from prose to evidence-plus-patch. The natural next step is running the script on one of your own repos in CI and calibrating --block-at before trusting it as a gate.