# Claude Code Fusion July 2, 2026 ยท Engineering, AI Turning one Claude Code session into a tech lead, cheap Claude tiers into workers, and the Codex and Grok CLIs into peer engineers billed to their own subscriptions. I pay for three coding subscriptions: Claude, Codex, and Grok. For months the Claude one did all the work while the other two sat idle, and the most expensive model on the Claude plan spent its quota running test suites and renaming variables. The wrong model was doing the wrong job on the wrong bill. [claude-code-fusion](https://github.com/okisdev/claude-code-fusion) is what I built to fix that. It turns a Claude Code session into a tech lead that plans, delegates, judges, and almost never implements. Cheaper Claude models do the mechanical work. The Codex and Grok CLIs, already installed and already paid for, act as peer engineers whose tokens bill to their own subscriptions. This post is the story of building it, including the parts that got thrown away. ## What didn't survive first contact Two obvious architectures died in the first research pass. Proxy routers break subscription auth: since Anthropic tightened OAuth enforcement in 2026, only the official Claude Code binary can authenticate with subscription credentials, so a proxy costs you the quota and the top model tier, the exact two things worth optimizing. An MCP server died on the project's core metric: it parks its schema in the orchestrator's context forever and pipes full peer transcripts into the same window. The CLIs already speak JSON and fan out fine. So the verdict: build a plugin, but only half the system should be one. The Grok integration needed real code. The orchestration layer needed none, just model-pinned subagents and a routing policy in a rules file. ## The shape Four layers: an orchestrator that only coordinates, three Claude workers, two peer engineers, and a panel for decisions where being wrong is expensive. The orchestrator runs on the strongest available model and holds one hard rule: if a tool call is producing the artifact you asked for, that call belongs to a worker. Its own tool calls are coordination only, a peek to phrase a better brief, a spot check, a final review. Below it, three Claude workers pinned by role: `deep-reasoner` (Opus, hard reasoning), `fast-worker` (Sonnet, work that needs Claude Code's own tool surface), `trivial-worker` (Haiku, now a fallback). Beside them, the peers: Codex takes well-specified implementation, Grok takes quick fixes, drafts, and research. They are not Claude, and a second opinion from a different model family fails differently. The routing boundary is the sentence I care most about in the whole policy: difficulty is not the delegation boundary; ambiguity is. Hard-but-mechanical work delegates freely. Anything whose brief would itself require judgment to write stays home until the ambiguity is resolved. ## Wrapping a CLI you don't control The Grok half is real code: a dependency-free Node runtime that wraps the Grok CLI's headless mode and reports every outcome as machine-parseable footer lines, `state: done|error|cancelled`, plus a `failure: ` on errors. The failure kinds drive a circuit breaker; the orchestrator parses the line instead of guessing from prose. My favorite small detail: the runtime's timeout is 570 seconds because the tool that invokes it dies at 600, and the runtime must always live long enough to write down what happened. And everything is tested against `tests/fake-grok`, a fake that started with eleven canned behaviors and now replays nineteen, one fossil per failure mode the live system has hit since. ## The permission surprise The best bug was not in my code, and it came in two acts. Act one: during hardening I found Grok loading permission rules straight out of `~/.claude/settings.json`. My "read-only consult mode" was not read-only; inherited allows let it write files and even launch nested `grok` commands, a consultation that could recursively bill itself. The fix rests on one verified property, deny beats allow: every consult run now carries explicit denies on writing and on launching any AI CLI, and passes `--no-subagents`, because Grok also auto-discovers my agents and would happily spawn my own workers back at me. Act two, a few sessions later: research briefs kept coming back empty. The trace was damning. When a consult run touches a tool outside the allow list, Grok does not return an error; it cancels the whole turn and exits zero. The runtime saw success and reported `state: done` with empty output, and a sibling project shipped a feature tuned on zero data, twice, before anything looked wrong. Seven failure kinds were designed. The eighth, `permission`, was discovered. ## The panel For expensive decisions, `/fusion:panel` sends one neutral brief to Codex and Grok in parallel, blind: neither sees the other's answer, not even in follow-ups. The orchestrator adjudicates with a structured judge pass first: consensus, contradictions, unique insights, attributed by engine. Blindness is the point. When the panel reviewed one of its own sibling features, both engines independently found the same subtle flaw, a diff hash that misses untracked files. Two engines converging without seeing each other beats one engine agreeing with itself twice. ## The system audited itself Before going public, the system ran its own acceptance test, all four executors live at once, and caught a real fail-open: the stop gate expected its `BLOCK:` verdict on line one, Grok prefaced it with a sentence of chatter, and a genuinely dangerous diff sailed through. The parser now scans every line, and there is a regression test. Mid-audit, the Grok track itself failed with `failure: auth`, and the circuit breaker, which another track was auditing at that exact moment, rerouted as designed. The mechanism validated itself while under review. ## The idle bench Then I read the transcripts of the system actually running and found the failure mode I hadn't designed for: Claude still did almost all the execution. The peers only appeared where the rules had framed them, as reviewers. Two paid subscriptions, mostly idle. The fix was a reframe, not a knob. The policy now opens with my favorite sentence in the repo: run the session like the founder of a well staffed startup; you decide, employees execute, and the bench is already paid for. Bias to fan out. Five or more concurrent delegations is a normal state, and under-dispatching is the failure mode to watch for, not over-dispatching. Two things fell out of the same complaint. The useful one: Claude Code's auto-delegation is driven by description competition, not by rules files. The Grok agent self-triggered because its description was trigger-shaped; the panel never fired because it lived only in the rules. Every description got rewritten to compete for its moment. The fun one: `/fusion:ultra`, a fleet mode that splits a "be exhaustive" request into six to eight facets across both peers and synthesizes one deliverable. The project that inspired it turned out to run on a MITM proxy borrowing OAuth tokens, the exact architecture this project ruled out on day one. ## Managing is harder than hiring The next stretch of policy is pure management. Truncation is not completion: four workers hit their 30-turn cap in one day, and each completion notification presented the worker's last sentence, forward-looking narration like "Now update the imports in...", as if it were a final report. The lesson was not a bigger cap. A turn cap is a runaway breaker, not a task-size estimate, and the real fix is detection by shape: a result that ends mid-thought, or lacks the verification its brief demanded, is a truncated run, and gets resumed until it reports properly. Reuse got rules too, after one worker quietly absorbed five follow-up tasks and ended the morning at 78 percent of its context window. A warm worker only takes follow-ups on the same files. Everything else gets a fresh agent, and after about three follow-ups the work rotates to a fresh worker whose brief carries the decisions, not the memories. ## The lanes follow the models The peer lanes lasted about a day before one question undid them: why do we always send Grok to implement, and almost never Codex? The history was blunt. Codex had received exactly one write task, and had never failed, reworked, or discarded anything. The imbalance was written into the prose: Grok's lane description read like an invitation, Codex's like a rescue line, and auto-delegation obeys descriptions. So the lanes flipped to match the models actually behind them. Codex's engine follows instructions literally and rewards spec-grade briefs, so it became the implementation lane, with a hard gate: completion criteria, output contract, boundaries, verification command, or the brief is not ready for Codex. Grok's default engine turned out to be Cursor's Composer, repurposed after the acquisition, fast and precise on scoped fixes, so it took the quick lane and the trivial tier with it. The research also surfaced one uncomfortable data point: the orchestrator's own model has a mixed coding reputation and a strong orchestration one. The bench is not the only one with a lane. ## Named for the pattern, not the model The project spent its first days as claude-router, until an uncomfortable question: what happens when the current top model is superseded? A system named for one orchestrator has its identity coupled to that model's lifespan. Around the same time I found OpenRouter's Fusion and Cognition's Devin Fusion, the same blind-perspectives-plus-judge pattern, converged on independently. The pattern deserved the name; the model didn't. The technical consequence: roles bind to model tiers, not model IDs, so new releases slot into their roles with zero configuration. ## The numbers I refuse to publish I wanted a benchmark, and the first draft was private telemetry, until I named the real goal: publish it, tell people this works. That flips the design, because readers do not trust you; they can only reproduce you. The methodology went to a blind two-engine panel before any harness existed, and both engines flagged the same embarrassment: a reproducibility document for a harness that did not exist. What shipped is the harness, not the numbers: pre-registered tasks, verifiers that prove themselves against seeded mutants, and a publication gate that requires a full task suite before any number goes public. The pool currently holds one task, so the README says plainly that the numbers do not exist yet. The gate blocking its own project's marketing is the mechanism working. ## Enforced versus requested The most honest split in the README, and one I now want in every agent system's docs: what is runtime-enforced versus prompt-requested. Deny lists, timeouts, failure classification: enforced, in code, tested. Routing, panel blindness, the circuit breaker policy: requested, in prose, dependent on a model following instructions. Both are real, but they fail differently, and pretending prose is enforcement is how agent systems get trusted more than they deserve. ## Coda This post went through the system too: subagents mined the transcripts, workers built the diagrams, and the orchestrator wrote the prose and judged the results. Every update since has worked the same way. The marketplace lives at [okisdev/claude-code-fusion](https://github.com/okisdev/claude-code-fusion): ```bash claude plugin marketplace add okisdev/claude-code-fusion claude plugin install grok@claude-code-fusion claude plugin install fusion@claude-code-fusion ``` Then `/fusion:setup` once per machine, and `/grok:setup` if Grok is on your PATH. If you pay for more than one coding subscription, the expensive question is no longer which model is best. It is which model should be doing the job in front of you, and on whose bill.