What Opus 5 changed in my delegation doctrine

Flight Deck 1.9.0 went out today. Half of it is Windows support, a PowerShell twin of the fanout guard so the package runs without Git Bash. That half is plumbing. The other half is the one I actually thought about: going back through the routing doctrine and recalibrating it, because Opus 5 now sits alongside Fable 5, Sonnet 5 and Haiku 4.5, and the grid I had written no longer described the models I was actually using.

A routing doctrine has an expiry date

The core claim in mission-control is model-agnostic. The frontier session model plans and verifies, calibrated cheaper subagents execute, nothing gets called done without evidence. None of that depends on which models exist this month. But a doctrine that stays that abstract is useless in a session: to be operational it has to say which model takes which lot, at which effort, and that means naming names.

So it describes roles that outlive models, encoded in a grid that does not. Before 1.9.0 the activation block read “on Claude Fable 5 or an Opus-class session model.” That was already a hedge, a placeholder for whichever second frontier model happened to be around, and it was harmless while nothing filled it precisely. The moment Opus 5 landed it stopped being harmless: the slot was no longer a vague class but a specific model with a specific price and a specific job, sitting between the default execution tier and the most expensive one. A grid that hedges about its own middle rung routes badly.

The old grid, and the new one

The old grid had four rows. Planning and verification on the session model. haiku at low effort for mechanical work outside code. sonnet as the default, and the floor for anything touching real code. opusfor what it called nuanced judgment, publication-grade writing and multi-step reasoning within the lot. Read that last row back and the problem is obvious: it is a mood, not a boundary. It was written when the frontier was Fable 5 and “Opus-class” meant whatever felt like the tier below.

The new grid names four explicit tiers and gives each one job. Haiku 4.5 takes zero-judgment mechanics outside code: extract, list, count, reformat. Sonnet 5 is the default execution tier and the floor for anything that touches real code. Opus 5 takes complex agentic coding, large-scale refactoring, systems engineering, publication-grade writing and long autonomous runs. Fable 5 is reserved for the hardest reasoning and the longest horizons, nothing routine, and it costs roughly twice what Opus 5 does.

Two things follow. An Opus session is now a normal frontier session rather than a splurge, at half of Fable 5's price. And Sonnet 5 absorbs a whole class of lots that used to justify an opus pin. The doctrine always said opus is the exception, and that a plan where most lots want it is a badly split plan; on this lineup that line finally has teeth. Reaching for opusshould be a decision you can defend, not a reflex when a lot looks slightly serious. The routing rule itself did not change and stays relative to your session model, but the grid now says out loud that the models it names are today's instances of the tiers, not the tiers themselves. I put that sentence in so the next reader knows which half to distrust first.

Verifier subagents are now the exception

The old doctrine said that past roughly six lots you should parallelize the checking: hand the mechanically verifiable criteria to fresh-context verifier subagents, one per lot, and keep the judgment for yourself. That is now demoted from a default to an exception.

The reasoning I had been leaning on is that verification by a fresh context beats self-critique, because an executor cannot see its own blind spots. Still true, and it is about someone else's deliverable. It had quietly been applied to the wrong thing. A current frontier model already re-checks its own output without being told, so spawning an agent to make it check itself buys nothing and costs a turn. Meanwhile, checking a subagent's deliverable against criteria you wrote before launching it is not a chore to farm out, it is the job the orchestrator is there to do.

So a verifier subagent spins up in two cases only: when the checking is itself heavy, many lots at once or purely mechanical counts, links and formats, or when I deliberately want an independent adversarial read. Then it gets pinned to haiku or sonnet at low effort, and every judgment call still comes back to me.

A hard ceiling of 20 parallel agents

This is the change I find most interesting, for what it says about the direction of travel. Flight Deck exists partly because Claude Code, out of the box, barely delegated. The whole point was to push a session toward splitting work up and handing it out. On the current frontier models that problem has inverted: they reach for subagents on their own, enthusiastically, and every extra one multiplies cost and latency without adding quality.

So the doctrine now caps enthusiasm instead of encouraging it. Adding a lot has to clear a higher bar than not adding it, a task that one subagent settles gets exactly one subagent, and there is a hard ceiling: past 20 parallel agents, the user must have asked for that explicitly. The old line about three well-specified lots beating ten crumbs is still there, but the floor now matters as much as the ceiling.

The effort ladder, restated honestly

Two corrections here, one factual and one that changes how I work. The factual one: effort accepts low, medium, high or xhighper call or in a subagent definition's frontmatter. max exists at session scope only and is not a valid per-call value, a per-call effort: "max" errors. The doctrine used to list it as another rung on the same ladder.

The one that matters: high is already the default on the current Opus and Sonnet tiers, so setting it changes nothing. Every instruction that said to set high effort was describing the status quo and feeling productive about it. The lever that pays goes the other way. Low and medium are unusually strong on the current top tiers, which makes them the primary control on cost and latency for execution lots rather than a degraded mode you accept reluctantly. xHigh stays for hard code or for verifying a critical lot, and raising effort has never rescued a badly specified lot.

I wrote a post a while back about running Opus 4.8 at High rather than xHigh. I am not reversing it. The conclusion was that xHigh is a deliberate escalation and not a default, and that holds. What moved is where the default sits: High used to be something I set, and now it is what I get. Same direction, different action, because there is nothing left to raise, only something to lower.

Scope discipline, written into every phase

One more line runs through the whole doctrine now: the plan states where a lot stops, and holds it there. That is a response to something I kept watching happen. The current models add steps nobody asked for and apply their own judgment about what the work should have been, without saying so. Often the addition is defensible on its own terms, but it is a scope change nobody approved and nobody was told about.

The counterweight sits in two places. The brief names the stop line, because an over-briefed subagent over-builds and a current one widens on its own. And the verify pass hunts over-delivery as hard as it hunts gaps, since done criteria measure presence and never restraint: a lot can satisfy every criterion and still have grown an abstraction with exactly one caller.

The same reasoning hardened close-out from guidance into a hard rule. The knowledge pass, sweeping memory, CLAUDE.md and the project's own docs, is now the first action on any close-out signal, run and announced as such before any mechanical teardown. Stopping a dev server and deleting temp files is not close-out. Touching one memory file earlier in the task does not discharge the pass, and work that has not merged yet does not defer it.

What did not move

Almost all of the shape survived, which is the part I take some comfort from. Plan, delegate, verify is unchanged. The orchestrator is still the ceiling: route each lot at or below the session tier, never above it without the user's explicit approval. Done criteria are still written before the agents launch. Verification is still not optional, because skipping it means you just paid less for an unchecked result. And a lot that touches real code still never drops below Sonnet.

What the split tells me is that a delegation doctrine has a stable core and a perishable surface, and it is worth knowing which is which before a release makes you find out. The roles are durable. The grid, the tier names, the effort defaults, the assumption that models under-delegate, all of that is a snapshot of one lineup, and mine went stale in a matter of weeks.

The usual caveat, and I mean it: this is hands-on calibration from my own use, on my own workload, not a benchmark. I measured nothing. What I have is a doctrine that stopped matching what I was seeing in sessions, and a rewrite that made it match again. Run it on a different kind of work and you may land somewhere else, which is why the grid is deliberately easy to edit. The same release also brought native Windows support through that PowerShell fanout guard, a story for another day; the source for all of it is at github.com/CaseReed/flight-deck.