How Devin Fusion Ran a Five-Day Company-Brain Cutover

Narrated, with burned-in subtitles. All costs in the video are list-price reconstructions from the method below. Also on YouTube.

Disclosure. I am a Devin ambassador. This describes a real production system; hostnames, page identifiers, customer names, tokens and credentials are omitted. Counts, dates and token figures come from Git history and the Devin CLI's local session store on my machine. Every dollar figure is a list-price reconstruction, not a bill.

Success IT runs a fleet of AI agents - support, engineering and synthesis agents, coding harnesses such as Devin and Codex, and humans - that share one durable memory about our products, tickets and runbooks. That memory is the company brain: a GBrain engine serving Git-backed Markdown over MCP.

The design, argued in Two Brains, One Operator, is fences, not gates: agents write directly, but only inside a prefix the server enforces; Git history is the audit trail; a frozen archive holds historical imports, labelled as such; and I only get pinged for exceptions. My brief to Devin was blunt:

"I need assurance that the whole process is EASY. I don't want to have to review all the information all the time. I only want to handle exceptions." And: "Let's not deviate from the intention of the authors of GBrain."

So the work was the opposite of building a pipeline. Retire my custom capture-verify-promote pipeline, move to the engine's stock model, then make the brain genuinely useful for development, product understanding and support.

On day two, Devin reported that native synthesis was working well: a clean two-method reconciliation procedure, with a real conflict flagged between two manuals. On day three it came back with a correction. It had captured the exact request the engine sent to the model, and the evidence block for the relevant page contained only provenance. The detailed answer had come from another agent's injected memory, not from the brain. The lean agent, given the same block, had answered "the excerpt contains only provenance" - the faithful answer.

In Devin's words: "I reported that answer as good yesterday; that was wrong." It then rerouted the engine's model calls to the lean agent, rewrote the agent instructions to read the full page before quoting, and filed the evidence-budget issue upstream. That is the behaviour I want from a coworker.

Devin Fusion runs two full agents in one session. The lead (Claude Fable 5.1 Medium) owns the plan, the interpretation of ambiguity, the correctness-critical authoring, the review, and every word to me. The sidekick (SWE-2 Medium) does the hands-on work from a bounded brief: running the sync loop, patching scripts, generating the 14 hubs, executing the 75 MCP calls of the eval, collecting evidence read-only. Cognition's own description of the lead: it "should take minimal actions, and only read what is absolutely necessary. By default it should delegate and monitor, while making the significant decisions."

This was not greenfield coding. It was operations and data cleanup: reading whole pages before moving them, comparing duplicate bodies, reading engine source to diagnose a sync stall, and reading every eval answer before grading it. The lead carried ~191k tokens of context on every turn, for 3,602 turns.

The transcript also carries one metered window - 66 lead steps between 24 Sep 07:31 and 25 Sep 04:21 UTC, about 21 hours in the middle of the work:

That is about 129 tokens read for every token written. The frontier model barely typed. It wrote briefs, read reports, reviewed diffs and talked to me. A workload shaped like this is exactly where the question "which model reads what" decides the bill.

Assumptions

• Lead volume: 688M context tokens, split at the measured 86.8% cached / 13.2% uncached (597M / 90.8M). Lead output: ~0.35M tokens of stored text; I allow 1M to cover reasoning tokens.
• Sidekick volume: not recorded locally. I assume it processed the same context volume as the lead at the same cache ratio, and produced five times the output (5M tokens) because it writes the code and scripts. It could be half or double.
• Cache writes priced as base input; batch discounts ignored. The metered window covers 21 of ~118 hours, so treat every figure as an order of magnitude.

Lead on Fable: 90.8M uncached × $10 + 597M cached × $0.25 + 1M out × $50. Sidekick on SWE-2: 90.8M × $3 + 597M × $0.30 + 5M × $15. Other rows substitute prices. Rounded to the nearest $10.

My first instinct was that Fusion saves money because the expensive model does not type. The numbers say otherwise. Here is the sidekick line, priced on Fable versus on SWE-2:

1. About 80% of the gap is uncached input, not output. Fable alone costs ~48% more than the pairing - equivalently, Fusion is ~32% cheaper, against the 41% Cognition reports for Fusion with Fable 5 on its FrontierCode benchmark. Most of that comes from the bulk context the sidekick reads at $3 per million instead of $10. Output savings are real but small.
2. The lead's own bill is mostly cache misses. Of the lead's ~$1,110, about $908 (82%) is uncached input. Fable 5.1's cache-hit rate ($0.25) is half of Opus 5's ($0.50), so a frontier lead that stays in cache is cheap to keep reading. Missing the cache is what costs money.
3. Splitting only pays if neither model loses its cache. "Ask the smart model" tools re-send the task context on every call, uncached. In Fusion, the lead and the sidekick each keep their own persistent, cached context, and model switches happen at context compaction, which would miss the cache anyway. 87% of my lead's context was a cache hit.
4. Caching is why the job was affordable at all. At Fable list rates the lead's 688M context tokens cost ~$1,060 with that hit rate (90.8M × $10 + 597M × $0.25), against ~$6,880 with no cache at all. That saving belongs to caching, not to Fusion specifically - but it is the constraint any multi-model split has to preserve.
5. Against Opus 5 as sidekick, SWE-2 saves roughly $350 here. Against Sonnet 5 it is not cheaper per token. The argument for SWE-2 is price per task - fewer retries and fewer expensive review rounds for the lead. Across 61 handoffs I sent one consolidated rework brief that I can recall, but one project cannot prove that counterfactual, so I will not claim it.
6. In practice the bill was a plan quota. The session metadata records zero credit cost, and I hit my self-serve plan's usage limit on day five. The table is what this work is worth at list price, not what I paid.

• Judgment stayed with the lead. The eval questions, the grading rubric, the upstream issue text and every architecture decision were authored by Fable; the sidekick executed the 75 MCP calls from the spec and handed back raw results. When I asked it to think harder, the answer was a ranked list of five retrieval optimisations with payoff estimates - not more tool calls.
• The sidekick survived interrupts. Twice I paused the session because another agent was working on the same system. When I said "continue", the lead first re-checked the vault, the writer queue and the sync position rather than assuming nothing had changed.
• Reports were reviewed, not trusted. The lead read query results itself when ranking moved the wrong way, read a 20-page sample itself before recommending I keep another agent's ingest, and read every eval answer before grading. That is where the frontier model earned its rate.
• Handovers were part of the job. When I said we were close to the usage limit, the output was a 274-line handover grounded on a fresh status check, committed and linked, so the next agent on any harness could pick it up.

Stock GBrain, one shared source with server-enforced writer fences, direct writes, native maintenance timers, a frozen labelled archive, and Git as the authority. No custom review pipeline. I approve clients and handle exceptions. Next on the handover list: retype 717 session-note pages so documentation questions can filter them, extend product aliases for the variants the eval missed, re-run the same 15 questions for a before/after, and hand the five genuine content gaps to a human.

Method: counts come from the Devin CLI's local session database and transcript (message roles, tool-call table, per-turn context sizes, and one metered window with prompt, cached and completion tokens), read read-only. The session ran from 21 Sep 02:34 UTC to 26 Sep 00:18 UTC. An earlier, smaller Fusion session on the same repository (14-15 Sep) is not included. Fusion design details from Cognition's Devin Fusion post.

• Two Brains, One Operator - why personal and company agent memory split, and the fenced design this session put into production.
• From Company Knowledge to Verified Changes - how the company brain fits alongside CodeGraph and verifiers in our engineering workflow.
• The Last Project You Build Alone - why a brain should outlive any one AI harness.
• Devin Fusion - Cognition's design notes on the sidekick harness.