Kimi quota consumption too fast, Anthropic advocates folding sub-agents back into the main loop

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 users with quota, 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 equipped with skills actually outperformed "a group of sub-agents dividing the work" in quality, and that per-task cost and latency were often lower. Most critically, the tokens consumed by this agent were far lower than those consumed by a group of sub-agents.

The concept of sub-agents was, in fact, 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 rates, 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 models became more expensive.

Anthropic says that as models become stronger and context windows grow 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 do not need that many sub-agents at all—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 then decides what to do next.

By analogy, if the kitchen needs to make a dish, 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 would be one person for washing, one for cutting, one for cooking, and one for plating, each with their own task list. The problem is that each person's task list is handed over by the previous person—for example, the one cutting vegetables gets theirs from the one washing them.

When the dish reaches the table and turns out salty, it is hard to say which link went wrong; maybe the cook added too much salt, or maybe the vegetables were not washed clean.

The advantage of a single agent is that it does not have to explain at the start of every round to someone else "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.

Information passes between different sub-agents, and each time it is passed along, its fidelity drops by one layer. By the time it reaches later sub-agents, what they receive 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. As a result, one produced a background that looked like Super Mario, and the other produced a bird that did not look like game assets at all.

The third is personality fragmentation.

Although within the system it is multiple sub-agents communicating with one another, and these sub-agents output in wildly different styles due to different prompts, the user faces only one entry point.

Anthropic gives an example in the article: a company had more than a dozen specialized sub-agents on its client side, and as a result the company judged that these sub-agents "struggle to maintain a consistent brand voice," and users always had to wait for the slowest sub-agent to finish output before getting 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 once 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, 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 there has to be some means of splitting 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 look up this company's financial report," and even if what it finds is the wrong one, it will still keep reasoning downward based on the wrong thing, and in the end hand you a piece of nonsense that looks very serious. 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.

MetaGPT, for example, 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 the problems. From this, 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, so the main context is not 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, with multiple independent threads advancing at the same time.

Anthropic believes that sub-agents should count as a kind of "patch" for models. But these patches also have to be paid for by token.

Over the past two years, those paying have mostly been 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 single-agent form 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 burned through quota too fast, with just one or two small tasks consuming a 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.

When a requirement comes in, one person each from product, design, frontend, backend, testing, and operations shows up, and 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.

In a company, it's called organizational capability. But when it comes to models, it's called burning tokens.

As a user of the model, he can only choose the model's thinking intensity, not how many sub-agents to open. 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 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 it does.

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 a sub-agent when one Agent can solve it.

In addition, users should be able to decide the upper limit on steps, with a budget range indicated before a single task starts.

With Anthropic about to go public, reducing sub-agents and thereby lowering token consumption is also about pleasing their consumer users.