What the official notes say about subagents

Anthropic does not ship a new multi-agent API with Opus 5. The official product story is how the model behaves inside the agent frameworks people already run.

The What’s new page says that in multi-agent frameworks it “delegates to subagents more readily,” narrates progress more often, and “verifies its own work without being told to.” The prompting guide is blunt: do not use a subagent to verify the parent. That leftover instruction causes over-verification.

Where the product docs praise multi-agent, the language is coordination quality, not fan-out: “effective writer-verifier patterns and few cases of agents overwriting each other’s work.” Spawn is something to cap on cost-sensitive work.

A separate official voice is research, not the Opus 5 launch. The June 2025 engineering post (“How we built our multi-agent research system”) is the numbered 1-vs-N they did print: Opus 4 lead + Sonnet 4 subagents beat single-agent Opus 4 by 90.2% on an internal research eval, at ~15× chat tokens.

Then on August 13, 2026 — after Opus 5 shipped — the Frontier Red Team published “Patterns and problems in emerging multiagent systems.” That paper is not an Opus 5 product note. It argues true peer multiagent (no hierarchy, long-lived agents with their own goals) is still in its infancy, and it scores swarms vs independent parallels on vulns and shared-repo game development.

The numbered Opus 5 crew eval lives in the system card, not the launch blog. Section 8.11 runs two harnesses — an N-agent team (5 or 10 peers plus a lead) and async long-lived subagents — on BrowseComp and ProgramBench, and plots score against derived latency and against total tokens. Multi-agent Pareto-dominates the score–latency frontier; tokens and cost go up with agent count.

“In multi-agent frameworks, it delegates to subagents more readily. It also verifies its own work without being told to, so remove verification instructions carried over from earlier models (“include a final verification step,” “use a subagent to verify”); they cause over-verification on Claude Opus 5.”

What’s new in Claude Opus 5

“Claude Opus 5 coordinates teams of subagents well, with effective writer-verifier patterns and few cases of agents overwriting each other’s work. For cost-sensitive workloads, cap delegation.”

Prompting Claude Opus 5

“Delegate to a subagent only for large tasks that are genuinely independent and parallelizable, such as a wide multi-file investigation. Do not delegate work you can finish yourself in a handful of tool calls, and do not use subagents to verify or double-check your own work.”

Prompting Claude Opus 5 — controlling subagent spawning

“A multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval.”

How we built our multi-agent research system (June 2025)

“Agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats.”

How we built our multi-agent research system — token accounting

“True multiagent systems are still in their infancy. For some time now, agents have excelled at tool use, and insofar as they are able to treat other agents as tool invocations… they can work together efficiently. Where agents currently stumble, however, is in treating each other as more like distinct, long-lived peers, with their own goals and behaviors, and no clear hierarchy between them.”

Patterns and problems in emerging multiagent systems

“For Mythos Preview, the simple independent parallelized method produces 21 vulnerabilities over a 6.5 million token run, while the coordinating agent swarm found 266 vulnerabilities over a 27 million token run.”

Patterns and problems in emerging multiagent systems — vuln swarm

“More recent models (in particular, Opus 4.8 and Mythos Preview) have “solved” this problem, but only by hardly working together at all… It was only our most recent model, Sonnet 5, that worked on shared resources (relatively high code sharing) while also maintaining a high PR throughput.”

Patterns and problems in emerging multiagent systems — shared-repo game

“Individual agents are “low variance”… when one agent makes a bad decision, it is likely that many agents will make that same bad decision. What would have been isolated problems can quickly become systemic failures.”

Patterns and problems in emerging multiagent systems — conformity

“Multi-agent harnesses achieve the highest scores and Pareto-dominate the score-latency frontier. Every multi-agent variant matches or exceeds the best single-agent variant, with the 10-agent team reaching our highest score of 93.6%, +3.1pp over best single-agent baseline. Latency improves alongside accuracy as agents are added: relative to the single-agent 10M-token baseline, the N-agent team achieves speedups of 5.6×, 5.9× for N=5 and 10 agents respectively.”

Claude Opus 5 System Card §8.11.1 — Multi-Agent BrowseComp

“From Figure 8.11.2.A, on the full golden set, both 5-Agent Team and Async Subagents show latency improvement at the same score compared to single-agent. In particular, the 5-agent team achieves a 2.2x latency improvement over the single-agent to reach the same score of 0.6. The async-subagent curve… taking the lead to get the highest final score.”

Claude Opus 5 System Card §8.11.2 — Multi-Agent ProgramBench

“Token usage is calculated as the total number of tokens consumed across all agents on a task; cost is calculated based on token usage and per-token API pricing, assuming perfect cache hits; and latency is reported as a derived per-task latency rather than raw wall-clock time… take the maximum of all agent latencies.”

Claude Opus 5 System Card §8.11.4 — Evaluation Methodology

OpenAI splits two knobs that other labs often blur: max is more time for a single agent to think; ultra is a different kind of compute — parallel subagents.

The launch post is explicit: ultra “goes further by coordinating four agents in parallel by default, trading higher token use for stronger results and faster time-to-result.” BrowseComp and SEC-Bench Pro also show 16-agent configurations.

The API docs describe a root agent that may spawn a tree of subagents sharing the request’s model and tools. Coordination primitives are spawn, send_message, followup_task, wait_agent, interrupt_agent, and list_agents. The root synthesizes.

There is no advertised hard cap on tree depth or total agents — only max_concurrent_subagents (default 3). Automatic per-agent compaction is turned on when multi-agent is enabled.

The eval footnote matters as much as the scores: latency is taken from the root agent; output tokens and API cost include every subagent. Ultra is defined as four agents.

“ultra goes further by coordinating four agents in parallel by default, trading higher token use for stronger results and faster time-to-result on demanding tasks.”

GPT-5.6 launch post

“The charts below compare ultra’s default four-agent setup with a one-agent baseline across BrowseComp, SEC-Bench Pro, and Terminal-Bench 2.1; BrowseComp and SEC-Bench Pro also show 16-agent configurations.”

GPT-5.6 launch post — ultra charts

“Across all three evaluations, adding parallel agents shifts the score-latency frontier upward and to the left, reaching stronger results in less time.”

GPT-5.6 launch post — ultra charts

“For multi-agent, latency is derived from the root agent, while output token and API-cost totals include all tokens. Ultra is run with 4 agents.”

GPT-5.6 launch post — footnote 6

“GPT-5.6 launches with ultra mode, our highest-performance setting to accelerate your most ambitious work by coordinating multiple agents to work in parallel.”

@OpenAI on X, July 9, 2026

K3’s own tech blog is more reserved than the swarm marketing around K2.5/K2.6. The K3 post demonstrates multi-agent with a concrete case: 20+ concurrent subagents analyzing 391 gravitational-wave events.

The swarm numbers people quote — 100 then 300 sub-agents, 1,500 then 4,000 coordinated steps — come from the official K2.5 and K2.6 blogs and from @Kimi_Moonshot product posts (Kimi Work: “Native agent swarm: Up to 300 AI agents running in parallel”).

K2.5 is where the training story is named: Parallel-Agent Reinforcement Learning (PARL). The model “learns to self-direct an agent swarm of up to 100 sub-agents… without predefined roles or hand-crafted workflows.”

Same-day as K3, Kimi Code shipped nested-agent tooling. On July 27 Moonshot open-sourced AgentENV for “large-scale parallel agent workflows” that power K3’s agentic RL.

K3 did not reprint a 1-vs-N table. The official swarm eval is still the K2.5 wide-search result. K3’s contribution is the case study (20+ concurrent) and the training infra (AgentENV).

“An analysis of 391 gravitational-wave events using 20+ concurrent subagents, producing 7 scientific visualizations, 2 tables, and a literature synthesis from 10+ papers.”

Kimi K3 Tech Blog — GWTC-5 case

“Trained with Parallel-Agent Reinforcement Learning (PARL), K2.5 learns to self-direct an agent swarm of up to 100 sub-agents, executing parallel workflows across up to 1,500 coordinated steps, without predefined roles or hand-crafted workflows.”

Kimi K2.5 Tech Blog

“Agent Swarm reduces the minimum critical steps required to achieve target performance by 3×–4.5× compared to single-agent execution in wide search scenario… translating to up to 4.5× wall-clock time reduction via parallelization.”

Kimi K2.5 Tech Blog — official swarm eval

“The architecture scales horizontally to 300 sub-agents executing across 4,000 coordinated steps simultaneously, a substantial expansion from K2.5’s 100 sub-agents and 1,500 steps.”

Kimi K2.6 Tech Blog — Agent Swarms, Elevated

“Native agent swarm: Up to 300 AI agents running in parallel on your local machine.”

@Kimi_Moonshot on X — Kimi Work, June 8, 2026

The August 5 launch is a pair: Muse Code (beta terminal agent) and Muse Spark 1.2 (coding-focused update of Spark 1.1). Meta says they “co-trained Muse Spark 1.2 with Muse Code,” including “recipe optimizations for goals, compaction, and subagents.”

Muse Code “operates with a simple agent loop plus a set of async background agents.” Those background agents “remain active throughout each session, rather than being spawned for individual tasks,” so they do not re-gather context. They “carry out next steps and choose when to communicate back to the main agent.”

A second, hotter path is fan-out. Zuckerberg on X: when a job is big enough, Muse Code “fans out to separate sub-agents working in parallel in isolated worktrees. Your working copy is never touched. In testing we had it build six features for a game simultaneously with no collisions.”

The 1.1 notes already trained the model to play both sides: “As the main agent, it can gather context, make a plan, and delegate execution across parallel subagents. As a subagent, it adheres to its job… and knows when to escalate back to the main agent.”

The April Spark launch framed multi-agent as a latency trick: scale parallel agents instead of making one agent think longer — “superior performance with comparable latency.” 1.2 inherits that thesis and binds it to a shipping harness.

“It can coordinate multiple persistent subagents for each task, solving difficult problems faster, more accurately, and with less intervention.”

Introducing Muse Code and Muse Spark 1.2

“Muse Code operates with a simple agent loop plus a set of async background agents to enhance the main agent's capability. These specialized background agents remain active throughout each session, rather than being spawned for individual tasks, helping avoid redundant information gathering.”

Introducing Muse Code and Muse Spark 1.2 — Async Background Agents

“We co-trained Muse Spark 1.2 with Muse Code to ensure the model exhibits its best performance and coding usability when paired together. The training included rejection sampled harness trajectories and recipe optimizations for goals, compaction, and subagents.”

Introducing Muse Code and Muse Spark 1.2 — Co-Training

“When a job is big enough, it fans out to separate sub-agents working in parallel in isolated worktrees. Your working copy is never touched. In testing we had it build six features for a game simultaneously with no collisions.”

@finkd on X, August 5, 2026

“As the main agent, it can gather context, make a plan, and delegate execution across parallel subagents. As a subagent, it adheres to its job, understands available tools, and knows when to escalate back to the main agent.”

Introducing Muse Spark 1.1

“To spend more test-time reasoning without drastically increasing latency, we can scale the number of parallel agents that collaborate to solve hard problems… scaling Muse Spark with multi-agent thinking enables superior performance with comparable latency.”

@AIatMeta on X, April 8, 2026 — original Spark launch