Cross-Lab Adversarial Review (CLAR): A Definition

As the complexity of AI-operated projects increases, so does the opportunity for error. Assumptions are made. Details are missed. Focus drifts. And so, when the AI stops, the work often isn't done. The human operator is then left with reviewing the work, requesting changes, and then reviewing the new output. Skilled operators have already adopted correction practices to mitigate this problem.

One powerful technique is to recruit a second AI from another lab to perform a quality check. OpenAI ships an official plugin for software development that drops Codex into Claude Code as a reviewer.

A short name for it doesn't exist. Practitioners who write about the pattern reach for their own multi-word phrases, each a little different. You can't ask a team to "do the thing where the other lab's model argues," and a practice without a shared short name is hard to put in a checklist, budget for, or audit.

So, I propose a name:

Cross-Lab Adversarial Review (CLAR) is the practice of putting a model from a different lab against the work as an adversarial reviewer. The rival needn't be smarter; it's differently trained, so its blind spots are less likely to match. That is the value — decorrelation beats intelligence: their agreement carries real information, and the disagreement they can't resolve marks the call that still needs a human.

That definition is the whole of the term: a reviewer from a different lab, told to argue. Everything downstream — the evidence rules, the escalation, the tool that runs it — is how the practice gets implemented, not what makes something CLAR.

Why "Cross-Lab" is the Key

Adversarial review — telling any reviewer to challenge the work rather than rubber-stamp it — is good practice with any model. CLAR is differentiated by using a different lab. You find anecdotal evidence for model differentiation when talking to avid AI engineers: someone might prefer Opus for writing, Gemini for planning, and Codex for coding — three different labs. The difference is also backed by research.

The premise — that shared blind spots are the risk, and that crossing labs reduces them — is grounded in two findings. Great Models Think Alike and this Undermines AI Oversight (arXiv:2502.04313) finds model errors are substantially shared, and more so among more-capable models — the reason self- and same-model review is a weaker control than it looks. Correlated Errors in Large Language Models (Kim et al., arXiv:2506.07962) measures the overlap directly: models agree on the same wrong answers well above chance, with the correlation lower — but far from zero — across labs. Neither paper tests an adversarial-review protocol; they establish the problem CLAR responds to, not its effectiveness. Cross-lab review buys a discount on shared blind spots, not an exemption — which is why agreement stays evidence, not proof.

The first paper puts a direction on it: model errors, in its own framing, are becoming more similar as models grow more capable. Which turns the cheapest check you have — a model reviewing itself, or its sibling — into a control that's losing value.

Three Rules Define My CLAR Implementation

The definition stops short of any tool on purpose; the practice should outlive whatever implements it, and which labs and which models make sense for CLAR will change fast. But without discipline, a cross-lab review decays into two models trading opinions — confident, articulate, unfalsifiable. My implementation, below, is opinionated about three rules.

Every finding carries anchored evidence. A location and an observation — a line number, a named standard, a reproduction. Never a vibe. Evidence is what lets the first model check the claim against the actual artifact instead of debating tone.

A rejection needs contradicting evidence too. Verification is symmetric. The first model saying "I disagree" doesn't dismiss a finding; if it can't produce proof against it, the finding survives — recorded as a deadlock rather than waved away. Agreeableness corrupts a review in both directions.

The escalation is the deliverable. Most findings resolve — verified and fixed, or refuted with proof. What reaches the operator is the short list neither model could settle. If everything escalates, you've built a forwarder. If nothing escalates, you've built a rubber stamp.

For example, while building this site, Claude and Codex deadlocked on a diagram's color — Codex citing a WCAG contrast threshold for the mark against its background, Claude citing the design system's canonical diagram-ink token (specified in the website repository's DESIGN.md file), both right about their own half. Neither could win on the contradictory evidence, so the question reached me: the one decision in that batch of work that was actually mine.

The dozen or so other unambiguous mistakes were identified and sorted by a referee this essay names later. Claude automatically fixed those errors before I ever saw them.

What CLAR Is Not

A new discovery. The human antecedent is adversarial collaboration — opponents designing a fair test together, with an arbiter — as practiced by Mellers, Hertwig, and Kahneman (2001); CLAR points the same posture at models. The AI lineage approaches it from other angles: AI safety via debate (Irving et al., 2018) has competing agents argue before a human judge; multiagent debate (Du et al., 2023) improves answers by argument among instances of one model; LLM-as-a-judge (Zheng et al., 2023) has an external model score outputs; and PoLL (Verga et al., 2024) already juries across providers, aimed at judge bias and cost. Practitioners have described the cross-vendor adversarial version under longer names — "cross-model adversarial review" (Vaughan), "adversarial cross-model review" (Wade). CLAR is a short label and a discipline for a practice that was already emerging. The term was introduced here in July 2026.

The Reference Implementation

That referee is Impasse, the reference implementation of CLAR — open source, MIT-licensed, and deliberately dull in its mechanics. It hands the artifact to a rival-lab model with instructions to refute, requires structured findings with anchored evidence, and routes only genuine deadlocks to a person. It reviews more than code: a decision memo, an essay, a research claim, a dataset. And it is read-only on the work — the reviewer criticizes; it never edits. One caveat worth checking: Impasse selects the reviewer by provider relative to your host, and some configurations can't confirm the pick is genuinely a different lab. If yours can't confirm it, you haven't run a CLAR pass — you've bought a second opinion from the same blind spots. Verify the provenance.

The field story — what a rival reviewer caught over a day of real work, what it got wrong, what the arguing looked like — is in AI's Second Opinion.

Does the Reviewer Need to Be Smarter?

The CLAR definition claims a rival reviewer needn't be smarter than the model it checks. A July 2026 preprint directly challenges that claim.

Cross-Model LLM Code Review: Should you use Claude to review Codex or vice versa? (Xiang et al., arXiv:2607.21656) ran 116 hard and medium coding tasks through six conditions, pairing Claude Opus 4.7 with Codex GPT-5.5. The pairing helped in one direction and hurt in the other: Claude reviewing Codex lifted the pass rate from 71.6% to 89.7%, while Codex reviewing Claude dropped it from 91.4% to 82.8%. Self-review split too, lifting Codex from 71.6% to 84.5% and leaving Claude's 91.4% unchanged. The authors call the work exploratory, and flag that the results are sensitive to prompt wording and specific to these two models.

The two correlation papers cited earlier show that models make overlapping mistakes. Neither tests whether cross-lab review reduces the harm those overlapping mistakes cause. This preprint tests a review protocol itself — the first test of a cross-lab review protocol I've been able to find. Searching for earlier work turns up studies that benchmark models at review independently, and one that separates review into a fresh session with the same model, but none that put one lab's model against another's under a defined protocol. If an earlier one exists, I'd want to see it.

Codex reviewing Claude is the result that bites, and it establishes something narrower than "a weaker reviewer is a liability." Both models came from different labs, so cross-lab decorrelation was present by construction — and cross-lab decorrelation did not stop the lower-scoring reviewer from degrading the higher-scoring model's work. Decorrelation alone is not sufficient. The study also does not test CLAR's narrower claim: that independently generated disagreements identify the work worth checking. It records final pass rates, not which bugs each model caught.

The study's review protocol departs from Impasse's in three ways. In each, it is the study's reviewer being described, not Impasse's. First, the study's reviewer emits the final program: its instruction is to "produce a final corrected solution—either the original if it is correct, or an improved version," so it may leave the draft untouched, but it alone controls what gets submitted. Impasse's reviewer never holds the pen — it files findings, and the host makes the edits. Second, the study's reviewer cannot execute anything: "do NOT run or test the code; reason purely from code inspection." Static inspection isn't worthless — it produced the eighteen-point gain in the other direction — but it denies that reviewer any execution feedback, where an Impasse host checks each finding against the artifact with whatever evidence and tools the artifact allows. Third, the study requires no evidence and runs no verification step: a claimed defect goes straight into the submitted program. Impasse would make that same claim carry anchored evidence and survive verification before anything changed.

Two of those three — static-only review, and mandatory final-code emission — the authors name among their own limitations, noting that static review understates what tool-using agents with sandboxes could achieve, and that a reviewer with no separate non-intervention action may inflate harmful rewrites.

So a precise reading is narrower than "always use the more capable reviewer," and it still takes something from CLAR: even allowing for those protocol differences, the result defeats any claim that cross-lab decorrelation on its own makes a weaker reviewer safe. A setup that hands the reviewer control of the output, no execution, and no evidence requirement is easy to build by accident.

The capability question is less settled than that headline suggests. Bigger Isn't Always Better (Kumar et al., arXiv:2606.15689) evaluated five models on 150 code-review samples and found Claude Haiku 4.5 consistently outscoring its larger sibling Claude Sonnet 4.6 — higher F1 (0.365 against 0.343), 18% higher recall, better qualitative scores on all four dimensions, at 3.2 times lower cost per review. The result held across three sample sizes and was reproduced on a third-party benchmark with different repositories and a different judge. It measures review quality directly rather than a reviewer's effect on another model's pass rate, so it doesn't contradict Xiang et al. — the two ask different questions. What both suggest is that skill at review doesn't track model tier, and the pairing worth running is the one you've measured. Kumar et al. also report a caution that applies to every number in this section, including their own: on real pull requests, their best model scored an F1 of 0.066, against 0.847 on synthetic mutation-injected bugs — a 92% drop. Benchmark review performance is not field review performance.

Whether a propose-verify-escalate architecture changes that is untested, and I want to be careful about what I'm claiming. The study reports pass rates; it doesn't decompose why the rate fell, so "the reviewer's bad rewrites" is my reading of the mechanism, not a measured finding.

Impasse's approach to separating the critic from the pen and making each finding survive verification should reduce the damage a wrong call does. It doesn't remove it — a bad finding could pass verification and still reach the artifact.

My expectation is that the CLAR architecture does better here. I'd love to see a version of the experiment with the reviewer restricted to evidence-backed findings, the host verifying each one, and deadlocks escalated instead of silently applied — run by these authors or by anyone else. That would settle it.

What It Costs

Running CLAR uses more tokens, and requires access to a second lab's model. Wiring one agent to call another reliably takes work. And the failure mode is quiet: let the two models share a prompt, a style guide, a set of assumptions, and you've collapsed them into one reviewer with two logos — you've paid to agree with yourself more confidently. While the cross-lab review provides the most independent viewpoint, the more of that shared framing you hand the reviewer, the more its verdict slides back toward the first model's mold.

Decorrelation is something you protect, not something you get free with the second login. A CLAR pass is only as good as the difference between the two models you feed it.

The day-by-day account of this practice in the field — the deadlocks, the catches, the costs — is in AI's Second Opinion, and a single catch worth its own write-up — a spam filter that passed its own tests but would have dropped real leads — is in Green Tests, Two Bugs. Why the harness around a model matters more than the model is in the harness beats the model; how operators structure whole agent fleets is in your AI agents need an org chart.