Every time Claude Code needed to search, review, or explore something, I had to make a call: handle it myself, or spin up a sub-agent? If sub-agent - which one? Which model? How complex is this task really?
That's five decisions before any actual work happens. Multiplied across a full session, the mental overhead adds up fast. And the decisions aren't free - getting them wrong either burns expensive Opus tokens on tasks Haiku could handle, or accidentally routes critical operations to an underpowered model.
I decided to make this a math problem instead of a judgment call.
A fair question, and the honest answer is that they are worth it for exactly two things and people get burned reaching for a third.
They are worth it for isolation and for parallelism. A sub-agent gets its own context window, so a wide search or a long file read costs you a summary instead of 40K tokens of your own budget. And genuinely independent work runs at the same time instead of in sequence.
They are not worth it for anything you could finish in a handful of tool calls yourself. Every sub-agent re-establishes context before it does useful work, reports back, and then you read the report. On a small task that overhead is most of the cost, and you pay it whether the sub-agent succeeds or not - which is why a sub-agent that fails and retries is the most expensive thing in a session. If you have banned them after watching one burn six figures of tokens on a task that failed three times, you were not wrong about what you saw. The fix is a narrower brief and a smaller model, not a bigger budget.
Be clear about what the formula below does and does not do about that. It is tuned for the first case, not against the second: exploration and search score high enough to delegate on their own, so a one-grep task will still go out. That is deliberate, because search is the clearest isolation win - the tokens stay in the sub-agent's window and only the answer comes back. What the threshold actually protects is the other direction, via penalties heavy enough to keep deploys, payments and credentials on the main agent under almost any combination of delegation signals. Almost, not all, and the arithmetic is worth doing rather than trusting: a critical keyword subtracts 10, while the positive factors are worth 2 or 3 each and there are six of them, so a request that somehow fires every one lands on exactly 3 and goes out anyway. The real protection is that the keyword list is short and specific, not that the numbers make it impossible.
If you want to stop small tasks delegating, there are two places to turn the dial and they are not interchangeable. Dropping the exploration weight from 3 to 2 targets one signal: a lone search stops going out, and nothing without an exploration signal in it changes at all. Raising the threshold from 3 to 4 catches that case too, but also every other combination that lands on exactly 3 - and those exist, because factors stack at 2 to 3 each and penalties subtract 3 to 10, so plenty of multi-signal tasks total 3 with no exploration in them at all. Change the weight if search is the thing bothering you, the threshold if you want the whole system more conservative.
Want the foundational patterns first? The free 3-pattern guide covers memory, delegation, and knowledge graphs at concept level.
The Problem: Manual Delegation Doesn't Scale
When I built out my first few agent types, manual routing was manageable. I knew the agents, I could roughly estimate complexity, the overhead was tolerable.
Then I had 50+ agent types.
At that scale, the decision tree becomes impossible to hold in working memory. Most developers hit one of two failure modes. The first: never delegating. Every task stays with the main agent, which means paying Opus rates for searches, explorations, and reviews that a cheaper model could handle at a fraction of the cost. The second: always delegating. Everything gets routed out, including the tasks where you actually need the main agent's full context and reasoning - critical deployments, sensitive configuration changes, complex architectural decisions that require careful judgment.
Neither extreme is right. What I needed was a system that could reliably distinguish between the two - without my involvement.
The Solution: A Scoring Formula for Claude Code Delegation
The core idea is straightforward: task characteristics map to points, and points determine whether to delegate and which model to use.
Each incoming message gets analyzed for characteristics. Some characteristics add points - the task involves searching across a codebase, or it's clearly independent from the current context, or it's a research question. Some characteristics subtract points - the message contains critical operation keywords, or the user is asking for an explanation rather than execution.
When the score crosses a threshold, delegation happens automatically. When it doesn't, the task stays with the main agent. No judgment call. No five decisions.
The threshold sits at three points. Below three: stay with Opus. At or above three: delegate. The number isn't arbitrary - it's calibrated to let a single strong delegation signal trigger automatically (exploration keywords score high enough alone), while requiring multiple weaker signals to combine before delegation fires.
Safety penalties are the critical design choice here. Certain keywords - deploy, production, payment, password - carry penalties large enough to override almost any combination of positive factors. A task with two or three delegation signals and a critical keyword lands well below the threshold and stays with the main agent. It is not a hard interlock, though, and it is better to know that than to assume it: the six positive factors total +13 against the keyword's -10, so a request that fired every single one would scrape back over the line. What does the work in practice is keeping the keyword list short and specific.
A Concrete Example
User message: "search the codebase for all authentication patterns."
The hook reads this and scores it. Exploration and search are high-value delegation signals - they score high enough to cross the threshold on their own. The task is clearly independent from whatever else is in the session. The score lands well above three.
Model selection happens next, and here it is task type that decides. This is exploration, and exploration routes to Haiku - the same rule the diagram below shows. Delegation fires, Haiku runs the search, and what comes back is the answer instead of every file it had to read to find it.
Now compare that to: "deploy the payment system."
The hook scores this too. There's an independent task signal, which adds points. But "deploy" and "payment" are both critical operation keywords. The penalties are aggressive by design. The total score goes sharply negative. The task stays with the main Opus agent, which has full session context and appropriate caution for irreversible operations.
Same formula, opposite outcomes. The difference isn't a rule I wrote about deployment - it's the penalty system making the math work correctly.
The Result
The before state was five decisions per task. Operator overhead on top of every piece of actual work.
The after state is zero decisions. The formula runs on every message in the background. Tasks that should be delegated get delegated. Tasks that should stay with Opus stay with Opus, and it is worth being precise about what that means mechanically, because it is not one rule. Not delegating is the main agent keeping the task, so most Opus work is simply what you get when the router does not fire. Among the tasks that do go out, the task-type table itself only ever yields Haiku or Sonnet. The exception is a trait override layered on top, and it is in my own setup rather than in the open-source version below: the two heaviest roles, security fixing and architecture fixing, are pinned to Opus inside a sub-agent, because those are the cases where the isolation is worth paying full rates for. If you install Evolving Lite you get the first two mechanisms, not the third. I never think about any of it.
The cost impact is real. Haiku costs a fraction of Opus per token. When the system automatically routes simple searches and exploration tasks to Haiku, those tasks are both faster and cheaper - without any quality tradeoff for that class of work. The savings compound across a full session.
There's also something no competing framework does here. CrewAI uses role-based routing - you assign roles to agents manually, and tasks go to whoever has the matching role. LangGraph uses explicit state machines - you build graphs of nodes and edges that define legal transitions. Both approaches require upfront design work and don't adapt based on what the task actually is.
This system uses quantitative scoring. The task itself determines where it goes. No predefined roles. No explicit graph. Just arithmetic on task characteristics.
- -5 decisions per task (delegate? which agent? which model?)
- -Opus tokens burned on simple searches
- -Critical tasks accidentally sent to Haiku
- -No learning from delegation patterns
- +Zero manual decisions - formula handles routing
- +Haiku handles searches, Opus handles architecture
- +Safety keywords block delegation of critical tasks
- +Gap tracking reveals missed delegation opportunities
This is different from the broader multi-agent architecture post, which covers how to build and orchestrate a system of agents. That post is about structure. This post is about the decision mechanism - how the system knows, for any given message, whether to delegate at all and where to send it if so. The architecture and the router are complementary layers. It also connects to hook-based automation patterns - both use the same UserPromptSubmit event to intercept and process messages before Claude acts on them.
The full implementation - complete scoring tables, the Python hook, model routing configuration, and the gap tracking setup - is included in Evolving Lite. Free and open source.
This lives in primeline-ai/evolving-lite - the self-evolving Claude Code plugin. Free, MIT, no build step.
