Live

Quorum‑AI

“What happens when four models disagree about your question?”

A costly run cannot start on a nod: the approval is a single-use, expiring token cryptographically tied — an HMAC, a keyed hash — to the account and the exact estimated cost, so a stale or borrowed approval is rejected with the estimate reattached. And agreement is never allowed to flatter: anything Quorum wrote itself — a simulated answer, a templated critique — is excluded from the evidence before consensus is scored, a rule added after a run once showed “4 of 4 aligned” while asking nobody.

GateCost approved before anything runs; fallbacks disclosed

Quorum-AI's verdict panel reading '4 of 4 models aligned, 3 revised their position', with a note that only 13% of claims carried citations

SAMPLE — an end-to-end acceptance fixture rendering canned data (e2e/fixtures/golden-run.ts), not a measured run. Live execution is off by default. The revision count is inferred from position movement, and the interface says so.

Tests2,095 python · 358 e2e
Coverage floor88%, enforced in config
Decisions32 ADRs, each named
Limits16 concurrent · 180s deadline
Not claimed
Latency · accuracy · adoption

What it does, and what it refuses

Works now

  • Four models answer in parallel; a separate moderator pass critiques them over two rounds
  • The four never read each other — there is no code path on which they could
  • Cost is approved before anything runs
  • Any fallback or simulation is disclosed on screen, never hidden

Known gaps

  • Round 2 is skipped when the per-run debate budget runs out, and recorded as skipped
  • Live execution is off by default — the interface says the output is local simulation
  • Consensus is lexical: 4-gram overlap and negation heuristics, captioned “inferred, not a tallied vote”
  • The moderator’s default model id is the same as answer slot 2’s — a separate call in a separate role, using the same model by default
  • The mutation gate is advisory in CI. Promotion to blocking was built, measured, and reversed

Not claimed

  • Latency
  • accuracy
  • adoption

The eval judge is a paid call several threads may need at once, so the first thread makes it and the rest wait on that one future. A reader that times out marks itself, so a verdict-less result never gets cached over a run the judge did verify. Its production readiness review records a Go dated 21 June and the No-Go it superseded five days earlier. Both are kept in the file.

Discussion

Comments need JavaScript and a GitHub account — the same account system the site's own code already lives in. Without either, read or start the thread directly on GitHub.