Token budget is not one pool. That is the insight the whole pattern turns on.
When you work with a strong coding model over a long session, the natural failure mode is context bloat. Every file you read, every command you run, every dead end you explore accumulates in the same window as the high-level plan you are trying to hold. Eventually the conversation you actually care about — the direction, the decisions, the through-line — is drowning in the debris of the work that produced it.
The fix is not a bigger context window. It is separating the conversation you want to keep from the context you are willing to throw away.
Drivers and workers
Modern tool-using models are good at two things that make them natural orchestrators: they decompose a task into steps, and they call tools to execute those steps. The temptation is to treat that as model magic — point a capable model at a big job and let it churn.
The leverage is architectural, not model-magic. A driver conversation stays small and high-level. It never reads the sprawling config file itself. Instead it dispatches a sub-agent, which spins up its own fresh context window, absorbs the large and disposable material, does the messy work, and returns a distilled result — a summary, a diff, a verdict. The expensive context lives and dies inside the sub-agent. The driver only ever sees the conclusion.
Stack that up and the arithmetic changes. A single top-level conversation can direct dozens of context windows' worth of work without itself growing past a few thousand tokens of actual plan and state. You are not spending one budget. You are spending one small, durable budget to command many large, ephemeral ones.
A concrete test
I wanted a real task, not a toy. The one I chose: take a large infrastructure setup — configuration files plus a deploy process — and convert it into a fully virtualized, in-code implementation. Same behavior, lower cost to run, easier to maintain and reason about.
That kind of migration is exactly where flat single-agent sessions fall apart. You have to read a lot of existing config, understand a lot of implicit behavior, and produce a lot of new code — each of which wants to pile into the same window.
Run through an orchestrator, it stayed inside a single top-level context window from start to finish. The driver held the plan: what to virtualize, in what order, how to verify equivalence. Sub-agents did the reading and the writing — each one consuming, then discarding, a full window of detail. Underneath, the work spanned many windows. On top, the conversation never bloated. I could still see, at the end, the whole arc of what we decided and why.
Where this is the wrong tool
Orchestration is not free, and I would rather be honest about that than sell it.
- Sub-agents lose shared nuance. A worker only knows what you handed it. The tacit context a single long session accumulates — the reason we chose X earlier, the odd edge case we noticed — does not automatically travel. You have to pass it deliberately, or it is gone.
- Hand-offs need clear contracts. The value of a distilled return depends on the sub-agent and driver agreeing on the shape of that return. Vague instructions produce vague summaries, and now your driver is making decisions on bad information it cannot see behind.
- Coordination has overhead. Dispatching, framing, and integrating results costs tokens and latency. Below a certain complexity threshold, a flat single-agent session is simply better — faster, cheaper, and with full shared context. If the whole job fits comfortably in one window, do not orchestrate it.
The pattern pays off past a complexity threshold, not before it. Knowing where that threshold sits for a given task is the actual skill.
Why a skill, not a prompt
I built this as a thin, custom orchestration skill in Cursor rather than as ad-hoc prompting. That distinction matters more than it looks.
A clever prompt lives in one person's head and dies at the end of the session. A skill encodes the pattern — how the driver frames work, what contract sub-agents return, how results get integrated — into a reusable artifact. It compounds. It travels across projects. A teammate can adopt it without me explaining the mechanics each time, the same way shareable AI artifacts have spread across our team faster than any verbal tip ever did.
The skill is thin on purpose. It is not a framework. It is the minimum encoding of a good pattern so that the pattern is repeatable instead of rediscovered. The implementation is on GitHub if you want to read or adapt it.
The bottom line
Stop treating context as a single pool you must ration. Decide which conversation you want to keep — the plan, the decisions, the through-line — and push everything you are willing to discard into sub-agents that burn their own windows and report back clean.
That reframing is worth more than any model upgrade. The next time a session starts drowning in its own debris, ask which of that context you actually needed to keep. Usually, it is very little.