Anthropic proposes folding sub-agents back into the main loop, responding to the controversy over Kimi K3.1 Pro quota consumption
Anthropic published the article "Building Agents: When to Fold Sub-Agents Back into the Main Loop," stating that a single agent with skills often outperforms multiple sub-agents dividing labor in quality, cost, and latency, with far lower token consumption than the latter, and open-sourced the single-agent-loop-kit tool. The article notes that multi-agent systems consume about 15 times the tokens of ordinary conversations, and converting sub-agents into Skills can cut over 80% of system prompts. After Moonshot AI's K3.1 Pro launched on October 24, multiple users reported excessively fast quota consumption, and the company said in the early hours of October 26 that it would reduce unnecessary sub-agent calls and output length.
Why read this
AI score 60
The article places Anthropic's analysis of sub-agent costs alongside Moonshot AI's K3.1 Pro quota controversy, so readers can understand the token costs of multi-agent architectures.
Topics
Body · AI translation
After the release of K3.1 Pro, as many users reported that their quotas were burning up too fast, Moonshot AI urgently issued an announcement, saying "the problem is on us, and we should have fixed it earlier." While compensating quotas, Moonshot AI also said it would "reduce unnecessary sub-agent calls and output length."
Just two days before the model went live, Anthropic published an article titled "Building agents: When to fold subagents into your main agent loop," and what it discussed happened to be exactly this matter of sub-agents.
Anthropic's conclusion is that, by comparing Claude deployments across multiple enterprises, they found that a single agent with skills actually beats "a group of sub-agents dividing the work" in quality, and that per-task cost and latency are often lower. Most critically, the tokens consumed by this agent are far lower than those of a group of sub-agents.
The concept of sub-agents was actually a "patch" that vendors applied during the period when model capabilities were insufficient, in order to get models to complete more tasks.
In terms of task completion rate, multiple sub-agents were indeed far stronger than the single agents of that time. As a trade-off, tokens burned much more heavily, and the model became more expensive.
Anthropic says that as models become stronger and context grows longer, this "patch" no longer improves capability and instead becomes a "burden."
What Anthropic's article says
Anthropic believes that for the vast majority of tasks, you simply don't need that many sub-agents—you only need a single agent, a single model, a single conversation record, and one loop.
The model works repeatedly within one loop; in each round it can issue a batch of tool calls at the same time, and the results go directly back into this model's hands, which decides what to do next.
As an analogy, the kitchen needs to make a dish, so it has to start with prepping the ingredients, then washing them, cutting them, putting them in the pan, and finally plating and serving.
Under the old division of labor, there was one person for washing, one for cutting, one for cooking, and one for plating, and each person had a task list in hand. The problem is that each person's task list was given by the previous person—for example, the one cutting vegetables got theirs from the one washing them.
When the dish reaches the table and turns out salty, it's hard to say which link went wrong; maybe the cook put in too much salt, or maybe the vegetables weren't washed clean.
The advantage of a single agent is that it doesn't have to start every round by explaining to someone "what flavor I want." The dish is made by itself, and it has tasted the saltiness itself.
The article argues that there are three reasons sub-agents are bad.
The first is token compounding.
Every additional sub-agent in a task adds another layer of branching, and the cost increases a bit more. The token consumption of a multi-agent system is about 15 times that of an ordinary conversation.
The key point is that these 15 times are not spent on "thinking" but on "remembering."
Each sub-agent has to re-establish its own identity, rules, tool list, and relevant context, and after finishing, compress everything into a summary to hand back. This forces the main agent to read the same material many times over.
The second is information decay.
Each time information is passed between different sub-agents, its fidelity drops by one layer. By the time it reaches a later sub-agent, what it receives may no longer be the same thing as the original requirement.
Cognition, in its 2025 article "Don't Build Multi-Agents," described a scenario: two sub-agents were each assigned to build a Flappy Bird clone, one doing the background and one doing the bird. In the end, one produced a background that looked like Super Mario, and the other produced a bird that didn't look like game asset material at all.
The third is personality fragmentation.
Although within the system it is multiple sub-agents communicating with one another, and these sub-agents, due to different prompts, output in utterly different styles, the user faces only a single entry point.
Anthropic gives an example in the article, saying that one company's client had more than a dozen specialized sub-agents, and as a result the company judged these sub-agents as "very difficult to maintain a consistent brand voice," and users always had to wait for the slowest sub-agent to finish outputting before they could get a reply.
But there are two sides to every story: Anthropic does not believe sub-agents should simply be abolished, but rather that they should be loaded on demand as Skills.
Each sub-agent carries various kinds of knowledge with it, such as the knife skills for cutting vegetables or the heat control for cooking. Whenever needed, these Skills are taken out, and at the next stage they are put back.
The effect of this approach is measurable.
Anthropic mentions in the article that, combined with supporting tools, this method of turning sub-agents into Skills can cut more than 80% of system prompts.
This instantly makes prompts that were originally so bloated they affected judgment clean and concise, thereby freeing up a large amount of context space for the task itself.
Do we really still need sub-agents?
Sub-agents were, from the very beginning of their birth, an engineering compromise.
At the time, Karpathy, who was still at OpenAI, once posted a tweet roughly saying that GPT doesn't know it has a context limit, and when you give it a task, it easily fills up the context, which then causes the task to fail.
So you have to use some means to split the task so the model can complete it step by step.
At the end of March 2023, AutoGPT and BabyAGI ran two experimental projects. Their core was to use an Agent to break a big goal into several todo lists, assign work to itself, and execute it itself.
This batch of projects proved one thing: let the model decide the next step itself, and the loop can run. But it also exposed one thing: if there is no reliable verification step in this loop, errors will amplify themselves within the loop.
An Agent says "I'm going to check this company's financial report," and even if it finds the wrong one, it will still keep reasoning based on the wrong thing, and in the end give you a very serious-looking piece of nonsense. After that comes endless spinning, with error piled on error.
From the second half of 2023 to 2024, the industry's solution was to make the division of labor resemble a real company.
For example, MetaGPT divided the model into four roles: product manager, architect, engineer, and tester.
You throw in one line, "make a Snake game with a leaderboard," and it will proceed layer by layer according to the roles. First the "product manager" writes the requirements document, then the "architect" translates the document into system design and interfaces, next the "engineer" writes code according to the interfaces, and finally "testing" picks out problems. In this way a complete program is generated.
At the time, everyone's thinking was quite simple: if one model easily goes off track, then let several models look out for one another. This was also the prototype of the sub-agent system.
Put plainly, a sub-agent is essentially "using architecture to simulate a wider, more stable machine with more memory."
Besides the limited context window, Anthropic also wrote in the article that the model's reliability is limited, and the longer the chain, the easier it is to collapse. In addition, the model can only work single-threaded and cannot think at the same time.
Anthropic said that their motivation for doing sub-agents in 2024 was to solve these three things: context isolation, to keep the main context from being polluted by massive intermediate outputs, effectively expanding the context window; giving different tools to different tasks, to prevent a collapse somewhere in the chain from directly affecting the entire task; and parallelism, to advance multiple independent threads at the same time.
Anthropic believes that sub-agents should count as a kind of "patch" for models. However, these patches also have to be paid for by token.
Over the past two years, most of those paying were developers and enterprises billed by API, with costs clearly priced and accountable. If you spend one more dime on tokens, your bill goes up by one dime, crystal clear.
Monthly quotas are a black box. Users only know "how much is left this month," not "how much quota these sub-agents actually consumed in this round of conversation."
Subscribers judge quota by "how many things I did," but the system calculates by "how many times I called the model, how many branches I opened, how many times I read files."
Therefore Anthropic said that as model performance and compute gradually improve, these "patches" only play a role in extremely complex tasks; for the vast majority of tasks, sub-agents only burn more tokens.
So Anthropic reached a conclusion: the benefits brought by sub-agents no longer outweigh their own costs.
Anthropic even open-sourced a tool called single-agent-loop-kit for this purpose, specifically to let the model execute tasks only in the form of a single Agent and no longer call sub-agents.
This bill for K3.1 Pro
Moonshot AI was precisely the one that suffered from opening too many sub-agents.
On October 24, Moonshot AI's K3.1 Pro launched, with strong performance. On Terminal-Bench 4.0 it scored 65.7%, surpassing GPT-6 Astra's 58.2%, and compared with Claude Opus 5.5's 66.4%, it was only 0.7% behind.
But multiple users in the community reported that the model's quota burned too fast, and just one or two small tasks could consume the 5-hour quota.
In the early hours of October 26, Moonshot AI officially said it would reduce unnecessary sub-agent calls and output length.
Anyone who has worked at an internet company will find this very familiar.
A requirement comes in, and product, design, frontend, backend, testing, and operations each send one person; everyone has to leave a comment on the document, otherwise it looks like they didn't participate. In the end you find that work one person could have finished in half a day took more than half a year from requirement to scheduling to testing and launch.
Although in a company it is called organizational capability, when it comes to models, it is called burning tokens.
As a user of the model, he can only choose the model's thinking intensity, not how many sub-agents are opened. He only wants to pay for completing the task, not for so many sub-agents to "align, hold meetings, and make PPTs."
And users don't even have a chance to call stop. There is a concept here called front-loaded failure cost.
A normal transaction is "the work is done, then the money is spent." With sub-agents, quota burns as soon as they are opened, even if the role of that sub-agent is almost negligible.
To be fair, this is not an illness unique to K3.1 Pro.
Claude users have also complained that with the $20 subscription tier, one prompt uses up the 5-hour quota; Opus 5.5 processing an existing codebase triggers the limit in about 30 minutes. All because Claude opened too many sub-agents.
Anthropic believes this is a "structural contradiction" of the "long-horizon Agent" category.
You give it a task, and it has to look up information, read files, write, revise, and verify by itself again. It has to run dozens of steps, and each step has to reread the context; running for half an hour is common.
The stronger the model, the longer it searches, the more tools it calls, and the more rounds of self-checking.
Anthropic's solution is to determine from the product side, on the user's behalf, "which sub-agent calls are unnecessary," thereby reducing sub-agents and resolutely not opening sub-agents when one Agent can solve it.
In addition, users should be able to decide the upper limit of steps, with a budget range prompted before a single task starts.
With Anthropic about to go public, reducing sub-agents and thereby lowering token consumption is also meant to please their consumer users.
This article comes from the WeChat public account "Letter AI", author: Miao Zheng, published by 36Kr with authorization.