claude-council: run the same question past several coding agents and read the answers side by side

The problem claude-council solves: one model's bias on a decision you cannot check

A single coding agent answers with confidence whether or not it has grounds. The README frames the plugin around exactly that gap: it is "useful when one model's bias could mislead you and the right call depends on cross-checking", and it names architecture decisions, debugging dead ends, security reviews and framework picks as the cases it targets. The audience is a developer already working inside Claude Code who has to commit to a choice, not someone who wants a leaderboard of models.

The design assumption is that disagreement is the signal. In the README's UUID versus BIGINT example, four providers split two and two, and the synthesis line reads that the choice depends on whether distributed ID generation is needed. That is a different output from a single answer: it hands you the axis of the decision rather than a verdict. The second example is the more interesting one. When all five recommend SQLite, the synthesis does not treat unanimity as confirmation. It states that the agreement is about the reasoning, not verification, and names the premise that would flip the answer (single-node deployment) plus the fact that none of the providers could inspect the system. That is a deliberate refusal to let consensus stand in for evidence, and it is the part of the design worth judging the project on.

How the council is assembled: API keys, subscription CLIs, and a local ollama seat

The plugin treats a provider as a seat you fill in one of three ways. The first is an API key: OPENAI_API_KEY, GEMINI_API_KEY, XAI_API_KEY, PERPLEXITY_API_KEY, KIMI_API_KEY or OPENROUTER_API_KEY. The second is a CLI that authenticates against a subscription you already have: codex, agy (Antigravity), grok and kimi. The README states that when a CLI is installed it is preferred over its API sibling, so a machine with both a key and the CLI will use the CLI. The third is a local ollama model, which the README describes as needing no key, no subscription and no network.

OpenRouter is the escape hatch for coverage. The README says you can "seat any model OpenRouter routes to", and notes that the default there is Anthropic's Claude, so the council hears a vendor it otherwise has no voice for. That is a neat bit of positioning: the plugin runs inside Claude Code, and without OpenRouter the council would never include a Claude answer.

Beyond the roster, there are modifiers: --roles assigns roles such as security or performance, or a preset like balanced, or provider=role pairs; --debate turns on a two-round debate mode; and the README mentions agent-enhanced deep analysis for high-stakes decisions. The repository layout backs this up with top-level agents/, commands/, config/, prompts/, schemas/, skills/ and hooks/ directories, and the README calls the provider system extensible. The exact contract for adding a provider is not spelled out in the README, so anyone planning to write one should read schemas/ and the provider code rather than the front page.

Installing claude-council from the plugin marketplace

The recommended path is the Claude Code plugin marketplace, which the README says persists across sessions. Two slash commands do it:

/plugin marketplace add hex/claude-marketplace
/plugin install claude-council

After that, configure at least one provider. Either export a key, or install one of the subscription CLIs:

export OPENAI_API_KEY="..."

The README notes that GEMINI_API_KEY, XAI_API_KEY, PERPLEXITY_API_KEY, KIMI_API_KEY and OPENROUTER_API_KEY work the same way, and that installing the codex, agy (Antigravity), grok or kimi CLIs uses your existing subscription instead, with no API key needed. Run /claude-council:status to confirm what is configured and connected.

If you would rather run from a local clone, the README gives a different command and warns about two traps. Clone the repository anywhere, then point Claude Code at the repository root for the current session:

git clone https://github.com/hex/claude-council.git
claude --plugin-dir /path/to/claude-council

The README states that this loaded copy lasts for the session only. It also says not to clone into ~/.claude/plugins/ (on Windows, %USERPROFILE%\.claude\plugins\), because that directory is Claude Code's managed install cache and is never scanned for manually added plugins. A second trap: pluginDirectories in settings.json is not a real setting, so it is silently ignored with no error shown.

A first real question, and what the output looks like

With at least one provider configured, the ask command takes a plain question. The README's own first example is a schema decision:

/claude-council:ask "Should I use UUID or BIGINT primary keys for a SaaS users table?"

Each configured provider answers under its own banner, naming the provider, the model that answered and how long it took, followed by a synthesis section. You can narrow the roster or attach context:

/claude-council:ask --providers=gemini,openai "What's the best approach for caching here?"
/claude-council:ask --file=src/auth.ts "What's wrong with this implementation?"
/claude-council:ask --quiet "What's the best caching strategy?"

The README lists --providers, --file, --image, --output and --quiet among the flags; --image attaches one image for vision-capable providers, --output exports the response to a markdown file, and --quiet shows only the synthesis. Inside tmux, results stream into a side pane in real time with vendor-colored banners. For long queries, the README suggests --async and then fetching the job by id:

/claude-council:ask --async "Deep-dive the tradeoffs of event sourcing here"
/claude-council:result <job-id>

One more command is worth knowing before you paste anything sensitive: /claude-council:advise puts the conversation itself to the council, and the README says it shows you what would leave the machine before it goes.

Where claude-council is the wrong tool

The plugin's honest limitation is written into its own synthesis example. Every provider receives the same description of a system, and the README says plainly that none of them can inspect it. So the council cannot verify anything about your codebase beyond what you paste in. It is a reasoning cross-check, not a test suite, and it will not catch a bug that only shows up when the code runs.

Cost and latency scale with the number of seats. Each question is sent to every configured provider, and the README's own answer to long queries is --async with /claude-council:result to fetch, list and cancel jobs. If your question is short and you already trust one model, the council is strictly more expensive and slower than asking it directly.

There is also a privacy question the README addresses only for one path. /claude-council:advise shows what would leave the machine before it goes. For a normal ask, the README does not describe an equivalent pre-flight view, so the practical rule is that whatever you pass via --file or --image goes to every configured provider, including any API provider, unless you have restricted the roster with --providers.

Finally, the README does not document rollback, and provider model names move underneath you. The synthesis example labels one seat "grok-latest" and another "sonar-reasoning-pro", which suggests model identifiers are resolved at query time rather than pinned by the plugin.

How claude-council differs from a router or a single-model workflow

The obvious comparison is a model router such as OpenRouter used on its own, or a multi-model chat client that lets you switch between models manually. Those give you access to many models but leave the comparison to you: you send the prompt, read one answer, switch, send it again, and hold both in your head. claude-council's difference is that the fan-out and the synthesis are one step, and the synthesis is opinionated about disagreement rather than neutral. The README's two examples are the whole argument: it splits agreement from divergence, and when there is no divergence it names the premise the agreement rests on.

The second comparison is a single Claude Code session with no plugin. That is cheaper, faster and needs no keys. What it cannot do is tell you that four other models read your question differently, which is the only thing this plugin sells.

A third comparison is running the CLIs yourself in four terminals. You can do that, and the plugin's CLI support means it is partly automating something you could script. The parts you would not get for free are the streaming tmux pane with vendor-colored banners, the background job commands, the stop-gate hook that reviews your uncommitted diff before Claude ends its turn, and the proactive agent that suggests consulting the council on architecture or debugging dead ends. Those are the pieces that make it a plugin rather than a shell script.

Maintenance, upgrades and the MIT licence

The last push to the default branch was on 2026-09-07, and the three most recent releases listed are v2026.9.7 on 2026-09-04, v2026.9.8 on 2026-09-05 and v2026.9.9 on 2026-09-06. The version scheme is calendar-based, so a release identifier tells you the month and day it was cut. The repository is not archived. The README does not document an upgrade procedure or a rollback path, and it does not say how a marketplace-installed plugin is updated, so the upgrade cost is genuinely unknown from the front page. The CHANGELOG.md at the repository root is the place a reader would look for what changed between those releases.

The licence is MIT. That is permissive, and it means you can read, modify and redistribute the plugin, including the provider system the README calls extensible. The licence says nothing about the providers themselves: your OpenAI, Gemini, xAI, Perplexity, Kimi or OpenRouter usage is governed by those vendors' terms and billed by them, and the subscription CLIs are governed by whatever plan you are on. MIT also carries no warranty, which matters here because the output is model-generated advice about your code. None of this is legal advice; the LICENSE file is the authority.

Editorial conclusion

Adopt claude-council if you already pay for two or more of these providers, or if you want a local ollama model in the mix without any key at all; the plugin is only as useful as the number of voices you can configure, and a single-provider setup is just a slower way to ask one model. Skip it if you need reproducible, auditable answers: the README describes a synthesis that names the assumption behind agreement, not a scoring or verification step, and it does not document rollback or pinning for provider model changes. Before relying on it, run /claude-council:status and confirm each provider you expect shows as connected with the model you expect, because a silently missing provider shrinks the council without telling you.

Frequently asked questions

Official sources

1. hex/claude-council on GitHub
2. Issues
3. License: MIT
4. README
5. Releases