Author’s note: Using DeepSeek’s super-agent design as a starting point, this article breaks down how to assign models to routers and workers in a multi-agent system—and how cache-read tokens affect architecture costs.
When building a multi-agent coding system, most people give the strongest model to the “commander” and cheaper models to the agents doing the work. The DeepSeek Harness team’s super-agent design, published in November 2026, takes the opposite approach: a cheap model for the router, a strong model for the workers. A lightweight model handles conversation and task assignment, while the strongest model does the actual coding.
This isn’t a news recap. We’ll turn the architecture into practical model-selection guidance: what capabilities routers and workers need, how to estimate cache-read tokens, and when to choose a cheaper model. DeepSeek itself calls the test results cited here “indicative,” and we’ll explain their limitations.
What you’ll get: By the end, you’ll be able to create a role-based model allocation plan for your own multi-agent system and use cache-read volume to estimate its order-of-magnitude cost.
Key Principles for Multi-Agent Model Allocation
DeepSeek’s design has two layers. The router is a persistent session that communicates with people, assigns tasks, and tracks relationships between them. Each worker takes on one task at a time, operates in its own clean context, never talks directly to people, and reports status only to the router. With those roles in mind, the table below sets a starting point for model allocation.
| Role | Core responsibilities | Writes code? | Recommended model tier | Why |
|---|---|---|---|---|
| router | Communicate, assign tasks, and track task relationships | No; shell access isn’t necessary | Lightweight, inexpensive, and fast | The work is simple but frequent, so latency and cost per call matter more |
| worker | Take on a single task and complete the coding | Yes | The strongest coding model currently available | Code quality directly determines the quality of the deliverable |
| Trigger filtering layer | Filter out noise from group chats and CI notifications | No | Use ordinary code for the first pass and a small model for the second | Most events don’t need to reach a model |
Why Multi-Agent Model Allocation Should Be “Inverted”
DeepSeek believes the bottleneck in AI-assisted coding has shifted from model capabilities to human attention. A person can typically track only 3 to 5 active agent sessions at once. Beyond that, it becomes hard to tell which session is waiting for approval, which is stuck, and which two are quietly modifying the same PR. So the router’s value isn’t in being “smart”—it’s in reliably assigning work and keeping track of it. It doesn’t break tasks down; it only assigns and tracks them. That’s different from the common pattern where a primary agent breaks a task into steps.
Since the router doesn’t need deep reasoning and doesn’t write code, using the most expensive model for it is a waste. Workers are where the code actually gets produced, and code quality determines whether the work succeeds. That’s where the budget for a stronger model should go. This is the “model selection inversion”: the closer a role is to the user, the lighter the model; the closer it is to the code, the more powerful the model.
What capabilities do the router and workers need?
Breaking down each role into specific capabilities makes it easier to choose the right models. You can use the checklist below to evaluate candidates.
| Capability | Router requirements | Worker requirements | Selection tips |
|---|---|---|---|
| Instruction following and classification | High; must reliably determine where tasks belong | Medium | Prioritize dispatch accuracy when testing the router |
| Long context and traceability | Medium; expands context gradually using ID summaries | High; needs to read large amounts of code | Check the worker’s context window and code retrieval capabilities |
| Code generation quality | Not needed | Highest priority | Don’t skimp on the worker budget |
| Response latency | High priority; makes frequent decisions | Medium; individual tasks can take longer | Choose a fast, Flash-class model for the router |
| Price sensitivity | Very high; cache read volume is enormous | Medium | The router’s unit price affects the total bill |
| Tool use | Limited; shell access isn’t necessary | Extensive; needs to run code and tests | Use permission boundaries to constrain each role |
There’s another easily overlooked requirement for the router: its setup must prevent it from doing the work itself. DeepSeek deliberately gave the router no shell access to eliminate that possibility. So when choosing a router model, don’t look for one that “can do everything.” Instead, accept that it “only knows how to delegate.”
Cache Read Token Costs in Multi-Agent Model Allocation
A cheap router isn’t enough. The biggest cost in this architecture comes from cache read tokens. The router runs as a long-lived session, repeatedly reading cached context, while multiple workers run in parallel and each read large amounts of context. DeepSeek’s test data makes the issue clear.
| Test metric | Value | Details |
|---|---|---|
| Messages per run | About 300 | About 20 were actual work requests |
| Average super-agent completion time | 12.4 minutes | 15.7 minutes at the slow end |
| Single-session baseline, slow-end time | 29.5 minutes | Used for comparison |
| Router decision load | Increased from about 1 to about 40 per minute | Time per decision fell from 6.4 to 1.6 seconds |
| Cache read tokens | 23.2 million | With pass-through optimization enabled |
| Cache reads without optimization | 31.8 million | Workers didn’t subscribe directly to the thread |
| Cache cost | About $7 | Based on DeepSeek’s own off-peak Flash-tier pricing |
How to Estimate Multi-Agent Model Allocation Costs from Cache Reads
You can break the cost of a run into three parts: cache read tokens multiplied by the cache read price, plus uncached input tokens multiplied by the input price, plus output tokens multiplied by the output price. In a router-worker architecture, the first part often accounts for the vast majority of the cost, so the cache read price is the pricing metric to watch most closely when choosing a model.
Working backward from the reported figures, about $7 for 23.2 million cache read tokens comes to roughly $0.30 per million tokens. That’s only an approximation based on the reported numbers, not an official quote. Check the model provider’s current pricing for actual rates. With that ballpark figure, you can plug in the cache read prices of candidate models and quickly see how much more the same workload would cost with a pricier model.
The pass-through optimization is also worth noting. When workers subscribe to the thread, new events go directly to them instead of being forwarded through the router. Cache reads fell from 31.8 million to 23.2 million, a reduction of about 27%. In other words, architectural optimization can lower the bill directly, just like switching to a cheaper model.
Three Caveats About the Original Data
- The coding step was simulated: In the test, “writing code” was replaced by a tool that only consumed time. The test measured scheduling behavior, not code quality, so it can’t establish which model works best for workers.
- The figures are only indicative: DeepSeek explicitly says these numbers are indicative, not a rigorous benchmark.
- The comparison with Sonnet-tier pricing is inconsistent: The report’s summary estimates about $4.64 at Sonnet-tier pricing, while the main text says the same usage would be “significantly more expensive” at a higher price tier. The two claims contradict each other. We wouldn’t recommend citing that specific comparison without checking DeepSeek’s original article first.
Quick Start: Assigning Models in a Multi-Agent System
You can put the approach above into practice by following these steps. There’s no code here; all configuration options are described inline so you can map them to your own framework.
- Define roles first, then choose models: List every role in your system that calls a model. At a minimum, distinguish between the router, worker, and trigger-filtering roles. For each one, note whether it writes code and needs tools.
- Make model names configurable: Set separate parameters such as
router_model,worker_model, andfilter_modelfor each role. Don’t hard-code model names in your application code. - Enforce delegation through system design: Remove execution tools such as shell access from the router. In DeepSeek’s experiment, a single-session agent never delegated across five runs with a neutral prompt, and the slowest run took nearly half an hour. Even when the prompt explicitly required delegation, the agent decided the task was too small and handled it itself in one of five runs.
- Filter first: Use ordinary code to filter out noisy trigger events by source and allowlist. Only pass the remaining events to the model for evaluation against team rules.
- Record cache reads: For each run, record cached reads, uncached input, and output tokens. Use the formula above to calculate the cost per run.
- Compare models: Keep the task set unchanged and replace only
router_model. Track changes in routing accuracy, latency, and cost before deciding whether to switch to a lower-tier model.
In steps 2 and 6, how you connect to the models can directly affect how quickly you can experiment. If the router and worker come from different providers, maintaining separate keys and SDK configurations means changing a lot of settings each time you switch. With a unified interface platform like APIYI at apiyi.com, you can use the same API key and OpenAI-compatible request format, changing only the model parameter to assign models from different providers to the router and worker. That makes comparison experiments much less costly.
🚀 Quick-start tip: When building a prototype, try configuring the router and worker model parameters with the same key on APIYI at apiyi.com, then run the same batch of tasks and record token usage. Check the platform’s current model list for availability, including DeepSeek’s Flash-tier models.
When to Choose a Low-Cost Model for a Multi-Agent Role
Low-cost models aren’t right for every task. The table below can help you decide which roles are good candidates for a cheaper model.
| Scenario | Recommendation | Why | Access |
|---|---|---|---|
| The role only dispatches tasks, tracks progress, or checks cached context | Choose a fast, low-cost model | The tasks are simple, so price and latency drive the experience | APIYI apiyi.com or the provider’s official API |
| The role generates and modifies code | Choose a more capable model | Code quality determines the quality of the deliverable | APIYI apiyi.com or the provider’s official API |
| Cache reads reach tens of millions and runs repeat daily | Prioritize a lower cache-read price | Cache costs grow linearly with the number of runs | Calculate costs using the provider’s price list |
| Occasional, lightweight one-off tasks | Use pay-as-you-go pricing | Usage is too low to justify the added architectural complexity | Any pay-as-you-go provider |
| High-frequency, token-intensive automation | Evaluate monthly plans or higher-limit options | The marginal cost of each run no longer appears on the bill | Depends on the subscription terms |
The last row has a useful point of reference: reports from the same period put Claude Code Pass at $9.99 per month, with roughly 2–5 times the rate limits for open models such as Kimi K3.1 Pro, GLM 5.3, and DeepSeek V4.1 Flash. It also has usage caps across three windows: five hours, one week, and one month. The reports also suggest that for routing decisions or checking cached context, a fast, inexpensive model is technically better suited—not just cheaper. Plans like this do lock you into the included models, though, so if a worker depends on a model outside the plan, you’ll still need another way to access it.
Risks and Limits of Multi-Agent Model Allocation
Model allocation addresses cost and division of labor, but it doesn’t solve the underlying challenges of the architecture. DeepSeek acknowledges two unresolved problems. The first is long-term memory: after the system has been running for months, it’s still difficult to retain relevant history without overwhelming the context window. The second is prompt injection: any agent that reads external events, such as group chats or PR comments, can potentially be manipulated. Because the router and workers are connected through a shared cloud loop, a compromised event source could theoretically spread instructions to every machine the system touches.
This has direct implications for model allocation. Using a cheaper model for the router doesn’t mean you can relax its safeguards—it’s the first component to encounter external events. In DeepSeek’s internal deployment, proactive behaviors initially ran in a logging mode that recorded “what would have happened” rather than executing actions immediately. Take the “silently reproduce and fix” policy: when someone reports a bug, an agent tries to reproduce it in the background. Only after confirming and fixing it does the agent submit a PR while the conversation is still ongoing. If it can’t reproduce the bug, it sends nothing. When rolling out a new system, it’s safer to observe the logs first and grant more autonomy gradually.
Also, the DSH Super Agent prototype is explicitly labeled on GitHub as research code, not an official product. It’s fine to take inspiration from its design, but deploying it directly to production isn’t recommended.
Frequently Asked Questions
Q1: What is “model selection inversion” in a multi-agent system?
It means using a lightweight, inexpensive model for the router and the strongest model for the worker. The router handles conversation, delegation, and tracking, but doesn’t write code. The worker does the actual coding, so the budget for a stronger model should go to the worker rather than the “commander.”
Q2: How does the router-worker architecture differ from having a lead agent break down tasks?
In the lead-agent pattern, the lead agent breaks tasks down into steps, which requires stronger reasoning capabilities. DeepSeek’s router doesn’t break tasks down at all—it only assigns and tracks them, so it can use a lighter model. The trade-off is that the worker must be able to complete the entire task independently.
Q3: When was this design made public? Can I use DSH Super Agent directly?
The related report was published on November 3, 2026. DSH Super Agent is a research prototype released on GitHub alongside the design article. The team has made it clear that it isn’t a supported product and is intended only to help people understand the architecture.
Q4: Can you use prompts alone to teach a single agent to delegate?
DeepSeek’s tests suggest it’s unreliable: a neutral prompt resulted in zero delegations across five runs, and even a prompt emphasizing delegation had one run with no delegation. Reliable delegation requires structural separation—for example, splitting sessions and removing execution tools—not just writing longer prompts.
Q5: How can I easily configure models from different providers for the router and worker in the same system?
The key is to make model names configurable by role and use a unified way to access them:
1. Register at APIYI apiyi.com and get an API key
2. Set the `model` parameter separately for the router and worker in your system configuration
3. Keep the request format unchanged and swap model names to run comparison tests
This way, you don’t need to maintain a separate SDK configuration for each provider. Check the platform’s current list for available models.
Q6: Can I use the cost data from the original article directly for budgeting?
It’s not recommended. The coding step was simulated, so the data is only indicative, and the article’s price comparisons with the Sonnet tier are inconsistent. A better approach is to measure cache reads using your own task set, then multiply by current unit prices. On APIYI apiyi.com, you can keep the tasks the same and run each model separately to get data that fits your use case.
Q7: What are the known limitations of this architecture?
There are three main limitations: memory degradation over long runs; the risk of prompt injection when reading external events; and a high volume of cache-read tokens, which can significantly increase costs with expensive models. There’s also no performance data identifying the specific model used for the router, so you’ll need to test that yourself.
Key Takeaways for Multi-Agent Model Allocation
- Flip the usual model selection: Use a lightweight, inexpensive model for the router and a stronger model for workers that write code.
- Attention is the bottleneck: People can usually keep track of only three to five sessions at a time. The router brings communication together.
- Enforce delegation through structure: Removing the router’s execution tools is far more reliable than changing its prompt.
- Cache reads drive costs: One test logged 23.2 million cached tokens read, making the per-token price critical.
- Architecture changes save money too: Pass-through routing reduced cache reads by about 27%.
- Treat the data cautiously: Coding was simulated, so results are indicative only; pricing comparisons need verification.
- Experiment through a unified interface: With APIYI at apiyi.com, you can compare allocation strategies by changing only the
modelparameter.
Summary
The core idea is to use an inexpensive model for the router and a stronger model for workers. Here are the main principles:
- Match the model to the role: Use a fast, low-cost model for roles that only assign and track work, and a stronger model for coding.
- Account for cache costs: Cache-read tokens are the main expense in this architecture, so compare cache-read pricing first.
- Decide based on your own tests: The original data is useful for direction, but you should measure cost and effectiveness on your own task set.
Start with a small task set and build a router-worker prototype. Make model names configurable by role, then gradually swap out the router model and observe changes in assignment accuracy and cost. APIYI at apiyi.com provides unified access to models from multiple providers with one key, making it easier to run these comparisons and base your selection on your own data.
📚 References
- DeepSeek’s Super Agent Harness: Fixing the Attention Bottleneck in AI Coding: An overview of DeepSeek’s super agent design
- Link:
mindstudio.ai/blog/deepseek-super-agent-harness-design -
Details: Covers the router-worker architecture, delegation experiments, cached token data, and open questions
-
Claude Code Pass Pricing: What’s in the $9.99/Month Plan: A look at the high-limit monthly subscription
- Link:
mindstudio.ai/blog/claude-code-pass-pricing - Details: Discusses the trade-offs between usage-based pricing and monthly subscriptions for multi-agent, token-intensive workflows
Author: APIYI Technical Team
Technical discussions: Contact us through the APIYI homepage at apiyi.com to discuss model allocation for multi-agent systems. For more integration resources, visit the documentation center at docs.apiyi.com.
