Devin Fusion Is Only Half Right. Why Cost Is the Wrong Optimization Goal.

1. Routing shipped as a product

Devin Fusion runs two parallel agents: a frontier model and a cheaper "sidekick" model, each with its own persistent, cached context. The frontier model makes the significant decisions (the plan, the ambiguous calls, the final review) and delegates execution to the sidekick. A lightweight classifier decides, mid-run, when to switch which model is in charge. Cognition reports a 41% cost reduction at the same quality, and Aaron Levie ran the same experiment by hand and was surprised to find that delegation lowered total cost rather than raising it. His conclusion: the harness is becoming the core area of differentiation.

That last claim is the one worth pressing on. If the harness is the moat, which part of the harness? The answer people reach for is the router: the policy that decides which model runs which step. I want to argue that the router is the least defensible part of the whole thing, and that the real work happens before it.

2. The sidekick optimizes cost

The sidekick pattern is an economics move. Put the expensive model on the decisions, put the cheap model on the token-heavy grunt work, keep both contexts warm so switching between them does not trigger a cache miss. Everything about the design is organized around one objective: spend fewer expensive tokens without losing quality.

Cognition's own examples make this concrete. Modernizing a file to ES6 is a trivial edit, but verifying it means babysitting a slow Playwright end-to-end suite. The expensive part is watching the tests, not writing the code, so they hand the test-watching to the cheap model and save 62% with no quality loss. Ripping an unused library out of a large Go codebase is mechanical work across many files with almost no judgment calls, so the entire task goes to the cheap model, 32% cheaper at the same quality. The pattern is clear: delegation pays off when the expensive work is low-intelligence, high-token, and cleanly separable.

3. Cost is the wrong target

This is where I part ways with the design. Because the sidekick's objective is cost, it back-derives a rule: the main agent should "take minimal actions, and only read what is absolutely necessary." The system is being told to read less and do less, not because the task is small, but because reading and doing cost money.

That is optimizing the wrong variable, and the failure shows up in Cognition's own results. Their launch note admits the savings are not uniform: "serial debugging tasks necessitate accumulated context to trace the error." In their blog, a React and Redux feature delegated to the sidekick scored only 27. Both are the same failure. The moment a task needs continuity, a cost heuristic that starves the agent of context produces a quality collapse. You told the agent to read less to save money, and it read less, and then it could not do the job.

4. Optimize the decomposition, and cost falls out

The fix is not a better router. It is to move the intelligence upstream, to the decomposition. Qualify each phase of the work well enough, with a clear goal and a clear definition of done, and the agent's job on any single phase becomes small. The agent then takes few actions, not because you forbade the rest, but because a well-scoped task does not need them.

Same behavior, opposite mechanism. The sidekick clamps the agent at runtime and hopes it does not starve. Good decomposition makes the clamp unnecessary at design time. Few reads are now a result of good carving, not a rule imposed on a hard task, so quality and cost move together instead of trading off. A small, well-specified task is both easy to do right and cheap to run.

This is the argument in three steps, and the order matters:

1. Qualify each phase's goal properly, so the work is well scoped.
2. A well-scoped phase is easy for a cheap model to execute correctly. High-quality delivery is the direct result.
3. Cost-effectiveness is the side effect. It comes along for free, because you never had to spend expensive tokens fighting an underspecified task.

5. Why this is structural, not incidental

Step 3 is stronger than "and it also happens to be cheaper." Good decomposition does not eliminate the cost of frontier intelligence. It relocates it. The expensive reasoning moves from runtime, where the sidekick pays for it on every step it micromanages, to design time, where you pay for it once while writing the plan.

That is the real reason it is cost-effective. You are amortizing. The frontier model (or a person, or both) is expensive exactly once, when it carves the task into the right milestones. After that, a cheap model runs many steps against a plan that already removed the hard reasoning. Compare that to paying the frontier model to sit in the loop and re-decide every step, which is what the sidekick's "delegate and monitor" actually costs. One up-front carving versus per-step micromanagement.

Which surfaces a position that neither Cognition nor most of the routing literature states outright. The sidekick says: frontier decides, cheap executes, per step. The better claim is: the frontier model's best use is not per-step manager but up-front decomposer. Spend the expensive intelligence on carving and qualifying the goals, then hand the whole execution to a cheap model. Frontier tokens on decomposition, cheap tokens on execution. Carve once, do not route every step.

6. When decomposition wins, and when it does not

I want to be honest about the boundary, because "my approach is always better" is the claim a single counterexample kills. The dividing line is not how long the task is. It is whether you can understand its structure before you start.

On plannable long-horizon work, decomposition wins, and it wins precisely on the tasks Cognition admits are its weak spot: serial, dependent chains where accumulated context matters. There is no per-step classifier to accumulate routing errors, the plan is auditable, and drift gets caught at the next milestone.

On genuinely unpredictable work, research, debugging an unknown failure, an interactive session where hard follow-ups arrive after simple prompts, the sidekick's reactivity is more robust. You cannot decompose what you cannot foresee, and a coarse milestone gate corrects more slowly than per-step routing. The sidekick also skips the up-front cost of writing a plan, which matters when the plan would be wrong anyway.

And to keep the cost accounting fair: decomposition's total has to include the price of the decomposition itself. On a one-off short task, the sidekick can be cheaper because it never pays that up-front tax. The advantage of decomposition grows with task length and with reuse. The more steps a plan governs, and the more times you run the same class of task, the harder the up-front carving amortizes in your favor.

7. The actual moat

So back to "the harness is the moat." The router, the part everyone is excited about, is the commoditizable part. Routing between a strong and a weak model is a solved genre: a small learned classifier scoring difficulty, which anyone can train and anyone can copy. If your differentiation is the router, your differentiation has a half-life.

What does not commoditize is the judgment that turns a vague, sprawling goal into five milestones that cannot be faked. That is not a model you can distill. It is taste about where a task actually splits, what "done" means at each seam, and which parts carry the accumulated context that must not be severed. The router is downstream plumbing. The decomposition is the thing worth defending.

8. What I would measure next

A thesis is cheap. The honest version of this argument is an experiment, and it does not require training a model or building a new environment. It is inference-only measurement on existing tasks:

• Take a set of plannable long-horizon tasks that already exist.
• Run two arms with the same cheap executor model: one with sidekick-style runtime delegation, one with explicit decomposition plus milestone gates.
• Measure de-confounded token cost (completion and new input, not re-sent history) and quality per task.
• Plot the cost versus quality frontier and see whether decomposition dominates.

Three things keep it honest. The sidekick baseline has to be faithful, not a strawman. The cost of the decomposition itself has to be counted in the decomposition arm's total, or the comparison is rigged. And the strongest result is not "mine is better," it is the crossover: decomposition dominates on plannable long-horizon work, reactive routing holds the unpredictable regime, and here is where the line falls. If that curve reproduces Cognition's own serial-debugging caveat as a measured effect, the benchmark is measuring the right thing.

That is the follow-up. For now the claim stands on its own logic: the router is the part you can copy, the decomposition is the part you cannot, and cheap delegation is what you get for free when you carve the task well, not the thing you should be optimizing for in the first place.

References

1. Cognition. "Devin Fusion." cognition.com/blog/devin-fusion, 2026.
2. Cognition. Launch thread, on non-uniform cost savings and serial debugging. x.com/cognition, 2026.
3. Aaron Levie. On the Fable-as-manager cost experiment and the harness as differentiation. x.com/levie, 2026.
4. Ong et al. "RouteLLM: Learning to Route LLMs with Preference Data." LMSYS, lmsys.org, 2024.