---
title: Multi-Model Council (ask several models at once and get one answer)
---

# Multi-Model Council (parallel panel + judge synthesis)

## What it is

### What it is

The Multi-Model Council lets you pose a single question to a panel of AI models simultaneously, then synthesizes their answers into one authoritative response. You pick which models sit on the council and which acts as judge. Ask a question, watch the member answers arrive in parallel, then read the judge's synthesized verdict.

There are two places to run a council, and they behave differently on purpose:

- **The standalone AI Council** — a project-less, always-available surface (its own entry in the sidebar, not nested under any project) for asking questions and having a conversation. You can keep several separate council chats here. It never works as an agent — it only reads and answers, never touches files — and the judge can be any model you like.
- **A council inside a project** — created from a project's Councils section. This kind is **always an agent**: the judge doesn't just merge the panel's answers, it actively reads and changes files in that project to carry out what you asked, with full tool access. Because agent sessions are Claude-only, the judge for an in-project council is always a Claude model — if you pick a different model as judge, Omniscio swaps it for a Claude model automatically so the council stays capable of running as an agent. There's no on/off switch for this — it's simply how councils behave inside a project. See [Orchestrator agent mode](#orchestrator-agent-mode) below for how that agent turn works, and the welcome screen's "In your project, the council works as an agent" callout (with its own **Learn more** link) for the in-app explanation.

Ordinary ("knowledge") panelists are plain API calls and spawn nothing regardless of which surface you're on — only the judge in an in-project council spawns a real background Claude Code session (see [Agent panelists](#agent-panelists) below for the retired per-panelist version of this idea).

> **Note:** This is an in-development feature, hidden by default. Reveal it by launching Omniscio with `AMC_SHOW_MULTI_MODEL_COUNCIL=1`, or by flipping the Labs toggle in Settings once it appears there.

## Where to find it

The **Multi-Model Council** surface in the app, where a council is created and its runs live. Once one exists it can also be asked from inside a session's own question.

## How it behaves

### Creating a council

For an in-project (always-agentic) council, click **"+"** next to **Councils** inside that project's sidebar section. For the standalone AI Council (never an agent, project-less), open its own sidebar entry — a project selection isn't needed there at all.

- **Very first council:** before you've ever finished setting one up, the "+" opens the **guided setup wizard** (see [Guided setup wizard](#guided-setup-wizard) below) instead of the raw template flow.
- **After that:** if there's exactly **one** template, the session is created from it immediately; with **several** templates a small picker menu opens so you choose which council setup to start; with **no usable provider** a toast explains that a council needs at least one AI model with an API key, then Settings → Council Templates opens.
- Behind the scenes, that first-run experience is still backed by an auto-seeded **"Default Council"** template — one recommended model per provider you already have a key for (capped at three; a single-provider setup gets two models from that provider), judge defaulting to your global judge model or the first panelist if its provider has no key — so even a skipped wizard leaves you with a working setup.

A brand-new council shows an explanatory empty state: who is on the panel, what will happen when you ask, and three clickable example questions that fill the composer.

### Guided setup wizard

The first time you create a council, the **"+"** button opens a short guided wizard (`CouncilSetupWizard`) instead of dropping you straight into a template. The welcome screen explains what a council is; if you're setting one up inside a project, it also shows a callout — "In your project, the council works as an agent" — with its own **Learn more** link, since that's the one behavior difference from the standalone AI Council. The wizard then walks through five steps:

1. **Pick your panel** — choose the models that sit on the council, with recommended picks highlighted for the providers you already have a key for.
2. **Pick the judge** — choose the model that synthesizes the panel's answers into one verdict. Inside a project, the judge always ends up a Claude model (see [above](#what-it-is)) because it's the one doing the agent work.
3. **How they work together** — choose the interaction depth (how much the panelists debate/see each other vs. answer independently).
4. **Advanced (optional, skippable)** — turn on an optional **Evaluator** (a critic that reviews the answers before the judge decides); skip this step entirely if you don't need it. There is no agent on/off choice here anymore — an in-project council is simply always an agent, and the standalone AI Council is simply never one.
5. **Save your council** — choose what this setup applies to, then click **Create my council**:
   - **Just this council** — use this setup once, for this council only (nothing is saved as a reusable default).
   - **This project's default** — reuse this setup for every new council you start in this project.
   - **My default everywhere** — reuse this setup for every new council, in every project.

Every configuration step carries a small **"Learn more"** link (next to the panel, judge, "How they work together", and evaluator — plus the welcome screen's agent-mode callout when you're in a project). Clicking it opens an illustrated explainer in its own pop-up — a plain-language description of that concept plus a simple diagram of how it fits together — with a **Got it** button (or the usual ✕ / Escape) to close it and return to the wizard exactly where you left off. It is the same explainer whether you opened the wizard to create a council or to Configure an existing one, and the explainer is a standalone pop-up that can be reused elsewhere in the Council UI, not just in the wizard.

The wizard only auto-opens once. After you finish it (or once a project already has a council session), the "+" goes back to the normal template flow above — but you can always come back to the wizard through the **"✨ Guided setup…"** entry at the top of the template picker menu.

The **config bar** at the top stays a one-line summary (panelists · Judge · mode). Click **Configure** to reopen the same guided wizard in edit mode, prefilled from the council's current setup — its final step becomes a review screen instead of the save-scope picker, and "Save changes" applies only what you changed. All edits are staged — nothing changes until you save; Cancel or Esc discards them. Configure is locked while a turn is running. ("Judge" is the UI name for the synthesizer role; internal identifiers remain `synthesizer*`.)

### How it works

When you submit a question:

1. **Members answer in parallel.** Every configured council member model receives the question simultaneously via `llmProviderService.chat()`. Omniscio uses `Promise.allSettled` so a failing member can never block the others. If a member fails, the judge is told who did not reply; the turn only aborts entirely when zero members answer.

2. **The judge synthesizes.** Once all member answers (and any failure notes) are collected, the judge model receives a prompt containing all member responses and produces a single final answer. The judge's reply is structured with `===FINAL ANSWER===` and `===REASONING===` delimiters, parsed by `parseJudgeReply` with a whole-text fallback — deliberate plain-text sections rather than JSON mode (the same avoidance pattern used in the inbox pilot evaluator; see `inbox-pilot-evaluator-contract.md` for why JSON mode is unreliable on the Anthropic direct path).

3. **The conversation plays out as a group chat.** Your question appears first, then each panelist model posts its own answer as its own chat message (labeled with that model's name and avatar), and finally the judge posts its synthesized verdict as a highlighted message at the end of the round. **Answers stream in live**, just like a normal Claude Code session — a panelist (and the judge) shows a brief typing/skeleton state only until its first words arrive, then its answer grows on screen token-by-token as the model generates it, rather than popping in all at once when the model finishes. A long panelist answer is collapsed to a preview with a **Show more** toggle (`data-ui-anchor="council-answer-expand"`) so the chat stays scannable — click it to expand or collapse that model's full answer. All messages (verdict, reasoning, and each panelist answer) are rendered as **markdown** via `react-markdown` + the `rehypeHighlightSubset` shim, updated live as the streamed text grows.

4. **Stop mid-flight.** While a turn is in progress a **Stop** button (`data-ui-anchor="council-cancel"`) appears in place of Ask. Clicking it sends `COUNCIL_CANCEL`; the orchestrator finalizes the turn as `cancelled` (partial member answers kept, judge skipped). The cancelled state is shown in the verdict area.

5. **You're notified when it finishes.** A council surfaces its result like any other session: when the verdict is ready the council's session turns to **Needs You** (amber) — it appears in your inbox, plays the needs-you chime, shows the OS notification, and bumps the badge — so you don't have to watch the panel. A council that **fails** (no panelist could answer, the judge couldn't produce a verdict, or the run crashed) turns to **Error** (red) with its own notification. Only a turn **you** cancelled stays quiet. (A finished council used to silently go back to "ready" with no signal — that was the notification bug fixed by routing council completion through the shared turn-conclusion authority every engine uses.)

6. **Failed turns offer Retry.** When a turn fails outright, a **Try again** button (`data-ui-anchor="council-retry"`) re-asks the same question — no retyping. (File attachments are not re-sent on retry.)

### When a provider needs re-authentication

If any provider used by the council (a panelist, the judge, or the evaluator) lacks usable auth at the moment you click Ask — for example, an expired Claude subscription with no API key fallback, or a missing OpenAI key — the council does NOT run. A single slim notice row appears in the answer slot — the same compact divider-line treatment regular chat shows when a login expires — naming the provider that needs attention, with either a **Re-authenticate** link (Anthropic OAuth) or an **Open Settings** link (API-key providers). Once you resolve it the council automatically retries the turn; if another provider still needs auth, the row updates in place with the next offender. This replaces the previous stack of per-panelist "No API key available for fallback" errors.

### Agent panelists (legacy — superseded by Orchestrator agent mode)

> **Superseded.** The per-panelist "Run as agent" path described below has been **removed** from the UI in favor of council-level [Orchestrator agent mode](#orchestrator-agent-mode), where the judge (not each panelist) holds the tools. Existing councils that used agent panelists are migrated automatically to agent mode (judge tier = `full` if any agent panelist had full access, else read-only). The section below documents the old behavior for historical context; the spawn machinery it describes is what agent mode now repoints at the judge.

A Claude panelist can be flipped to **"Run as agent"** in the Council setup dialog (member `type: 'agent'`). Instead of a plain API call, an agent panelist spawns a **real silent background Claude Code session** via `createSessionWithPrompt()` (`source: 'council-agent'`, `background: true`, `silent: true`) — so it can read files, search code, and run tools in your project before answering. Knowledge panelists and agent panelists mix freely on the same panel.

How an agent panelist runs:

- **Project resolution** (`council-project-resolve.ts`): the agent runs in the council's configured agent project — the `council.agentProjectPath` override if set, otherwise the project of the council's linked session. If neither resolves, the member is **skipped with a notice** in its answer slot ("Agent panelist skipped: no project directory configured.") rather than failing the turn.
- **Project docs injected.** Because it goes through the standard `createSessionWithPrompt()` spawn path, the session gets the project's `.claude/docs/` context prepended to its first turn like any other Omniscio session.
- **Tool access.** It is a full Claude Code session — file reads, searches, and tool use all work, and its activity streams live into the council UI (`COUNCIL_AGENT_ACTIVITY` push events bridged from `SESSION_OUTPUT`).
- **No timeout.** An agent panelist is never cut off for taking too long — it runs until it finishes on its own or you press Cancel. (Total council spend is still bounded by the daily cost cap, and Cancel cleanly stops any still-running agent session.)
- **Silent session.** The spawned session is hidden from the sidebar/inbox (the standard `isSilentlyHidden` gating) — it exists to answer the council question, not to be interacted with.

Agent panelists cost more per question than knowledge panelists because they run full Claude Code sessions. The spawn logic lives in `src/main/services/council/council-agent-spawn.ts` (`runAgentPanelist`), with structured-answer parsing in `council-agent-answer.ts`. An agent panelist's real cost is captured and counted toward both the turn total and the daily cap — see [Cost model](#cost-model).

### Orchestrator agent mode

A council created **inside a project** always runs as an **orchestrator**: instead of every panelist answering in parallel and the judge merely merging their text, the **judge becomes an active agent** that plans the task with the panel and then carries it out itself using tools (reading and writing files, running commands), while the panelists act as plain advisors. This is the council's single agentic path — it replaces the old per-panelist "Run as agent" checkbox, which has been removed. The **standalone AI Council** never runs this way — it stays a plain ask-and-answer panel with no tool access, whatever model you pick as judge.

There is no on/off switch for this anymore — it is simply how an in-project council behaves, always at **full access**:

- **The judge is always the orchestrator** for an in-project council — there's no separate "enable agent mode" step, and the judge can't be turned off (it's the one doing the work).
- **The judge is always a Claude (Anthropic) model.** Agent sessions are Claude-only, so creating (or editing) an in-project council with a non-Claude judge automatically swaps it for the recommended Claude model — you never hit an error for this, it's handled for you. (Standalone councils are unaffected — any judge model is fine there, since they never act as agents.)
- **Full tool access**, work-in-place and fully autonomous — the same posture the old full-access agent panelist had (no worktree isolation, no per-action confirmation prompts). There is no read-only tier to choose anymore; an in-project council is always full access.
- **No timeout.** The judge's agent session runs until it finishes on its own or you press Cancel — it is never cut off mid-task. (Spend stays bounded by the daily cost cap.)

Want the plain-language explanation in-app? The wizard's welcome screen shows an "In your project, the council works as an agent" callout (with its own **Learn more** link) whenever you're setting up a council inside a project — see [Guided setup wizard](#guided-setup-wizard) above.

How a turn runs in agent mode:

1. **Plan (panel).** Each panelist is asked, as an advisor, to propose the best approach for the lead agent to take — concrete steps, what to investigate first, and what "done" looks like (`===APPROACH===` / `===RISKS===`). These stream in as the panelist responses.
2. **Execute (judge).** The judge spawns as a real Claude Code session in your project at the chosen tier, seeded with the task and the panel's approaches — which it reconciles into its own plan as it works, keeping the strongest ideas and dropping weak or contradictory ones — plus a shared **project-context block** (project name/path, a `CLAUDE.md`/README excerpt, and a shallow directory listing — the same picture the advisors saw). Its live tool activity is shown as a single calm status line — the judge's current action plus a running step count (e.g. "Reading your code… · 14 steps") — with a **details** toggle that expands the full tool-by-tool list on demand. **Agent-mode panelists show their streamed answer text live alongside this tool-activity feed** — you see the growing answer and what the agent is currently doing at the same time, not just one or the other. When the turn finishes, that line collapses to a quiet one-line record above the verdict ("Investigated your code · 14 steps · 38s", still expandable; an errored or cancelled turn says so honestly rather than showing a success tick). The full durable transcript remains available via **Open Full Session**.
3. **Ask the panel (only if stuck).** If the judge hits a real blocker it can't resolve alone, it emits `===NEEDS PANEL===` with the specific blocker and ends its turn. The council runs a brief advice round (each panelist answers the blocker, `===ADVICE===`), merges the advice, and resumes the judge session to continue. This is **bounded to 2 re-consults per turn** — on a persistent blocker the judge is told to make its best judgment and finish, so a turn always terminates.
4. **Verdict.** The judge ends with `===EVIDENCE===` (what it did) + `===FINAL ANSWER===` (the outcome), which becomes the verdict in the usual verdict view.

If no project directory can be resolved for the council, an agent-mode turn fails with a friendly message rather than spawning a judge with nowhere to work. The judge's real wall-clock cost is metered into the same `multi-model-council` daily-cap ledger as everything else, captured exactly once (it is never double-billed on a re-delivered completion or a retry). With Agent mode **off**, the regular parallel-panel-then-judge flow above is unchanged.

## Related

- [Multi-Model Council part 2](multi-model-council-part-2.md) — asking a council a question, what a verdict shows, the per-turn actions, debate mode, attachments, memory and cost.
- [ai-council-launch.md](ai-council-launch.md) — the lightweight one-shot version of asking several models at once.
- [overseers.md](overseers.md) — the always-on coordinator a council's Orchestrator mode borrows from.

### Related

- [ai-providers.md](ai-providers.md) — the `llmProviderService` the council uses to call each model
- Omniscio’s unreleased-feature (“Lab”) gate — how the Labs gate works