Claude Octopus: multi-model consensus gates for Claude Code tasks

The blind spot problem Claude Octopus is aimed at

A single model reviewing its own plan tends to agree with itself. Claude Octopus is built on the premise that this is the failure mode worth engineering around: the README opens with the line that every AI model has blind spots, and the project's answer is to route a task to several models and compare their answers rather than trusting one. The audience is narrow and specific. You need to be working inside Claude Code, because the plugin activates through slash commands in that host. You need tasks where a wrong call is expensive, such as security review, an architecture decision, or a refactor plan that other people will implement. And you need to be willing to pay for more than one model on the same task, either in subscription quota or in API spend. The README is explicit that this is not the default path: Claude-native /init, /review and /security-review are described as the tools to use when Claude alone is enough, and Octopus is positioned as the escalation. That framing is honest, and it also tells you who should not bother.

How the council, personas and consensus gate fit together

The mechanism has three layers. The first is a roster of providers: the README lists ten external integrations (Codex, Antigravity CLI, Copilot, Qwen, Ollama, Perplexity, OpenRouter, OrcaRouter, OpenCode and Grok) alongside the built-in Claude Code host. The second is a library of 32 specialized personas, described as role-specific agents such as security-auditor and backend-architect, plus 54 commands and 63 skills. The third is the gate. The README states that a 75% consensus gate catches disagreements before they reach production, and that the council workflow runs a structured 3, 5 or 7 persona deliberation with quorum and critical-veto gates. So the data flow is: an explicit /octo command selects a workflow, the workflow selects personas, personas are dispatched to the providers that are available, and the returned answers are scored against a consensus threshold. Disagreement is the product, not a bug. Two design choices are worth noting. Activation is explicit-only by default, with an optional smart router, so ordinary Claude requests do not trigger Octopus. And providers are detected rather than configured up front: the README says each becomes available when detected and runs only inside an explicit workflow. That keeps the plugin dormant, but it also means the set of models in any given council depends on what is installed on the machine, which is a reproducibility cost.

Installing the plugin and running a first council

The repository is distributed as a Claude Code plugin, and the package.json name is @anthropic-plugins/claude-octopus. The README does not spell out a single install command, so the entry point to check first is the plugin manifest directory, .claude-plugin/, in the repository root. The README's own examples all assume the plugin is already loaded and you are typing slash commands inside Claude Code. The first thing worth running is the model configuration inspector, which the v10.0.0 release notes show as a way to inspect or override the frontier roster.

/octo:model-config                         # inspect or override the frontier roster

You should see the current roster, with Claude Opus 5 leading architecture, planning, security reasoning and final judgment, GPT-5.6 Sol as the independent implementation and review peer, and Claude Sonnet 5 as the standard Claude seat. The README notes that existing model pins and provider configuration still win over the defaults. If you want Fable 5 as a judgment escalation, the release notes give an explicit opt-in variable rather than making it the default.

OCTOPUS_OPUS_MODEL=claude-fable-5          # explicitly opt in to Fable 5

The first real use is a council on a decision you are actually stuck on. The README gives these two examples, with a goal mode and a style:

/octo:council --goal decision --style adversarial "Should this service stay monolithic?"
/octo:council --goal implement --implement plan-only "Refactor the auth flow"

The goal modes listed are advice, decision, plan, implement and review; the styles are balanced, adversarial, red-team, executive and implementation. The second example is the safer starting point, because plan-only stops at a plan rather than touching the working tree. The README also mentions a bin/octopus CLI and a Makefile at the repository root, where make test runs smoke plus unit tests and make ci-local runs the fuller local matrix. Those are for people working on the plugin, not for users.

Where the design costs you: detection, cost and v10 exit codes

Three limitations are visible in the README and release notes. First, provider detection is a dependency you do not fully control. The README says zero external providers are needed to start and each is added one at a time, which is good for adoption but means a council's composition varies by machine. If you expect four models and only two are detected, the consensus gate is being computed over a smaller sample and nothing in the README suggests the plugin will refuse to run. Second, cost. The README points out that four providers cost nothing extra when you already have access: Codex, Antigravity CLI and Copilot use existing subscriptions or local auth, and Ollama runs locally. That leaves the rest, including Perplexity, OpenRouter, OrcaRouter and Grok, as paid paths. The README also notes that Qwen now requires API-key or Coding-Plan auth because its free OAuth tier ended on 2026-04-15, which is the clearest example of a provider whose cost profile changed under users. Third, the v10 upgrade is not free of behavioural change. The upgrade notes state that automation using doctor --json must handle exit 1 while retaining its valid JSON body, and that invalid arguments return 2. Any script you have that treats a non-zero exit as a flat failure will need adjusting. The README does not document rollback in the section I can see; it points to docs/V10-MIGRATION.md for compatibility and rollback details, so that file is where to look rather than the README.

Claude Octopus versus Superpowers and plain Claude Code

The related searches include people comparing Claude Octopus with Superpowers, and the difference in approach is worth stating plainly. Superpowers-style skill packs extend what one Claude Code session can do by giving it more structured workflows and reusable modules. Claude Octopus does that too, through its 63 skills and 54 commands, but its distinguishing move is putting other vendors' models in the loop and scoring their agreement. The README makes the contrast itself: other orchestrators give you infrastructure, Octopus gives you the workflows, and the four-phase Discover, Define, Develop, Deliver methodology with quality gates between phases is presented as the differentiator. There is also a middle option worth naming, which is Claude Code on its own. The README recommends exactly that for ordinary work, calling /review and /security-review the right tools when Claude is enough. If your tasks are small, or your reviewers are humans rather than models, the extra dispatch and gate logic adds latency and spend without changing the outcome. The honest comparison is not Octopus versus another orchestrator; it is Octopus versus the single-model path you already have.

Licence, maintenance and the upgrade treadmill

The repository is MIT licensed, and the package.json confirms the same licence for the npm package. MIT is permissive, so the practical implication is that you can use, modify and redistribute the plugin, including inside commercial work, provided you keep the copyright and licence notice. The repository also carries a THIRD_PARTY_NOTICES.md and a licenses/ directory, which suggests bundled third-party components with their own terms; those are worth reading before redistribution, and this is not legal advice. On maintenance, the last push was on 2026-08-26 and the most recent release is v10.0.0 on the same date. The release history shown is dense: v9.66.0 and v9.66.1 landed on 2026-08-21 and 2026-08-22, with v10.0.0 four days later. That is a fast-moving project, and it is the main upgrade cost. The v10 notes describe a durable execution contract, fail-closed contribution validation, Doctor 2.0, Provider Registry 2.0 and opt-in eval routing, which is a substantial internal rework rather than a feature addition. The README tells you to see the migration guide for compatibility and rollback details. The package.json version is 11.5.0 while the newest release listed is v10.0.0, so the version numbering across the package and the release notes is not something to rely on when deciding what you are running.

Editorial conclusion

Adopt Claude Octopus if you already work inside Claude Code and want a second or third model opinion on reviews, architecture calls or specs, and you accept that every escalated run is an explicit /octo command with its own cost. Skip it if a single model is enough for your work, or if you cannot add a plugin to your Claude Code environment. Before committing, run /octo:model-config and read docs/MODEL-ROUTING-STRATEGY.md and docs/V10-MIGRATION.md, then confirm in your own environment that the providers you expect are detected, because the README states each provider becomes available only when detected.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes