There is a pattern I keep returning to when I think about how intelligent systems — human or artificial actually perform at their best. It is not about raw capability, it is more about fit between the nature of a task and the mind assigned to it. For example a senior architect pulled into writing boilerplate for eight hours straight is not doing their best work, neither is a junior developer asked to make high-stakes infrastructure decisions without adequate context. The waste is not only economic, but it is also cognitive. Something is being misallocated that has real value,
I think the same logic, almost exactly, applies to how we currently use large language models in software development workflows — and a pattern I have been watching emerge called model-delegated execution makes this tension explicit in a way that I find genuinely illuminating.
The context accumulation problem, stated precisely
When you work with a capable language model across a medium-sized feature — say, five implementation tasks — something quietly degrades across the session that is easy to miss until you start measuring it. Every API round-trip sends the entire accumulated conversation as input tokens. By the time you reach task four or five, the model is processing 150,000 to 200,000 tokens per call, the vast majority of which have nothing to do with the task at hand.
This is not a hypothetical inefficiency. It is structural. Context windows are not free cognitive resources; they are shared attention capacity. A model reasoning over 200,000 tokens to complete a focused implementation subtask is doing something analogous to asking someone to solve a focused problem in a room filled with every prior conversation they have had that day. The output will still be reasonable. But it will not be as sharp, and the cost — in tokens, in dollars, in subscription window capacity — is real and growing superlinearly with task count.
| API Call | Task | Input Tokens (Accumulated) | Relevant to Current Task |
|---|---|---|---|
| Call 1 | Task 1: Setup | ~40,000 | ~95% |
| Call 2 | Task 2: Core logic | ~80,000 | ~50% |
| Call 3 | Task 3: Tests | ~120,000 | ~35% |
| Call 4 | Task 4: Integration | ~160,000 | ~25% |
| Call 5 | Task 5: Finalize | ~200,000 | ~20% |
| Total | ~600,000 tokens | Avg. ~45% |
Table 1: Token Accumulation in a Single-Session workflow. Estimated based on typical agentic development session patterns. At task 5, roughly 80% of the tokens being processed are historical noise from prior tasks.
The math is not subtle. A five-task single session might consume 500,000 input tokens. The same five tasks with fresh subagents per task consumes around 150,000. A ten-task session scales quadratically in the single-session model to something approaching 1.5 million tokens, while the subagent approach scales linearly to roughly 270,000.
| Feature Size (Tasks) | Single Session Input Tokens | Model-Delegated Input Tokens | Ratio |
|---|---|---|---|
| 5 tasks | ~500,000 | ~150,000 | 3.3x |
| 10 tasks | ~1,500,000 | ~270,000 | 5.6x |
| 15 tasks | ~3,000,000 | ~390,000 | 7.7x |
Table 2: Context Scaling — Single Session vs. Model-Delegated (Linear vs. Quadratic). The gap between quadratic (single session) and linear (model-delegated) growth is where the capacity gains originate. The advantage compounds with feature complexity.
The delegation insight
What makes model-delegated execution interesting is that it does not simply address this problem by fragmenting work across isolated sessions. That would solve the context bloat but introduce a different failure mode: no oversight, no escalation path, no consistent architectural judgment threading through the work.
Instead, the approach separates planning and review — which genuinely require deep reasoning, tradeoff analysis, and architectural judgment — from execution, which, given a precise specification, is largely a matter of reliable pattern application.
The orchestrating model plans the full feature, produces precise task specifications, assembles focused context bundles for each implementation step, reviews output against those specifications, and handles any escalations where the implementing agent encounters genuine ambiguity. The implementing model receives those specifications, executes against them, runs tests, commits, and either completes or escalates cleanly.
| Responsibility | Orchestrator (Opus) | Implementer (Sonnet) |
|---|---|---|
| Feature planning | Yes | No |
| Architecture decisions | Yes | Escalates to Opus |
| Spec authoring | Yes | No |
| Context bundle assembly | Yes | No |
| Code writing | No | Yes |
| Test writing | No | Yes |
| Running commands | No | Yes |
| Committing | No | Yes |
| Output review | Inline, every task | No |
| Escalation handling | Yes | Triggers when criteria met |
Table 3: Role Division in Model-Delegated Execution.
This is not a hierarchy of intelligence in any meaningful sense. The implementing model is highly capable. What it lacks is not raw capability but architectural context and the mandate to make high-stakes decisions about things the plan did not specify. When it encounters genuine ambiguity — an architectural fork not covered by the spec, test failures that resist quick resolution, a dependency the plan did not anticipate — it surfaces that back to the orchestrator rather than making decisions itself.
The “Tech Lead” analogy
The tech lead analogy that surfaces naturally when describing this pattern is more than illustrative — it captures something structurally accurate about why the approach works.
A good tech lead does not implement every feature themselves. They define the work precisely enough that a skilled engineer can execute it without constant supervision. They review the output against the specification. They are available for escalation when the engineer hits something genuinely hard. Their context stays clean because they are not in the weeds of every implementation detail — they are holding the architectural picture and the cross-task consistency.
Model-delegated execution instantiates this structure in a multi-agent workflow. The orchestrating model stays at roughly 30,000 to 50,000 tokens of context throughout the entire feature. Each implementing subagent starts fresh, executes against a precise 20,000-token context bundle, and terminates. The orchestrating model reviews each output inline — no separate reviewer subagents needed — and carries only what matters into the next task.
| Phase | Orchestrator Context | Subagent Context | Notes |
|---|---|---|---|
| Planning | 30,000–50,000 tokens | — | Opus reads plan, designs tasks |
| Task 1 dispatch | ~35,000 tokens | ~20,000 tokens | Fresh subagent, focused bundle |
| Task 2 dispatch | ~38,000 tokens | ~20,000 tokens | Prior task context discarded |
| Task 3 dispatch | ~42,000 tokens | ~20,000 tokens | Results summarized, not full history |
| Task 4 dispatch | ~45,000 tokens | ~20,000 tokens | Orchestrator accumulates summaries only |
| Task 5 dispatch | ~48,000 tokens | ~20,000 tokens | Peak orchestrator context: ~50K |
| Total input tokens | ~208,000 | ~100,000 | ~308,000 combined vs ~600K single session |
Table 4: Context Size — Orchestrator vs. Subagent.
API cost analysis
Current Claude API pricing (as of February 2026) defines the economic case directly.
| Model | Input (per MTok) | Output (per MTok) | Primary Use in MDE |
|---|---|---|---|
| Claude Opus 4.6 | $5.00 | $25.00 | Orchestrator: planning, review, escalation |
| Claude Sonnet 4.6 | $3.00 | $15.00 | Implementer: code, tests, commits |
| Claude Haiku 4.5 | $1.00 | $5.00 | Potential use for low-complexity subtasks |
Table 5: Claude API Pricing — February 2026Anthropic official pricing documentation
The Opus-to-Sonnet price ratio is 1.67x on both input and output. That ratio is the lever the architecture exploits. Every task handed from Opus to Sonnet saves approximately 40% of the per-token cost for that implementation work. For comparison, at the time of writing, GPT-4o is priced at $5 input / $20 output per MTok, making Claude Sonnet a meaningfully more cost-efficient option for high-volume implementation tasks. AI API Pricing Comparison (2026): Grok vs Gemini vs GPT-4o vs Claude.
| Phase | Tokens (est.) | All-Opus Cost | Model-Delegated Cost |
|---|---|---|---|
| Planning (Opus) | 50K in / 10K out | $0.50 | $0.50 |
| Implementation (5 tasks) | 200K in / 100K out | $3.50 | Sonnet: $2.10 |
| Review (Opus, inline) | 50K in / 5K out | $0.38 | $0.38 |
| Escalation (1 task, rare) | 20K in / 10K out | — | Opus: $0.35 |
| Total | $4.38 | $3.33 | |
| Savings | — | ~24% |
Table 6: Per-Feature Cost Comparison — All-Opus vs. Model-Delegated (example of medium feature with 5 tasks)
| Monthly Volume | All-Opus | Model-Delegated | Monthly Saved | Annual Saved |
|---|---|---|---|---|
| 10 features | $43.80 | $33.30 | $10.50 | $126 |
| 50 features | $219.00 | $166.50 | $52.50 | $630 |
| 100 features | $438.00 | $333.00 | $105.00 | $1,260 |
| 500 features | $2,190.00 | $1,665.00 | $525.00 | $6,300 |
Table 7: Monthly API Cost at Scale
It is also worth noting that prompt caching, which is available on all Claude models - can reduce repeated input token costs by up to 90% on cached content. For orchestrators that repeatedly reference the same architectural context or codebase-wide constraints across dispatches, this compounds the efficiency gains further.
Subscription plan capacity
The economic argument above addresses pay-as-you-go API usage. For developers on Claude Pro or Max subscription plans, the relevant currency is not dollars-per-token but tokens-available-per-window.
| Feature Size | Single Long Session | Model-Delegated | Extra Capacity |
|---|---|---|---|
| Small (2–3 tasks) | ~15 features | ~25 features | +67% |
| Medium (5 tasks) | ~8 features | ~19 features | +137% |
| Large (10 tasks) | ~4 features | ~12 features | +200% |
Table 8: Subscription Plan Capacity
The gains compound because the relationship between task count and token consumption is fundamentally different across the two approaches. Single sessions are quadratic; model-delegated is linear. The larger the feature, the more dramatically the gap widens.
The ecological dimension
There is something worth naming here that tends to get less attention in discussions of workflow optimization: the environmental cost of token consumption is real and measurable.
Research published through 2024–2025 has documented the inference-side energy picture with increasing precision. A 2025 simulation study “Quantifying the Energy Consumption and Carbon Emissions of LLM Inference via Simulations” found that inference now accounts for more than half of the total lifecycle carbon emissions of deployed large language models — a meaningful shift from the earlier assumption that training dominates the footprint entirely. Separate work on energy-per-token benchmarking showed that GPU power consumption during inference scales with both model size and context length, with the prefill stage — which processes all input tokens — being particularly energy-intensive relative to the token generation (decode) stage. “Beyond Test-Time Compute Strategies: Advocating Energy-per-Token in LLM Inference”
| Metric | Single Session | Model-Delegated | Reduction |
|---|---|---|---|
| Total input tokens (5-task feature) | ~500,000 | ~150,000 | 70% |
| Total tokens consumed (in + out) | ~600,000 | ~250,000 | 58% |
| Relative GPU prefill load | Baseline | ~0.4x baseline | ~60% lower |
| Relative inference energy (est.) | Baseline | ~0.5x baseline | ~50% lower |
Table 9: Estimated Inference Energy Impact Estimate based on token-proportional energy scaling. Actual figures vary with hardware, quantization, and data center efficiency. GPU power consumption during the prefill phase scales approximately linearly with sequence length.
The broader context is significant. The AI inference market is projected to grow from $106 billion in 2025 to over $250 billion by 2030, with Gartner predicting that over 80% of data center accelerator workloads will be dedicated to inference by 2028. At that scale, architectural patterns that reduce token consumption by 2.4x are not just good engineering practice — they represent a meaningful aggregate reduction in the compute and energy required to deliver the same software development output.
I do not think this is the primary reason to adopt the approach. The quality, cost, and capacity arguments are strong enough on their own. But when token efficiency and ecological efficiency point in the same direction rather than trading off against each other, that alignment is worth naming explicitly.
Comparison with alternative execution approaches
| Dimension | All-Opus Single Session | Subagent-Driven Dev | Executing Plans | Model-Delegated |
|---|---|---|---|---|
| Fresh context per task | No | Yes | Partial | Yes |
| API cost per feature | $4.38 | Higher (3 agents/task) | ~$3.50 | $3.33 |
| Context efficiency | Quadratic | Linear | Moderate | Linear |
| Escalation path | N/A | None | None | Built-in (Opus) |
| Review quality | Opus (inline) | Sonnet reviewers | Human-in-loop | Opus (inline) |
| Subagent dispatches/task | 1 | 3 (impl + 2 reviewers) | 1 | 1 |
| Session management | Single | Multiple | Manual | Automatic |
| Features/window (medium) | ~8 | ~8 | ~12 | ~19 |
Table 10: Approach Comparison Across Key Dimensions
The subagent-driven development comparison is worth dwelling on. That approach achieves fresh context per task — the same core insight — but uses separate spec-compliance and quality reviewer agents after each implementation. Model-delegated execution replaces those two reviewer subagents with a single inline Opus review, which is simultaneously faster, cheaper, and higher quality, since Opus reviewing output is more capable than Sonnet acting as a reviewer. The total subagent dispatches per task drop from three to one.
Summary of measured benefits
| Benefit | Magnitude | Basis |
|---|---|---|
| API cost savings | ~24% per feature | Sonnet replacing Opus for implementation (1.67x price ratio) |
| Total token reduction | 2.4x fewer tokens consumed | Linear vs. quadratic context accumulation |
| Peak context size | 4x smaller | Orchestrator stays at ~50K vs ~200K single session |
| Features per subscription window (medium) | 2.4x more | Token savings translate directly to capacity |
| Subagent dispatches per task | 1 vs. 3 | Opus inline review replaces two separate reviewer agents |
| Inference energy reduction | ~50–60% per feature | Proportional to token reduction (prefill-dominant) |
| Review quality | Maintained or improved | Opus reviews every task output before marking complete |
Table 11: Benefits Across Dimensions
So, what?
Match the model to where its marginal capability actually matters. Keep context clean by design. Build escalation paths so that ambiguity surfaces rather than silently degrades into wrong output. These are not complicated principles, but putting them together into a coherent workflow that handles the orchestration automatically is the implementation challenge, and it is worth solving.
The numbers in this analysis — 24% API savings, 2.4x fewer tokens, 2–3x more features per subscription window — are real and compound at scale.