Dynamic Workflows are not rate-limit-aware — heavy-read fan-outs burst ITPM, 429s drop agents mid-run and waste session tokens

Summary

Dynamic Workflows fan out N concurrent subagents with a user-set concurrency cap,
but the runtime has no awareness of the account's token-rate limits (input/output
tokens-per-minute). Workflows whose agents do heavy file reads spike input tokens
in a few seconds and trip a 429. On 429, affected agent() calls fail terminally
after retries and the workflow proceeds with the survivors — so the user loses the
dropped agents' work AND the tokens already spent, then must restart the whole run.

Environment

• Claude Code (CLI), Windows 11
• Feature: Dynamic Workflows (Workflow tool), background run
• Model: Opus 4.8 (1M context)

What happens

1. Workflow fans out ~40 extract agents, cap 15, each Read-ing many (often large) files.
2. Within ~10s the parallel reads exceed input-tokens-per-minute → 429.
3. The first wave of agents fails terminally; the runtime "moves on without them."
4. The result looks complete but silently dropped a whole wave of agents.
5. Restart at lower concurrency; often 429s again. Each failed attempt burns ~7–10%

of Session Usage with nothing to show.

Impact

Users must hand-guess a "max concurrency" number with no feedback, and every wrong
guess wastes real session budget on a run that produces nothing usable. The concurrency
knob is a crude proxy for the real constraint (input tokens/minute), so it is mostly
trial-and-error: 15 → 10 → 5, waiting ~15 min between attempts to clear the limit.

Expected / asks

1. Rate-limit-aware admission control: read the anthropic-ratelimit-* response

headers (input-tokens-remaining/reset, retry-after) and pace the fan-out to stay
under ITPM — instead of relying on a user-guessed concurrency cap.

1. Adaptive backoff on 429: globally throttle in-flight agents, honor retry-after,

and requeue affected agents rather than failing them terminally.

1. Never silently drop: if agents are lost to rate limits, fail loud / surface it;

don't return a result that looks complete.

1. Budget by estimated input tokens, not agent count: 10 light agents ≠ 10 agents

each reading a dozen large files.

1. Don't bill dropped work as if it succeeded: mid-run rate-limited agents still

consume Session Usage; a forced restart re-spends it.

Current workaround

Manually drop concurrency (15 → 10 → 5), tighten each agent to grep-then-targeted-read
instead of whole-file reads, and wait ~15 min between attempts. Slow, lossy, and still
trial-and-error.