Fusion-Fable: a Claude Code skill that runs a panel of frontier models and lets Opus 4.8 judge them
Fuse two frontier models into one Fable-tier answer: Opus 4.8 drafts, a second model (Opus 4.8 or GPT-5.5 via codex) checks, Opus fuses. A Claude Code skill.
At a glance
- What is it?
- Fusion-Fable is a Claude Code skill that dispatches one prompt to two or three models in parallel, then has Opus 4.8 analyse the disagreement and write the final answer. It solves answer variance, not model capability, and it only works as advertised when your session is already running Opus 4.8.
- Who is it for?
- Adopt Fusion-Fable if your Claude Code session already runs Opus 4.8 and you regularly face questions where a single pass is not trustworthy: schema migrations, auth designs, protocol edge cases. Skip it if you are on another model, because the README states the slug becomes nominal rather than literal, or if you want a hosted API, since this is a local skill with no server component.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 60 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Fusion-Fable targets is run-to-run variance, not weak models
Most people reach for a second model because they think the first one is not smart enough. The README makes a narrower claim: run the same prompt twice against the same model and you get different reasoning paths, different tool calls and different sources. That divergence is the raw material. Fusion-Fable harvests it instead of manufacturing it, and the README is explicit that there are no contrived lenses or personas. Every panelist receives the task verbatim and answers it straight.
The audience follows from that. This is for someone already inside Claude Code, working on a question where a plausible-but-wrong answer is expensive: whether an ALTER TABLE is safe on a large production table, whether a JWT refresh-rotation design has a replay hole, whether a force-push is safe on a shared branch. Those are the README's own examples, and they share a property. You cannot tell a good answer from a bad one by reading it once. A panel plus a written audit trail gives you something to check against.
It is not a general assistant upgrade. If your question has one right answer that you can verify cheaply, the pipeline adds latency and token cost for nothing.
Fan-out, blind answers, then a judge that cannot be replaced
The architecture is a fan-out followed by a single judge. The prompt is dispatched to several panelists in parallel. Each answers independently with web search and bash, and none of them sees the others' work. That blindness is the whole mechanism. If panelist two could read panelist one, you would get anchoring, not diversity.
Opus 4.8 then judges every answer into a structured analysis with five named buckets: consensus, contradictions, partial coverage, unique insights and blind spots. The final answer is written grounded in that analysis rather than in the raw panelist outputs. Each point in the audit trail is attributed to the panelist that raised it, so you can see how the answer was assembled.
The judge position is fixed. The README states that Opus 4.8 always judges and writes the final answer, and that the pipeline cannot be reversed because the panelist models cannot call back out to spawn Opus. That is an honest architectural constraint rather than a preference, and it has a practical consequence: there is no configuration in which GPT-5.5 or Gemini writes the final synthesis.
Three panels ship. The opus4.8-4.8 panel runs the same prompt twice as two independent Opus 4.8 panelists and needs nothing installed. The opus4.8-gpt5.5 panel adds GPT-5.5 through the codex CLI. The opus4.8-gpt5.5-gemini3.1pro panel adds Gemini 3.1 Pro through the agy CLI. The skill auto-detects which panelist CLIs are present and uses the richest panel available, falling back when one is missing. Every run is written to a timestamped provenance file under ~/.claude/fusion-runs/ containing the raw panelist answers, the analysis and the final answer.
Installing Fusion-Fable and running your first fusion
Installation is a clone plus a shell script. The README gives exactly three commands, and the script copies the skill to ~/.claude/skills/fusion and the slash commands to ~/.claude/commands, then prints which panels your machine can actually run.
git clone https://github.com/duolahypercho/fusion-fable.git
cd fusion-fable
./install.shAfter the script finishes you need to restart Claude Code or run /reload-skills, or the new commands will not be registered. If your Claude configuration lives somewhere other than the default location, the README documents an override rather than requiring you to move files by hand.
CLAUDE_CONFIG_DIR=/path/to/.claude ./install.shThere are three ways to invoke a run, all equivalent under the hood. Natural language works because the skill auto-triggers and picks the richest panel available. Pinned slash commands let you choose the panel explicitly. And you can force a panel in prose by naming its slug.
/fusion-opus4.8 does my JWT refresh-rotation design have a replay hole?
/fusion-gpt5.5 is git push --force-with-lease actually safe on a shared branch?
/fusion-3 full 3-family panel (Opus 4.8 + GPT-5.5 + Gemini 3.1 Pro)What you should see back is a Final answer at the top, followed by the audit trail split into Consensus, Contradictions, Partial coverage, Unique insights and Blind spots, with attribution on each point. What you should see on disk is a new timestamped file under ~/.claude/fusion-runs/. If either is missing, the run did not complete the way the README describes.
There is a second command for planning rather than answering. /fusion-plan runs the panel as an iterative loop, with three seeded rounds in which an Opus 4.8 panelist and a GPT-5.5 panelist critique the current plan in parallel and blind, then Opus judges and synthesizes one tighter plan that seeds the next round. It stops early on NO_MATERIAL_CHANGE and writes the converged plan back to .omc/plans/<slug>.md.
/fusion-plan design the schema + flow for <feature>The README is upfront that this one is expensive: an interview plus roughly six panelist runs plus three judge passes. It is meant for high-stakes planning, not routine work.
The Opus 4.8 session requirement is the sharpest limitation
The requirements section contains the constraint that decides whether this tool is for you. Panelist subagents and the judge inherit the session model. If your Claude Code session is not running Opus 4.8, the README states plainly that the slug is nominal, not literal. The command still runs. It just does not do what its name says.
That is a quiet failure mode. Nothing errors, nothing warns you in the command output, and the provenance file will still be written. A team that installs this on a Sonnet session and reads the panel names will believe they are fusing Opus 4.8 answers when they are not. If you cannot guarantee the session model, the tool is the wrong choice.
The codex dependency is a second boundary. Without the codex CLI installed and logged in to an account with GPT-5.5 access, the two-model panel is unavailable and every run collapses to two Opus 4.8 panelists. That fallback is still useful, and the README argues it is not a downgrade to nothing, since two cold runs of the same model diverge enough that synthesizing them beats running once. But it is a different product from the one the panel name suggests. The README notes the runner uses codex exec and was tested against codex-cli 0.139, which is a version pin worth knowing about before you assume a newer or older codex behaves identically.
There is also a structural limit worth stating. Because the judge is always Opus 4.8, the fusion inherits Opus 4.8's blind spots. A panel can surface a contradiction between its members, but the synthesis is written by one model, and the README does not describe any mechanism for a panelist to challenge the judge's final text. The audit trail is evidence, not a second opinion on the verdict.
Fusion-Fable versus a hosted router like OpenRouter
People searching for this project often arrive from OpenRouter, and the two solve different problems despite both involving multiple models. OpenRouter is a hosted API gateway. You send a request, you get a response from whichever model you selected, and the routing decision is about availability and price. There is no judge step and no written analysis of where models disagree. If you want a multi-model answer through OpenRouter, you call it several times yourself and reconcile the results by hand.
Fusion-Fable is the opposite shape. It is a local Claude Code skill with no server component and no API endpoint. It owns the reconciliation step, which is the part that is tedious to do manually: fan out, collect blind answers, classify agreement and disagreement into named buckets, write the final answer grounded in that classification, and persist the whole thing to a file. What it does not give you is a stable HTTP interface, a hosted endpoint, or the ability to call it from a script that is not Claude Code.
The trade is therefore legibility against portability. A router gives you a request and a response you can log anywhere. Fusion-Fable gives you an audit trail you can read, at the cost of being tied to one editor, one session model, and optional local CLIs. If your problem is that you need multiple model families behind one endpoint, this is not that. If your problem is that you cannot tell whether a single answer is trustworthy, the audit trail is the part that helps.
The optional hook and the maintenance picture
The repository ships hooks/fusion-plan-nudge.sh, an optional PreToolUse hook with the matcher Agent|Task. When the orchestrator is about to delegate a non-trivial implementation task to a sub-agent, the hook injects an advisory reminder to run /fusion-plan --no-interview on it first. It never blocks, it de-dupes per task, and it skips fusion's own panelist spawns.
The important detail is what install.sh does with it. The script copies the hook to ~/.claude/hooks/ but does not enable it. You opt in by adding it to your settings.json, and the installer prints the snippet. Leaving it off keeps planning fully manual, which is the default and probably the right starting position given the cost of a plan run.
The licence is MIT, which is permissive and imposes no copyleft obligation on the skill files you copy into your Claude configuration. That is a statement about the licence text, not legal advice; if you redistribute modified versions, read the LICENSE file in the repository root for the exact terms. The repository has no published releases, so there is no versioned artifact to pin. You are installing from the main branch, and the last push was on 2026-07-20. That is roughly two months before this writing, which is recent enough that the code has not visibly gone stale, but with no releases and no tags, upgrading means pulling main again and re-running ./install.sh. There is no documented rollback path, and the README does not describe one, so if you modify anything under ~/.claude/skills/fusion locally you should keep your own copy before re-running the installer.
Editorial conclusion
Adopt Fusion-Fable if your Claude Code session already runs Opus 4.8 and you regularly face questions where a single pass is not trustworthy: schema migrations, auth designs, protocol edge cases. Skip it if you are on another model, because the README states the slug becomes nominal rather than literal, or if you want a hosted API, since this is a local skill with no server component. Before trusting it, run one question you already know the answer to and open the provenance file under ~/.claude/fusion-runs/ to confirm the panelists actually answered blind and the judge's consensus section matches what you see. Then check whether the codex CLI is installed, because without it every run collapses to two Opus 4.8 panelists.
Frequently asked questions
How does Fable AI work in Fusion-Fable?
The README describes a panel to judge pipeline. The same prompt goes to several models in parallel, each answering independently with web search and bash and none seeing the others' work. Opus 4.8 then judges every answer into consensus, contradictions, partial coverage, unique insights and blind spots, and writes a final answer grounded in that analysis.
What are fusion models in AI, according to Fusion-Fable?
Fusion-Fable does not define a new model class. It fuses the outputs of existing frontier models by running them independently and synthesizing the results. The README frames the mechanism as independence, then synthesis, and states there are no contrived lenses or personas.
What is OpenRouter fusion, and is it the same as Fusion-Fable?
OpenRouter is a hosted API gateway that routes a request to a model you select. Fusion-Fable is a local Claude Code skill with no server component and no API endpoint that owns the reconciliation step. The README does not mention OpenRouter.
Does Fusion-Fable expose a fusion API?
No. The README documents three invocation paths, all inside Claude Code: natural language, pinned slash commands such as /fusion-opus4.8, and forcing a panel by slug in prose. There is no HTTP endpoint described.
Community notes