Model Peer: Why Self-Review Is Still Self-Review

Coding agents will review their own work if you ask them to. They will do it thoroughly, in a confident tone, and they will miss the same things they missed when writing it — because the reasoning that produced the bug is the reasoning now inspecting it.

That is not a criticism of any particular model. It is what self-review has always been. We have known it about humans for decades, which is why code review exists as a practice at all.

Model Peer applies the same fix to agents: get a second opinion from something that did not write the code, and is not talking to whatever did.

model-peer ask codex "Review this authentication design for bypasses"
model-peer review

It is MIT licensed and public at github.com/makedirectory/ModelPeer.

There is no chat between the models

This is the part that surprises people. Your agent is the hub. Each consultation spawns another vendor's CLI, read-only, gets one answer, and exits. Nothing persists between them.

Primary agent
    |
    +--> independent peer model --> advisory response
    |
    +--> primary agent evaluates the advice

The peer supplies evidence, not authority. Your project's rules and invariants still win — an answer that is sound in general and wrong for your codebase is still wrong, and the primary agent is the one holding that context.

model-peer review fans your Git diff out to every installed model separately. None of them sees the others' conclusions. Only afterwards does a synthesizer reconcile what came back.

              +--> Claude --+
              |             |
git changes --+--> Codex ---+--> synthesis
              |             |
              +--> Gemini --+

The independence is the mechanism

Here is the thing we had to be strict about: reviewers that can consult each other are not independent observations.

If model B can see model A's findings, agreement between them tells you nothing. It might mean the finding is real. It might equally mean B anchored on A's framing, which is exactly what people do in a meeting where the senior engineer speaks first. Two correlated opinions look like corroboration and are not.

So model-peer review never chains, and that is deliberate rather than an implementation shortcut. The panel is only worth running if agreement across it carries information, and agreement only carries information when the observations are independent.

--depth relaxes this for ask, and only for ask, where you are having a conversation rather than collecting a vote.

What we learned building it

Reviewers should look, not be shown. The peer starts in your working directory with read tools enabled. You name files and symbols and let it go and read them. Pasting code into a question means you have already chosen what is relevant — and if you knew what was relevant, you would probably have found the bug.

A global install is not a team habit. Installing the CLI gives you a command. It does nothing for the agent working in your repository. model-peer init writes skills into each vendor's own directory — .claude/skills/, .codex/skills/, .gemini/skills/ — so the agent consults a peer on its own before an architecture decision, on a bug that has outlived two hypotheses, on anything security-sensitive, and tells you which model it asked and whether it took the advice. Commit those files and the whole team gets the behaviour. model-peer update --check verifies them in CI.

Do not touch files you did not create. Your AGENTS.md, CLAUDE.md, and GEMINI.md are never read, written, or symlinked. A tool that edits your instructions file to install itself has made a decision that was yours to make.

Credentials stay with the vendors. Model Peer never asks you to paste an API key; authentication belongs to each CLI. Fewer places to leak from, and nothing for us to be trusted with.

Using it

curl -fsSL https://raw.githubusercontent.com/makedirectory/ModelPeer/v0.4.0/install.sh | bash
cd ~/code/your-project
model-peer init

As with any remote shell installer, read it before you run it. Then either drive it yourself with ask and review, or let the agent reach for it. In Claude Code you also get /peer-review for a cross-model review of the current diff.

The full guide is at modelpeer.app.

Where it actually helps

Not everywhere. For mechanical changes, a second model is a slower way to reach the same answer.

It earns its keep when being wrong is expensive and the answer is not verifiable in a few seconds: a security-sensitive change, an architecture decision you will live with for two years, a bug that has survived two confident explanations, a migration where the rollback story matters. In those situations, three independent reads that disagree is genuinely useful information — it tells you the thing is not as settled as it felt.

We use it on our own work, including the website you are reading. That is roughly the standard we would want from anyone we hired: not "the AI checked it", but "several things that could not see each other's answers checked it, and here is where they disagreed."

If you have a codebase where nobody is quite sure what a change might break, tell us what you are working with.