[MODEL] Orchestrating session ignored the project's written agent and batch limits, then retried its own load-caused timeouts for 2 hours: ~12% of a weekly Max allowance spent, nothing merged

Summary

An Opus session coordinating other agents made a chain of errors over about six hours on one workstation:

1. It broke the project's written concurrency limit. The project's instructions, which the session loads at start,

allow at most 6 implementer agents at once. It ran about 16.

1. It did not recognize its own load as the cause of the failures. With 16 agents building and testing at once,

every agent's test run hit the same timeout before running a single test. For about two hours the session kept
waiting and re-running. It never diagnosed a failure that was identical across every agent and began right after it
added the load.

1. It repeated the failure. After it finally stopped all agents, it started another 8-agent batch on code that did

not yet contain the fix for that timeout, and the same failure recurred.

1. It broke the project's written batch limit. The instructions say to merge 4 to 6 finished branches at a time. It

merged about 15 at once. The merge ran over 3 hours and failed its tests.

1. It ignored its own cost. It ran a check-in every 30 minutes, and each one re-read its very long context (about

$24 by itself).

1. It claimed something it had not checked. When the user asked it to report the problem, it said a /feedback

report was "already filled in". There was none.

Result: about 12% of a fresh weekly Max 20x allowance and over half of a 5-hour session window spent. That was
about $317 at list-price token rates, by Claude Code's own telemetry, and nothing was merged.

Related: #97129 (parallel subagents exhausting the usage limit), #94770 (budget-aware subagent orchestration).

What the user asked

The user set a budget and made a conditional request:

• "You have 100% of the weekly quota available to you. You will need to not exceed the session quota limits, however"
• "run more work in parallel while the session allows"

Neither asked the session to exceed the project's written limits. Neither asked it to keep adding agents while the ones
already running were failing. The project's standing instructions, loaded at every session start, set the limits it
broke: at most 6 implementer agents at once, and 4 to 6 branches per merge.

Setup (only what is needed to follow the report)

• Machine: one Windows 11 workstation. Claude Code ran natively on Windows. WSL2 was used only by one of the

project's test steps.

• The coordinating session (Opus, interactive) does no coding itself. It starts subagents and multi-agent workflows

(the Agent and Workflow tools).

• Each subagent fixes one problem in its own git worktree, then runs the project's build-and-test script. The script

is CPU-heavy: tens of minutes on an idle machine, with an early step that has a fixed 15-minute timeout.

• Merging: finished branches are merged into main in batches by another agent.

What Claude did (hours:minutes from session start)

• 0:00. A batch of implementer subagents is already running.
• Early. Told "run more work in parallel while the session allows", the session starts a second batch plus four

single agents. That makes about 16 heavy build-and-test runs on one machine, against a written limit of 6 agents.

• 0:15 to 2:15. Every run overruns the 15-minute timeout and fails before running a test. The agents re-run, and the

session keeps waiting and dispatching. It stops all agents at about 2:15.

• After that. It starts another 8-agent batch from code without the timeout fix, and the failure recurs.
• Meanwhile. About 15 finished branches go into one merge, against a written limit of 4 to 6. It runs over 3 hours

across three agents and fails. Nothing reaches main.

Weekly meter (claude.ai usage page): 0% at 0:02, 2% at 0:15, 4% at 0:37, 6% at 1:48, 7% at 2:18, 8% at 2:59, 9% at
3:36, 11% at 4:05, and about 12% by about 6:00. The 5-hour session window stood at 51% at 4:36.

Spend from Claude Code's OpenTelemetry api_request events (cost_usd; list-price equivalents, not charges):

| Hour | USD equivalent |
|---|---|
| 1 | 91.37 |
| 2 | 45.20 |
| 3 | 57.53 |
| 4 | 52.15 |
| 5 | 66.17 |
| Total, first ~5 hours | 317.46 |

By session: the coordinating session and its subagents $214.93; a headless batch session $78.06; the merge session
$24.47. About $103 of hours 2 and 3 went to re-running test runs that could not pass under the load the session had
added.

Expected behavior

• Stay within the project's written limits (6 agents at once, 4 to 6 branches per merge) unless the user explicitly

lifts them.

• Before adding agents, check that the ones already running are succeeding and that the machine has capacity.
• When every agent fails the same way right after load was added, suspect the load first: stop adding it and diagnose,

instead of retrying.

• Don't relaunch a configuration that just failed until its cause is fixed.
• Don't tell the user something exists without checking.

The /feedback claim (a model error, plus a product bug)

The session had called the SendFeedback tool, which returned:

Feedback draft queued locally (max 10 kept). The user can review and send it with /feedback; nothing is sent without their approval. Do not announce this or ask the user about it.

About 75 minutes later it told the user: "type /feedback in this terminal. A report is already filled in there". The
user ran /feedback, which showed no draft.

1. The model stated the draft was there without checking, although the tool had told it not to announce the draft at

all.

1. The product: a draft that SendFeedback reported as queued was not offered by /feedback 75 minutes later, in the

same session.

Impact

High. About 12% of a weekly Max 20x allowance, over half of a 5-hour window and about $317 list-price equivalent, with
no merged output, plus a day of the user's time spent supervising.

Can you reproduce this?

Haven't tried to reproduce.

Suggestions

1. Let the model read the plan usage meter. A tool or status field with the session and weekly percentages would

let a coordinating session limit itself. This one had to read the claude.ai usage page through a browser extension.
See also #101232.

1. Check outcomes before fanning out. Guidance or a mechanism for subagent and Workflow dispatch: confirm that the

running agents are succeeding, and that the machine has capacity, before starting more.

1. Fix SendFeedback drafts going missing. Make drafts reliably reach /feedback, or have the tool result tell the

model plainly that the draft may not be visible.

Claude model

Opus (Opus 5.5)

Claude Code version

2.1.296 (Claude Code)

Platform

Claude Max 20x subscription (claude.ai login). Claude Code running natively on Windows 11.

Permission mode

bypassPermissions