claude-council: side-by-side answers from six model vendors inside Claude Code

The problem is model bias, not model access

You can already open six browser tabs and paste the same question into six chat windows. The README frames the actual problem differently: one model's bias can mislead you, and the right call depends on cross-checking. That is a claim about correlated failure, not about capability. If you ask a single agent whether to use UUID or BIGINT primary keys, you get one confident answer and no signal about whether that answer is a house style, a training-data artifact, or a real engineering trade-off. claude-council's answer is to put the answers next to each other, in one pane, with the provider and model named above each response and the elapsed time recorded. The audience is narrow and specific: engineers already running Claude Code who are making decisions expensive enough to justify a second opinion. Architecture choices, security reviews, framework picks, and the debugging dead end where you have been staring at the same stack trace for an hour. It is not a general chat wrapper, and it is not aimed at people who want one authoritative answer.

Fan-out, streaming pane, and a synthesis you have to read critically

The mechanism described in the README is a fan-out. One question goes to every configured provider in parallel. Each provider returns a response tagged with a banner naming the provider, the model that answered, and how long it took. Inside tmux, those responses stream into a side pane as they land, with vendor-colored headers, so you are not waiting for the slowest model before seeing anything. When the responses are in, the plugin writes a synthesis section. The README's own example is instructive: two providers preferred UUID or UUIDv7, two preferred BIGINT, and the synthesis reduces that to a single line about distributed ID generation. In the second example, where all five providers recommended SQLite, the synthesis does something more interesting. It states that the agreement is about reasoning rather than verification, notes that every provider received the same description of a system none of them can inspect, and names the premise (single-node deployment) that would flip the answer. That second behavior is the design's strongest idea. Consensus among models that were handed identical context is weak evidence, and the plugin says so in its own example output. What the README does not describe is how the synthesis is produced: which model writes it, whether it sees all responses, or whether it is deterministic. Treat the synthesis as a reading aid, not as a computed result.

Providers: API keys, subscription CLIs, OpenRouter, and a local model

The provider list splits into four groups, and the split matters for cost and for what leaves your machine. First, direct APIs: Gemini, OpenAI, Grok, Perplexity and Kimi, each enabled by exporting the matching key (GEMINI_API_KEY, OPENAI_API_KEY, XAI_API_KEY, PERPLEXITY_API_KEY, KIMI_API_KEY). Second, subscription CLIs: codex, agy (Antigravity), grok, and kimi. The README says these use your existing subscription and need no API key, and that they are preferred over their API siblings when installed. If you have the codex CLI on your PATH and an OPENAI_API_KEY in your environment, the README's stated behavior is that the CLI wins. Third, OpenRouter, which lets you seat any model OpenRouter routes to. The README calls out that Anthropic's Claude is the default seat there, so the council hears the one vendor it otherwise has no voice for, since the plugin itself runs inside Claude Code. Fourth, ollama, which the README describes as no key, no subscription, no network. That last one is the only configuration where the question and the code you attach never leave the host, which is the relevant fact if you are reviewing something you cannot send to a vendor.

Getting it running, and the two installation traps the README calls out

The documented install path is the Claude Code plugin marketplace: /plugin marketplace add hex/claude-marketplace, then /plugin install claude-council. You then export at least one provider key, or install one of the subscription CLIs, and ask a question with /claude-council:ask followed by the prompt in quotes. The README is unusually direct about two failure modes for people who clone instead. Cloning into ~/.claude/plugins/ (or %USERPROFILE%\.claude\plugins\ on Windows) does not work, because that directory is Claude Code's managed install cache and is never scanned for manually added plugins, so the plugin will not appear in the Installed tab and its slash commands will not respond. The second trap is pluginDirectories in settings.json, which the README states is not a real setting, is silently ignored, and produces no error. For a local clone the documented approach is claude --plugin-dir /path/to/claude-council pointed at the repo root, which loads the plugin for that session only. That is a development or offline workflow, not a persistent install. The flag surface is where the tool earns its place: --providers=gemini,openai to narrow the council, --file=src/auth.ts to put a specific file in front of every model, --image=shot.png for vision-capable providers, --roles to assign roles such as security or performance or a preset like balanced, --debate for a two-round exchange, --quiet to see only the synthesis, and --output=docs/auth-decision.md to write the result to a markdown file. Long queries can be pushed to the background with --async and retrieved with /claude-council:result plus a job id, which the README says also supports listing and cancelling.

Where the design costs you: latency, spend, and an unverifiable synthesis

The obvious cost is that every question is now N questions. You pay for each provider you enable, either per token through an API key or against a subscription quota through a CLI, and you wait for the slowest respondent before the picture is complete. The streaming pane mitigates the waiting but not the spend. The subtler cost is epistemic. The README's own SQLite example concedes that every provider was given the same description of a system none of them can inspect. That is true of every query you run through this plugin. If you paste the same wrong assumption into six models, you get six answers built on the same wrong assumption, and a synthesis that reports agreement. The plugin is designed to surface divergence, and divergence is exactly what you will not get when your framing is the problem. There is also a practical gap: the README documents what the synthesis says but not how it is generated, so there is no way to audit the step that most shapes your reading of the results. If you need a decision record that a reviewer can reproduce, the side-by-side output is evidence and the synthesis is commentary, and you should treat them differently.

Compared with asking one strong model, or with a routing layer

The nearest alternative is not another multi-model tool. It is asking one strong model, reading its answer carefully, and pushing back when something looks off. That approach is cheaper, faster, and has a single output you can reason about. It fails in a specific way: you cannot see the shape of the disagreement, because there is no disagreement to see. A second comparison is a routing layer or gateway that sends a request to whichever model is cheapest or fastest for the task. That optimizes a different objective. A router picks one model per request and hides the choice; claude-council deliberately refuses to pick, showing you every response with the vendor and model named so you can weigh them yourself. The cost is that you do the weighing. The plugin's --roles and --debate flags push partway toward orchestration, assigning different models different jobs or forcing a second round, but the README presents these as modes rather than as a pipeline with defined handoffs. If your goal is a single best answer, a router or one strong model is the better fit. If your goal is to find out where a question is genuinely contested, the side-by-side view is the point.

Maintenance, licence, and what to check before you commit

The project is Shell, MIT licensed, not archived, with a release cadence visible in the repository metadata: three tagged releases in the first week of September 2026, the most recent on 2026-09-06, and a last push on 2026-09-07. That is a fast-moving plugin, which cuts both ways. Provider APIs change, CLI flags change, and a plugin that wraps six vendors plus a local runtime has six plus one integration surfaces to keep current. Expect to update it, and expect occasional breakage when a vendor moves an endpoint. MIT is permissive: you can use, modify and redistribute it, including commercially, provided the copyright notice and permission notice are preserved. That is the plain reading of the licence text, not legal advice, and it says nothing about the terms you have already accepted with each model vendor, which govern what you may send them. Before adopting, run /claude-council:status to confirm which providers are configured and connected, because the README describes it as the connectivity check and the plugin's behavior depends entirely on what it finds. Then decide deliberately between API keys and subscription CLIs, since the README states the CLI is preferred when both are present, and that choice determines both your cost model and which vendor sees your code.

Editorial conclusion

Adopt claude-council if you already work inside Claude Code and you want a second and third opinion on architecture, security review or a debugging dead end, without leaving the terminal or opening six browser tabs. Skip it if you need reproducible, auditable answers: the synthesis is generated prose, not a scored comparison, and nothing in the README describes how it is produced or how you would verify it. Before installing, run /claude-council:status to see which providers are actually reachable, and decide up front whether you want subscription CLIs (codex, agy, grok, kimi) or API keys, because the plugin prefers the CLI when both exist and that changes what leaves your machine.

Official sources

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