Every AI reviewer generates findings it cannot stand behind. Dicast puts each one in front of three independent models that argue it out — and posts only what survives.
config.retries.Independent audits of AI review tools put 15–30% of their comments at low value or outright wrong. Teams don't filter that selectively — they mute the whole bot. The finding that mattered was in there somewhere.
A single model has no way to know which of its own findings it should have kept to itself. It is the author, the advocate and the judge at once. So it ships everything, and the filtering becomes your job.
Dicast splits the two jobs a reviewer does badly at once: finding things, and deciding which of them are worth your attention.
One fast model reads the full diff with your repository as context and proposes everything it suspects. Recall first — precision is not its job.
Each finding goes to three jurors drawn from three different model vendors, blind to one another. Each is asked to refute it, not to confirm it.
Two affirming votes to post a comment, three to block the merge. Everything struck stays on the record with the reason it was struck.
Panel size, vote threshold and what blocks a merge are yours to tune. Commit one file and the whole team inherits it.
# the panel that hears every finding panel: jurors: [anthropic, openai, google] threshold: 2 # votes required to post block_at: 3 # unanimous verdict blocks merge scan: paths: ["src/**", "!**/*.generated.ts"] max_diff: 3000 # larger PRs are split and heard in parts # house rules the jury must weigh rules: - "Money paths must be idempotent." - "No network calls inside a request handler." suppress: - style # the linter already owns this - test_coverage
The gate is a normal status check. Make it required in branch protection, or leave it advisory — Dicast never pushes commits and never merges on your behalf.
Jurors read the call sites, the types and the tests around a change, not just the lines that moved.
Every rejected finding is kept with its votes and the reason. When the panel is wrong, you can see exactly where.
Resolve a comment as "not useful" and that pattern carries a lower prior on every future hearing in the repo.
Write your invariants in plain language. They become evidence the jury has to weigh, not regex to maintain.
Per-package panels and thresholds. Payment code can demand unanimity while the docs site stays advisory.
Point the panel at your own vendor accounts on Scale, so inference runs under your contracts and your retention terms.
| Single-model reviewer | Dicast | |
|---|---|---|
| Who decides what you see | The model that wrote the finding | Three jurors from three vendors, none of which wrote it |
| Comments per pull request | Everything generated | Only findings that reach the vote threshold |
| When it is wrong | You find out by reading it | Usually caught by a juror before it is posted |
| Rejected findings | Never existed as far as you know | Kept on the record, with votes and reasons |
| Blocking a merge | Severity label from one model | Unanimous verdict, configurable per path |
Struck findings don't count against your quota — you are billed for pull requests heard, not comments generated.
Open source repositories are free. Public repos get the full panel with no pull request limit — no application, no logo on our site required.
Because the failure mode isn't capability, it's calibration. A model that generates a finding is a poor judge of whether that finding is worth your time — it has already committed to it. A juror that did not write the finding, and is asked to refute rather than confirm it, has no such commitment. Vendor diversity matters for the same reason: models trained on overlapping data make correlated mistakes, so a panel of three from one vendor agrees with itself far more often than it should.
No, because the panel doesn't review your code — it reviews the findings. One inexpensive pass reads the diff, and only the candidates it produces go to the jury, where each hearing is short and the three run in parallel. In practice a review lands in the same window you'd expect from a single-model reviewer.
Diffs and the context needed to review them are sent to the model vendors configured for your panel, held for the duration of the review, and not retained afterwards. We never train on customer code. On Scale you can point the panel at your own vendor accounts, which keeps inference under your own contracts and retention terms.
The panel is language-agnostic — it reasons over your diff and the surrounding code rather than a parser. Repository context is strongest where the ecosystem gives us a dependency graph to walk: TypeScript, JavaScript, Python, Go, Ruby, Java, Kotlin, Swift, Rust, C# and PHP.
A verbosity setting drops findings by severity label, which the same model assigned. You lose real bugs it ranked low and keep noise it ranked high. A vote threshold drops findings by whether independent reviewers could refute them, which is a different axis — and you keep the record of what was dropped, so the filter is auditable rather than a dial you guess at.
Only if you make it required. Dicast publishes a normal status check; branch protection is yours to configure. It never pushes commits, never merges, and never requests changes on behalf of a human reviewer.
Install on one repository, keep your current reviewer running beside it, and compare what each of them thought was worth saying.