AI
Claude Code Ultrareview: A Verified Multi-Agent Review
August 202612 min read
A deep code review that runs on Claude Code on the web infrastructure. Running /code-review ultra launches a fleet of reviewer agents in a remote sandbox, and every reported finding is independently reproduced and verified before it reaches you. A review typically takes five to ten minutes and runs as a background task.
Pro and Max accounts get three free runs as a one-time allotment that does not refresh; Team and Enterprise get none. After that, expect roughly 5 to 25 dollars in usage credits depending on the size of the change. A run counts once the cloud session starts, so a review you stop early still uses a free run.
It depends on the mode. For a branch review, Claude Code bundles the repository state and uploads it to the remote sandbox. For a pull request review, Claude Code uploads nothing from your machine — the sandbox clones the pull request directly from the host. If uploading is a policy concern, use pull request mode.
A branch review covers up to 500 changed files and 8,000 changed lines by default. The refusal names the limits in effect, your diff's size, and the files with the most changed lines. If the repository is too large to bundle, push the branch, open a draft pull request, and review by PR number instead.
Yes, with the claude ultrareview subcommand. It blocks until the remote review finishes and prints findings to stdout, with progress and the session URL on stderr. Exit codes are 0 for completed, 1 for a launch failure or timeout, and 130 for interruption. Interrupting the subcommand does not stop the remote review.
Key Takeaway
Ultrareview is a deep code review that runs on Claude Code on the web infrastructure. It launches a fleet of reviewer agents in a remote sandbox, and every reported finding is independently reproduced and verified before it reaches you. A review takes roughly five to ten minutes and bills against usage credits after a small free allowance.
The reason I stopped trusting most automated review output is that it was mostly right, which is worse than mostly wrong. A tool that reports twelve issues where nine are real and three are plausible fabrications costs you more attention than it saves, because you have to check all twelve to find out which three to ignore.
Ultrareview's answer is to do that checking itself: every finding is independently reproduced before it is reported. That single design decision is what separates it from the local review, and it is also why it costs money and takes ten minutes. This post covers when each review is the right one, what actually gets uploaded, the diff limits, the pricing including when a run counts against you, and running it from CI.
Both examine code and they are not competing. The local review is for feedback while you iterate; ultrareview is for confidence before you merge. Using either in the other's slot is how you end up disappointed in both.
Where each one belongs:
| Dimension | Local review | Ultrareview |
|---|---|---|
| Runs | Locally in your session | Remotely in a cloud sandbox, terminal stays free |
| Depth | Scales with the effort argument | A multi-agent fleet with independent verification |
| Duration | Seconds to a few minutes | Roughly five to ten minutes |
| Cost | Counts toward normal usage | Free runs, then roughly 5 to 25 dollars in usage credits |
The argument parsing is more considered than it first appears, and knowing the rules avoids a confusing launch. The command only ever runs when you invoke it — Claude does not start an ultrareview on its own.
# Your current branch against the default branch, including
# uncommitted and staged changes.
/code-review ultra
# Against a different base. The branch does not need to exist
# locally — Claude Code fetches it from origin, and a typo gets
# a closest-branch suggestion rather than a failure.
/code-review ultra develop
# A pull request. Also accepts #1234, PR 1234, and pasted URLs
# pointing at the repository you are in.
/code-review ultra 1234
# Plain words become a NOTE, not a scope change. The review
# still covers your current branch.
/code-review ultra check my auth changes
# Text is a note only when it is more than one word and is not
# a branch name or PR reference. A single word is read as a
# branch or PR. And a PR reference mixed with other words —
# "check PR 123 again" — launches nothing; it asks you to
# rerun with the number alone, or without the reference.This distinction matters for anyone reviewing the feature rather than just using it. For a branch review, Claude Code bundles the repository state and uploads it to the remote sandbox. For a pull request review, Claude Code uploads nothing from your machine at all — the sandbox clones the pull request directly from the host. If the upload is the part your policy cares about, pull request mode is the one that avoids it.
That difference has a practical use beyond policy. If your repository is too large to bundle, Claude Code prompts you to switch to pull request mode — push the branch, open a draft pull request, and review by number. The sandbox then clones from the host and the size ceiling on bundling stops applying, which is a much better answer than trying to shrink the diff.
Ultrareview validates the diff before any review runs, which means you find out in seconds rather than after paying for a review that could not complete:
Ultrareview bills against usage credits rather than your plan's included usage, which makes it the rare Claude Code feature with a per-invocation price. The details are worth knowing before the first launch:
Stopping a review mid-flight gets you nothing. Claude Code archives the cloud session and does not return partial findings — so a run you abandon at minute eight has cost you a free run or a partial bill and produced no output at all. Decide before you launch rather than after, and use the confirmation dialog's scope and estimate to make that call.
On a github.com pull request you can have Claude post the finished findings as a single plain comment from your own account. It is not a review and not an approval, and it ends with a note saying it was generated by Claude Code. Not posting is the default and consent is per run: interactively you choose it in the launch dialog, and non-interactively you consent by passing the flag.
Two operational details will bite otherwise. Claude Code does not post from your machine — it sends the findings to a session on the web, which posts through your connected GitHub account, so posting is unavailable on third-party providers and when non-essential traffic is disabled. And in an interactive session the post starts when the findings arrive, so if the session ends before the review finishes, nothing is posted even if you resume the conversation later.
The subcommand is the form to use in a script, and it behaves like a well-designed CLI tool rather than an interactive command wearing a disguise. It blocks until the remote review finishes, prints findings to standard output, and puts everything else on standard error.
# The subcommand blocks until the remote review finishes and
# prints findings to stdout. Progress and the live session URL
# go to stderr, so stdout stays parseable.
claude ultrareview
claude ultrareview 1234
claude ultrareview origin/main
--json raw payload instead of formatted findings
--timeout <minutes> default 30
--post post findings to the PR as one plain
comment from your GitHub account
--no-post the default; wins if you pass both
# Exit codes:
# 0 review completed, with or without findings
# 1 failed to launch, cloud session errored, or timed out
# 130 interrupted with Ctrl-C
#
# Interrupting the subcommand does NOT stop the remote review.
# Follow the session URL on stderr to watch it in a browser.There is a distinction between the subcommand and running the slash command non-interactively that matters for automation. The subcommand blocks until findings arrive; the slash command in a non-interactive session launches the review, prints a tracking link, and exits without waiting — which also means it posts nothing, because it is gone before the findings exist. When the review would bill usage credits, the slash command stops before launching and points you at the subcommand, because the billing confirmation needs an interactive session.
The feature to judge here is the verification, not the fleet. Plenty of tools can point many reviewers at a diff; the useful part is the one that throws away everything it could not reproduce, because that is what converts a list you have to check into a list you can act on. Reach for it before merging something substantial, use pull request mode when the repository is large or the upload matters, and decide to run it before you start rather than eight minutes in.
Sources & further reading