Moding and vibe coding.

Building the interface got very cheap. Building the judgement did not. This is about the gap between those two, and what you can drop into it.

The gap

You can now describe an app and have it exist by lunchtime. Auth, a database, a deploy, a passable interface. The parts that used to take a fortnight take an afternoon, and the constraint moved somewhere else.

What did not get cheap is anything the app has to be right about. Wiring a model call is three lines. Knowing whether the answer coming back can be trusted is the actual product, and no amount of scaffolding generates it for you.

That is the gap. Most vibecoded apps that stall stall there — not because the builder could not ship, but because they shipped something confident and could not tell when it was wrong.

This is a different door from the editor guides

Worth being explicit, because it changes what you should read.

Our editor guides are about using Quorum while you work — an agent calls a panel mid-task. That is not this. If you are vibe coding, the interesting move is usually that Quorum goes into the thing you built, not into the editor you built it in. You are not the user of the panel. Your users are.

Which means the door is the API, not MCP.

One line, roughly

The API is OpenAI-compatible. Point base_url at Quorum and change the model string. Existing SDK code runs unchanged.

const client = new OpenAI({
  baseURL: "https://www.quorum.dog/v1",
  apiKey: process.env.QUORUM_API_KEY,
});

const r = await client.chat.completions.create({
  model: "quorum-standard",          // a Mode, not an engine
  messages: [{ role: "user", content: q }],
});

The important part is the second line of that call. model does not name an engine. It names a Mode — a saved configuration of which model families sit in which seats, how hard they argue, and what a call may cost. Modes, explained.

Why “moding” is the part that differentiates

When wiring a model call is trivial, choosing what sits behind it is where the judgement lives. Two apps can make the identical API call and be completely different products, because one of them thought about who should be in the room.

That is what a Mode is for. Picking one — or building one — is a product decision that survives the model churn underneath it. Engines get deprecated and replaced constantly. A Mode is a statement about how a question should be argued, and that outlives whichever specific model was best last quarter.

You can browse what exists on the Modes, or build your own at Build a Mode. A signed-in account is the whole requirement.

The two limits that will bite first

Both of these hit vibecoded apps harder than anything else, so they go before the pitch rather than after it.

1. There is no streaming

stream: true returns a 400. Not degraded, not slower — refused. This matters because almost every generated chat interface streams by default, so the scaffolding you started from probably assumes it. You will get a clean error rather than a mystery, but you will have to change the interface.

2. It is not fast. A deliberation runs several models and has them argue. Median 28.5 seconds, and 88.2 seconds at the ninetieth percentile, measured over 3,845 real deliberations. There is no version of this that feels like autocomplete.

Together those two mean a panel is a considered interaction, not a conversational one. The interfaces that work put it behind a deliberate action — a button that says the user is asking for a real answer — and show them something honest while they wait. The ones that fail drop it into a chat box where people expect tokens to appear immediately.

Where it fits in something you built

The one screen that has to be right. Most of your app does not need a panel. The review step, the recommendation, the thing a user will act on — that one might.
Behind a button, not in the stream. “Get a second opinion” is a good affordance. It sets the expectation of a wait and makes the cost legible.
As a check on your own output. Generate with a fast model, then pass the result to a panel and ask what is wrong with it. You are buying disagreement, not a rewrite.

And where it does not fit: anything mechanical, anything in a tight loop, anything where one right answer exists. A fast single model is better at those and always will be.

Cost, before you put it in a loop

Call	Time	What you pay
`POST /v1/estimate`	~0.9 s	nothing
`POST /v1/chat/completions`	28.5 s median	varies by Mode

Estimate classifies and prices a question without running it, and is free — not as a trial allowance, but because it costs us almost nothing to provide. Use it to decide whether a question deserves the panel before you commit a user to the wait. The escalation router covers that pattern properly, and the threshold is yours to set, not ours.

The paper

This page is the wiring. AI Deliberation & Vibe Coding is the other half: which question inside the app you generated is the one worth arguing about, what changes when the answer takes half a minute, and the worked jobs behind both. 14 pages, PDF.

Every paper in the series sits on the whitepaper shelf — one per surface.

Modes · Where deliberation thrives · The escalation router · Pricing, explained · API reference