One line in the apology
On Oct. 25, Kimi posted an apology to subscribers. It acknowledged "rate limiting and unnecessary quota consumption" when members used K3.1 Pro, adding: "The problem is ours, and we should have fixed it sooner." Every paid tier gets a one-time reset: each active member is credited 25% of the monthly allowance, which Kimi says equals a week of use, and anyone who has used less than 25% is reset to zero.
Near the end, the apology names a technical fix. In Reuters' account, Moonshot "adjusted parameters to reduce unnecessary subagent calls and output length, referring to the delegation of tasks among AI agents and the total number of tokens generated in response to a prompt."
Changes in the same direction were already public in the Kimi Code repository before the apology went out. K3.1 Pro launched on Oct. 23. Less than two days later, pull requests merged into Kimi Code took the decision of whether to spin up helper agents away from the model and handed it to the user.
The pull requests before the apology
The first, #4382, was opened at 6:05 p.m. UTC on Oct. 24 by an account named kimi-agent-bot. It said the model was spawning large numbers of parallel subagents on documentation and research tasks, sometimes starting an agent swarm on its own, with "token/quota consumption too high." It called this a bad case that drew concentrated feedback from the "KFC side." KFC is an internal shorthand the PR does not define; given Kimi Code's model ID kimi-for-coding, it most likely refers to Kimi For Coding, the coding-subscription side. The PR only added restrictions to two tool descriptions, and its author noted that prompt-level limits "reduce how often it happens, but are not a hard cap." As of Oct. 26, it had not been merged.
The second, #4384, was opened at 7:00 p.m. UTC on Oct. 24 and merged 22 minutes later. It dealt with swarm mode. According to the PR, in version 2.3.1 the model could call the AgentSwarm tool without the user ever typing /swarm, starting "a large number of subagents at once (up to 128)." The tool was "always available to the main agent and auto-approved by default." The fix rejects the call at execution time: if the user hasn't turned swarm mode on, the tool returns an error, with no approval prompt and no subagents started.
The third, #4386, was opened at 7:44 p.m. UTC on Oct. 24 and merged at 7:26 a.m. UTC on Oct. 25. It covered ordinary subagents. Its reproduction steps: ask for a "comprehensive investigation" of a midsize repository, and the model typically calls the Agent tool within its first one to five steps, launching two to four subagents in parallel.
Kimi Code 2.3.2, which ships both changes, was released at 7:59 a.m. UTC on Oct. 25.
Prompts that encouraged delegation
The root cause listed in #4386 is plain: several parts of the prompt pushed the model to delegate, and none asked it to get the user's request first.
The PR quotes the old text. The explore subagent was described as the tool for any read-only exploration that "will clearly require more than 3 search queries," with the instruction "Prefer launching multiple explore agents concurrently." The Agent tool description pitched delegation as a way to keep intermediate file contents out of the main context. Plan mode told the model to send an explore subagent to investigate first.
The new Agent description carries a hard rule: do not launch a subagent unless the user explicitly asks for one. It defines what counts. The user names subagents, delegation or parallel agents in a message; AGENTS.md or a skill calls for delegation; or the user has turned on a multi-agent mode such as swarm or tower. A task being large, splittable, or described as "deep," "thorough" or "research" does not count.
The PR includes a test run against the real model on a midsize open-source TypeScript monorepo. Across four research and debugging requests that didn't ask for subagents, the old prompts launched them in 8 of 8 runs; the new prompts in 0 of 8. When users explicitly asked for subagents, both versions complied. The author spelled out the limits: "Because of usage quota limits, each cell has few samples and can only rule out large differences."
A lock in code, a rule in the prompt
The fixes use two different kinds of control.
Swarm, which can launch more than a hundred subagents at once, is now locked in code: unless the user has turned swarm mode on, the model's call is refused. Ordinary subagents are governed by a prompt rule. #4386 says it changes "only prompt text, no logic code," and adds no configuration switch. Users who want the old behavior have to ask in the conversation or write it into AGENTS.md or a skill. The author of #4382 noted that a hard limit would belong in the service that spawns subagents, as a global concurrency cap, and offered to do that in a separate PR.
The PRs' behavior-change tables list what users give up. In print mode (kimi -p) and in ACP clients such as Zed, the model used to be able to start a swarm itself; now there is no way to turn swarm on there at all, and the "fallback" column reads "none." The VS Code extension wasn't released this time and isn't affected yet, but its next release will carry the change, and it has no swarm switch either; the table's fallback entry for it reads "needs a decision before the extension ships." Users who relied on automatic delegation to save main context or to speed work up now have to ask for it. As of Oct. 26, the English and Chinese documentation on the main branch still said: "Sub-agents are scheduled automatically by the main Agent… They are dispatched at the right moment without the user having to specify one." The #4386 author marked the docs update as still to come.
Follow-ups on Oct. 26
Two more PRs labeled as 2.3.3 hotfixes were merged on Oct. 26. As of Oct. 26, 2.3.3 had not been released.
#4414, merged at 7:13 a.m. UTC, stops the interface from drawing a swarm panel in which "all subagents failed" when the model's swarm call was refused and no subagent had started.
#4423, merged at 9:01 a.m. UTC, adds a warning when a user turns swarm on: "Swarm is built for large parallel jobs and can use many times the tokens of a normal task. Start small, and run /swarm off when you're done." The PR says the wording is the same for everyone, whether or not they use a Kimi account plan.
A third PR from the same day, #4418, was still unmerged. It says that after users configure a cheaper secondary model for subagents, subagents could still "quietly run back on the main model," contrary to the expectation that the secondary model saves money. Separately, a developer asked in #4373 and #4392 for a command that prints account quota as JSON so editor integrations can display it. #4373, a pull request, is unmerged, and the issue #4392 is still open.
Under a subscription, who decides the spend
Kimi Code is billed as a membership subscription, paid monthly or yearly, with rate limits. At the K3.1 Pro launch, Kimi's open platform listed output at 68 yuan per million tokens. Subscribers deal in quota instead; the apology said the reset would show up on the "usage progress bar."
On a pay-as-you-go API, every extra subagent shows up as tokens on a bill, and a developer can decide whether it was worth it. Under a subscription, that trade-off was made by a line of prompt telling the model to prefer launching several agents at once. The model decided how much to spend, and the spending came out of the user's quota.
The PRs share a direction: they put the spending decision back with the person paying. Swarm now has to be switched on by the user, ordinary delegation needs an explicit request, and turning swarm on comes with a warning that usage can multiply. The 25% reset in the apology is compensation Kimi applied at a flat rate.
The structure is not unique to Kimi. In any flat-rate coding agent that lets the model decide how many helpers to start, the delegation default written into the prompt is in effect a pricing decision. In Kimi's case, #4382 traced the problem to quota consumption that drew concentrated feedback from the KFC side; #4384 and #4386, merged afterward, changed those defaults.
The apology did not say how much of the excess consumption came from subagents rather than output length or the rate limiting itself, and the PRs give no consumption figures. How much the single-agent default affects the speed and quality of finished tasks will depend on how users respond in the weeks ahead.
*Quotations from Chinese-language sources (Kimi's apology and pull-request descriptions) are DaLao's translations. The explore-agent prompt, the swarm warning, the documentation line and the Reuters passage are quoted in their original English.*