How to Build Your Own AI Code Review Bot

Hosted AI review bots are easy to turn on, but you get their model, their price, and mostly just the comments they post. A pull request reviewer is an agent with a good prompt, a copy of the code, and a way to post a review, so you can build one in an agent harness you already use and own all of it.

This guide covers the setup I use: four cheap models from different providers each review the pull request, and one stronger model checks what they found before anything gets posted. It includes both prompts, the models and what they cost, and the build in Omnara, which the video above walks through in under five minutes.

Prices are as of October 14, 2026.

The Short Version

Why Build Your Own

• You pick the models. When a cheaper model comes out, you switch to it. You can also point a reviewer at your own fine-tuned or self-hosted model.
• You add the tools. Give the reviewer an MCP server for your issue tracker or internal docs, and it can check a change against them.
• You see everything it did. The whole trace is yours: every file it read and every command it ran. You can message the same session to dig into a finding.
• You own the whole prompt. Hosted bots let you add rules on top of theirs. Here you decide what it looks for and what it ignores.
• You pay per token. There's no review product to pay for on top of the models.

Hosted review bots still make sense if you don't want to maintain prompts. They handle setup and code indexing for you, and most learn from which comments your team acts on.

How an AI Code Review Bot Works

Most of what you pay for in an AI review is a model reading code: the diff and the files around it. So the cheap models do that reading. Each one reviews the whole pull request with the same prompt and sends back a short list of findings.

I use four reviewers from four different providers. In my experience, mixing providers catches more than running the same model a few times, because each has different strengths and blind spots.

Several reviewers find more problems, but they also produce more false alarms and duplicates. The main agent fixes that. It merges findings that describe the same problem, notes how many reviewers flagged each one, and checks every finding against the code before keeping it. It only reads the lines each finding points to, which keeps the expensive model's share of the bill small.

Cloudflare describes the same shape for its internal reviewer: up to seven specialized reviewers, and a coordinator on a top-tier model that "deduplicates their findings, judges the actual severity of the issues, and posts a single structured review comment."

Three choices in the prompts matter most:

• Say what not to report. Style nits, anything a linter or type checker would catch, and problems that were already there. Cloudflare's team found that "telling an LLM what not to do is where the actual prompt engineering value resides." Without it, you get a pile of comments that's a slog to read.
• Ask about the design, not just bugs. A bug or messy code is often a sign that something deeper needs a refactor. The reviewers can suggest a better approach the pull request didn't consider, and the main agent keeps at most two of these, in the review summary.
• Run only when tagged. If the bot reviews every push, every push is another review you pay for.

The Models

At standard rates, each reviewer costs a tenth or less of the main agent per input token. Any four cheap models from different providers will do, and you can change them whenever prices move. I run the main agent at medium reasoning effort, since checking findings doesn't need the highest setting, and the reviewers at medium too.

The Prompts

Reviewer

The same prompt goes to all four reviewers; only the model changes.

You review one pull request as part of a team of reviewers. The repository is already checked out at /workspace/repo. Your task gives the diff command to run, the base and head SHAs, and the PR title and description. Do not modify files and don't ask questions; work with what you have. Run that diff command and read the surrounding code you need.
Bugs: report problems this PR introduces or exposes. For each one, give the file and line, and whether the line was added or removed; severity, high (breaks behavior, loses data, security hole) or medium; what goes wrong and the concrete input or sequence that triggers it; and the code that proves it, quoted.
Design: don't stop at bugs. Question the approach itself. If a bug or awkward code is a sign the design is off, or there's a clearly better end state the PR didn't consider, say what the current approach is, what the better one would be, and why. Report at most 2 of these, and only ones you'd defend in a design review.
Do not report style, naming, formatting, comments, missing docs, anything a linter or type checker would catch, or pre-existing bugs. Report at most 5 bugs. If you find nothing real, say "none".

Main agent

This version uses the tool names from Omnara's GitHub integration. In another harness, swap in its tools or the gh CLI for reading the pull request and posting the review.

You review GitHub pull requests. Nobody answers questions or approvals, so never ask; decide and continue.
Only act when someone mentions you (bot_mentioned is true), and do what the mention asks. "Review" means review the whole PR the first time, and after that only the changes since your last review. For anything else on the PR, like "Pull request head changed from <a> to <b>" or comments that don't mention you, do nothing and end your turn.
1. Read the PR with int__github-bot__read: title, description, changed files, base and head SHAs, and the repository's full name.2. If /workspace/repo doesn't exist, clone https://github.com/<full_name> into it. Then fetch the base SHA and pull/<number>/head, which also works for PRs from forks, and check out the head SHA. Git credentials are already set up.3. If the change is only docs, lockfiles, or generated files, review it yourself and skip step 4.4. Archive any reviewers left from an earlier review with stop_agent (archive: true), then spawn the four reviewers in parallel (haiku, luna, deepseek, gemini). Give each the repo path, both SHAs, the PR title and description, and the diff command: git diff <base>...<head> for a first review, or git diff <last-reviewed-head> <head> for a follow-up.5. Wait for them instead of reviewing the diff yourself. Merge findings that describe the same problem and note how many reviewers flagged each. Verify each one by reading only the lines it cites and enough surrounding code to judge it. Keep it only if it is real, introduced by this PR, and reachable. Drop anything about style or anything speculative. Post at most 5 comments; fewer is better. Check design points the same way and keep at most 2 that hold up; they go in the review summary, not inline.6. Post one review. Read section pending_review first and discard any draft left from an earlier run. Then int__github-bot__start_review at the head SHA, int__github-bot__review_comment for each finding (review_id, path, line, and side RIGHT for added or unchanged lines or LEFT for removed ones; say what breaks, when, and a suggested fix), and int__github-bot__submit_review with a short summary that includes any design points and any finding without a line in the current diff. If nothing survives, submit a short review saying you found no issues.

Building It in Omnara

Omnara is an open-source agent platform with a GitHub integration that registers a GitHub App, starts the agent from pull request events, sets up Git credentials for cloning, and gives the agent tools to post reviews.

1. Make four reviewer profiles. Under Agents → New agent, create haiku-review, luna-review, deepseek-review and gemini-review, each with its model, the reviewer prompt, medium reasoning effort, and default-pool under Machine sources. A reviewer runs on the main agent's machine, so it sees the repo the main agent cloned; the machine source is what gives it the tools to run commands. Nothing else goes under Tools.
2. Make the main agent. Create GitHub PR Reviewer on Claude Opus 5.5 at medium reasoning effort, with the main agent prompt and default-pool with working directory /workspace.
3. Add the reviewers as subagents. Under Subagents, add each reviewer profile as an Agent profile with the key the prompt uses (haiku, luna, deepseek, gemini) and Max instances 1, and set Max active subagents to 4. The configuration docs cover the other subagent settings.
4. Connect GitHub. Under Integrations → GitHub PR review, name the integration github-bot so its tool names match the prompt, create the GitHub App, choose the repositories, and connect. In Pull requests, pick GitHub PR Reviewer, tick only Bot mentioned, and select Save changes.
5. Try it. From a GitHub account with write access to the repo, comment @<your-app-name> review on a pull request. The run appears under Agents → Instances, with the four reviewers working in parallel, and its Usage panel shows the cost, including the subagents.

Any model you've connected works, including OpenRouter, Anthropic, OpenAI, Amazon Bedrock, or a custom endpoint for a model you host yourself. To have it check your issue tracker or docs, add an MCP server to the main agent or the reviewer profiles, and set its tools to always allow. MCP tools ask for approval by default, and nobody is there to approve them. For a simpler starting point with a single reviewer, see the PR review agent example.

Building It with Claude Code, Codex, and Other Harnesses

The pattern needs three things from a harness: a way to run on a pull request, subagents that run in parallel, and a model setting for each subagent. Claude Code, Codex, OpenCode and Goose all document parallel subagents. Where they differ is whether each reviewer can use a different provider.

In most of these, the main agent posts the review with its own gh api call. Claude Code's Action is the exception: it has a built-in tool that posts inline comments, one at a time. Either way, let only the main agent post. For workflows triggered by pull_request, GitHub withholds secrets on PRs from forks, so the review won't run on them; comment-triggered workflows do get secrets, so limit who can trigger them.

What AI Code Review Costs

You pay for model tokens and the time the machine runs. The cheap reviewers do most of the reading, but the main agent's tokens cost the most, so keep its share small. Four things keep the bill down:

• Run only on mentions. A message the bot ignores, like a new push, costs one short model turn instead of a review.
• Keep the main agent from re-reading the diff. It should read the reviewers' findings and the lines they cite, not do its own full review.
• Use medium reasoning effort on the main agent. Reasoning tokens are billed as output, the most expensive part.
• Keep reviewers focused. Haiku 5.5 charges five times as much for any single request over 100,000 tokens, which a reviewer reading the whole repo can hit.

For a sense of scale, Cloudflare reports a median of $0.98 per review for its reviewer, which uses mid-tier models for the reviewers. The Usage panel shows what yours costs.

FAQ

Can the bot fix the problems it finds?

Yes, if you let it push. Turn on Let agents push code in the GitHub integration. Apps registered through Omnara already have Contents: Read & write; if yours only has read access, grant write access in the app's GitHub settings. Then ask the same agent, in the same session, to fix what it found and push a commit.

How do I stop it from leaving too many comments?

Tell the reviewers what not to report, cap the number of findings, and have the main agent check each finding against the code before posting. If it's still noisy, look at which comments people ignore and add those to the "do not report" list.

What's the best AI model for code review?

Use two kinds: cheap models from different providers for the reading, so their blind spots differ, and the strongest model you can afford for the main agent, since it decides what gets posted. Swap the cheap ones as prices change.

Can Claude Code or Codex review pull requests?

Yes. Claude Code's GitHub Action reviews a pull request when someone mentions @claude, and Codex has a GitHub Action and codex exec for workflows. Both can run reviewer subagents, but Claude Code only uses Claude models, and Codex keeps every subagent on the session's provider. To mix reviewers from different labs without a router, use OpenCode, Goose, or Omnara.

Do I need four reviewers?

No. One cheap reviewer and a checker already works. In my experience, more reviewers from different providers catch more, and each extra cheap reviewer adds little to the cost.