Modes: saved consensus presets

A mode is a named, per-send preset. It bundles the decisions that shape a consensus run — who synthesizes, who weighs in, which models each of them sends, what stance they take, and how many rounds they get — so you can switch between recipes in one click instead of re-pointing your primary and toggling providers each time. Modes tune the consensus run; they never bypass it.

What a mode bundles

• Primary — the provider, and the model, that synthesizes the final reply. A valid mode’s primary overrides both your global primary and the per-window model pick while it’s active.
• Panel — which providers fan out. A mode’s panel is either Inherit user defaults (your enabled-model roster, minus any provider you’ve Muted in Settings → Providers) or an explicit set. An explicit panel overrides your Mutes — only the named providers fan out, even ones you’ve muted globally.
• Models — per panel member, which of that provider’s models the mode sends. Leave a member’s models unselected and it keeps using your own Settings defaults for that provider.
• Roles — per panel member, Panelist or Critic.
• Rounds — Single pass, or Debate for one extra round of revision.
• System-prompt append — optional text appended after your project context on every send the mode runs. It adds to the system prompt; it does not replace project context.

Models: a mode’s picks replace your defaults

This is the knob that most determines what a run costs and how good it is, and it works differently from the panel toggle above it.

A mode’s model picks replace your Settings defaults for that provider rather than narrowing them. A mode can therefore send a model you have not enabled globally — choosing the mode is the selection. Leave a member’s Models row empty and nothing is overridden: that provider contributes whatever you have enabled in Settings.

Picking models is a row of chips you remove one at a time. Add model opens a searchable list in three groups — what’s already In this mode, what you’ve Enabled in Settings, and All <Provider> models — because a flat checklist is unusable against a gateway that serves hundreds. Clearing the last chip returns the row to your defaults.

The Models row is there whether or not the panel inherits your defaults, and it stays on a member you’ve unchecked (captioned “Applies when this member is enabled.”), so toggling a member off no longer discards the models you’d chosen for it.

Pinning the primary’s own model

The primary’s row offers the primary’s own model alongside its siblings. Selecting only that one means “send the synthesis model and no other peers from this provider” — a useful thing to say when you want one provider’s voice writing the answer without its other models also voting. With nothing selected, that provider still contributes every model you have enabled globally, on top of synthesizing.

Roles: Panelist and Critic

Every panel member except the primary gets a role. A Panelist answers the question as asked — today’s behavior, and the default. A Critic argues the strongest case against the likely consensus and names failure modes, while still giving a complete answer.

A Critic is labelled as one in the inspector’s trace cards and split cards, so an outlying reply reads as the role working rather than as a provider being wrong. The primary is always a Panelist and carries no role control: it synthesizes, and a synthesizer arguing against its own consensus would be incoherent.

Roles naming providers that aren’t part of the resolved panel are ignored rather than invalidating the mode.

Rounds: single pass or debate

Debate runs one extra round. Every peer sees the other peers’ first drafts — labelled Draft A, Draft B, … with no provider names attached — and revises once before synthesis.

The editor states the cost where you turn it on: “Debate runs one extra round: every peer sees the others’ first drafts and revises once before synthesis. About 2× the fan-out cost per exchange.” Both rounds are billed and both count toward the inspector’s aggregate and Settings → Usage. Note also that a debate round sends each peer the other peers’ text, which nothing else in Polycode does — see fan-out and consensus.

Creating and editing modes

Open Settings → Modes — “Bundle a primary, panel, and system prompt for repeated kinds of questions.”

Click + New mode to open the editor. Name and Description sit side by side at the top; below them the Primary, the Panel table with its per-member Role and Models controls, the Rounds control, and the system-prompt field.

• Name — lowercase ASCII letters, digits, and dashes; no spaces, no leading/trailing dash. (It’s shown with a leading #, e.g. #review. The # is display-only — the stored name has none.)
• Description — a short hint shown in the composer picker.
• Primary — a provider and a model. A mode whose primary resolves no model of its own has to name one; saving without a model is blocked. Provider default is offered only for a custom endpoint that carries a default model.
• Panel — leave Inherit user defaults on to use your global fan-out set, or turn it off to check exactly the providers this mode should fan out to. Either way, each member has its own Role and Models controls.
• System prompt append — optional text added after your project context, “never instead of it.” To replace the system prompt for a specific model, open Manage models on that provider’s Connections row under Settings → Providers and use the system-prompt override in the model’s advanced drawer.

Existing modes have Edit and Delete buttons (the built-in #quick shows a disabled Delete). Polycode keeps a soft cap of ten user modes — saving an eleventh just warns “Lots of modes can get hard to remember; consider consolidating.”; it never blocks you.

The “This mode runs” card

At the bottom of the editor, a This mode runs card names what the mode will actually dispatch: the synthesis model, the peers, and the round setting. It is resolved output rather than a restatement of the rows above it — it accounts for muted providers, models that are no longer available, and the fact that pinning the primary’s own model removes that provider’s other peers rather than adding one. It updates as you edit, and on a debate mode it carries a ~2× a single pass chip.

A mode with no peers at all is a real configuration, and the card says so in words rather than showing an empty list: “None — this mode returns the primary’s answer without synthesis.”

The built-in #quick mode

Polycode ships one built-in mode, #quick — “Cheap consensus across small models — Haiku, Gemini Flash, GPT-5 Nano. Faster and cheaper than full consensus, still synthesized.” It pins the small-model variant of each provider and synthesizes through Haiku, so you get a real multi-model cross-check at a fraction of the cost and latency of your full panel.

Those picks are ordinary mode data now, visible and editable in the editor like any other mode’s. They used to be hardcoded, which meant you could not see what #quick sent or change it; on first launch of a build that has the Models control, #quick’s models are backfilled once so existing users keep the small-model behavior, and clearing them afterwards sticks.

#quick is editable in every other respect too — description, primary, panel, roles, rounds, system-prompt append — but its name is reserved and it can’t be deleted.

Using a mode for a send

Modes are chosen from the mode pill in the composer, the dropdown immediately to the right of the model picker. It defaults to No mode; pick any mode to apply it to your next send. The choice is per-window and survives an app restart for restored windows — a fresh window starts at No mode.

A one-shot !! target still wins. If you type !! to aim a single send at specific participants, those targets override the mode’s models for that send — the explicit thing you just typed beats the saved preset.

The typed #name accelerator isn’t available yet — the composer pill is the way to select a mode today.

The single-model fast path

Set a mode’s explicit panel to just its primary and the run has a single participant, so Polycode skips synthesis entirely and shows you that one model’s raw answer — no consensus framing, no synthesis pass to pay for. It’s the sanctioned way to get a single model’s unmediated reply while keeping your full panel one click away. (For a one-off without a saved mode, type !! in the composer to target a model for a single send — see composing prompts.)

When a mode can’t run

A mode is resolved against your currently configured providers and models each time it’s shown, so it can land in one of three states:

• Valid — applies fully.
• Partial (a yellow chip) — something it names is missing: providers you haven’t configured, models that have left the registry, or both. The mode still fires on what is available, and the chip’s tooltip names what was dropped — Dropped peers: …, Dropped models: …, or both.
• Invalid (a red chip) — its primary provider isn’t configured, its primary model doesn’t resolve, or every panel entry is unconfigured. Selecting an invalid mode and sending posts a warning toast (“Mode ‘#name’ is unavailable.”) and Polycode falls back to all defaults — your normal primary, your normal fan-out set, and no system-prompt append. Nothing from the broken mode leaks into the send.

A stale model pin degrades a mode; it does not invalidate one. A provider whose pinned models have all gone missing is skipped for that turn when it still has other models available, rather than being dispatched with a model the registry no longer carries and waiting for the provider to reject it.

What’s next

• Fan-out and consensus — what the primary, panel, and rounds a mode sets actually do during a run.
• Disagreement and adoption — where a Critic’s dissent and a debate round show up once the answer lands.
• Composing prompts — the !! one-shot model target, the @ file mention, and attachments.
• Setting up providers — configure the providers and per-model overrides a mode draws on.