Multi-model AI code review: several AIs review the diff before you merge

Multi-model AI code review on Council AI means pasting a diff, a file or a design document and having several models from different labs review it independently, then reading one merged review. It works because models from different labs have different blind spots: the race condition one model waves through is often the one another flags. Review by a different model also avoids the self-review problem, where the model that wrote the code shares the assumptions that produced the bug. The council reads what you paste. It does not run your code or your tests, so it complements CI and a human reviewer rather than replacing them. On Ultra, the same council can be called from Claude Code, Cursor or Windsurf through the Council MCP server.

What several reviewers catch that one misses

• Concurrency and ordering bugs. Races, missing awaits, double-submits and state that is read before it is written. These are the bugs a single reviewer most often reads past.
• Edge cases. Empty inputs, nulls, time zones, retries that are not idempotent, pagination that drops the last item.
• Security slips. Unvalidated input reaching a query or a shell, secrets in logs, an authorization check on one route but not its sibling.
• Architecture trade-offs. For a design doc: where the plan couples things that will need to change separately, and where the models disagree about whether that matters.
• Disagreement as a signal. When half the council calls something a bug and half calls it fine, that is exactly the line worth a second look, and the verdict says so.

A worked example

Paste the diff with enough context to judge it, and ask for a review, not a rewrite:

Review this diff for bugs only, not style. It adds retry logic to our payment webhook handler. For each problem: the line, what goes wrong, a concrete input or sequence that triggers it, and the smallest fix. Say explicitly if you think the change is safe to merge.

The verdict lists the problems most models found first, then any bug only one model raised with its trigger sequence, and ends with whether the council converged on "safe to merge" or stayed split.

How it works

1. Bring the finished work. Paste it or attach it, and say what you want checked. A clear instruction ("find what is wrong with this") gets a review; a vague one gets a summary.
2. Several models review it independently. Each model in your council, from a different lab, writes its own review. The first round is blind unless reading each other clearly helps, so no review is a copy of another.
3. One verdict, with the dissent listed. A moderator model reads every review and writes one verdict. Points most models raised come first; a point only one model raised is listed under it instead of being averaged away.

Limits worth knowing

• Council size: up to 7 models per question on Plus, up to 10 on Pro and Ultra, picked from 21 models across 9 labs.
• Files per message: Plus 4 files of up to 10MB each, Pro 5 of up to 20MB, Ultra 10 of up to 50MB.
• Text per message: about 200,000 characters of extracted text per file and across all files in one message (roughly 120 pages). A file over that is refused with a message saying so, never silently cut.
• Agreement is a stronger signal, not a guarantee. Several models can share the same mistake, so the verdict lists the dissent rather than hiding it.
• Code files and plain text attach directly. Paste a diff as text when it is shorter than the files it touches.
• The models read code; they do not execute it, run tests, or browse your repository. Give them the context they need in the message.
• Ultra adds the Council MCP server, so an agent in Claude Code, Cursor or Windsurf can send a diff to the council and get the verdict back in the terminal.

When a council is the wrong tool

Style nits a linter already catches, large refactors you cannot paste with enough context, or anything where only running the code will tell you the answer.

Related

• Council MCP server: Call the council from Claude Code, Cursor or Windsurf (Ultra).
• Best AI for coding: How the current models compare on code, and why the answer depends on the task.
• Research verification: The same independent-review pattern, applied to claims and evidence.

Frequently asked questions