Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add wan-huiyan/agent-traffic-control --skill opus-ratelimit-fanout-retry-on-sonnet-throttled-wavesgit clone --depth 1 https://github.com/wan-huiyan/agent-traffic-controlWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/wan-huiyan/agent-traffic-control/opus-ratelimit-fanout-retry-on-sonnet-throttled-waves)<a href="https://agentmods.dev/skills/wan-huiyan/agent-traffic-control/opus-ratelimit-fanout-retry-on-sonnet-throttled-waves"><img src="https://agentmods.dev/badge/skills/wan-huiyan/agent-traffic-control/opus-ratelimit-fanout-retry-on-sonnet-throttled-waves/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/wan-huiyan/agent-traffic-control/opus-ratelimit-fanout-retry-on-sonnet-throttled-waves"><img src="https://agentmods.dev/badge/skills/wan-huiyan/agent-traffic-control/opus-ratelimit-fanout-retry-on-sonnet-throttled-waves.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00207 | $0.01386 |
| Opus 5 | $0.00103 | $0.00693 |
| Sonnet 5 | $0.00041 | $0.00277 |
| Haiku 4.5 | $0.00021 | $0.00139 |
Grade A, and why
opus-ratelimit-fanout-retry-on-sonnet-throttled-waves scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 12d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 98 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Opus rate-limit on a fan-out → retry on Sonnet, throttled into waves
Problem
A wide parallel fan-out (Workflow parallel()/pipeline() or many concurrent Agent
calls) launched on Opus mass-fails with a server-side capacity throttle, not your
account quota. The whole fan-out collapses to a handful of results — only the agents that
happened to finish before the burst survive.
Context / Trigger Conditions
- Failure string (one per dead agent):
API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited→ HTTP 429. - The "(not your usage limit)" clause is the tell: this is Anthropic-side Opus capacity throttling, NOT your per-account rate limit. Waiting and retrying on Opus alone often re-hits it.
- You launched many subagents at once (one
parallel()over 20–50 items, or a single message with dozens ofAgentcalls). The wider the simultaneous burst, the worse. - Distinct from the empty-
StructuredOutputloop (that's a schema-payload failure under the same storm — see the companion skillworkflow-schema-agents-empty-loop-under-ratelimit). This skill is about the mass-429 capacity failure mode and the cheapest recovery.
Solution
Two independent levers; apply both on the retry:
-
Move the fan-out agents to Sonnet. Set
model: 'sonnet'on theagent()calls (Workflow) ormodel: "sonnet"on theAgenttool. Sonnet draws from a separate capacity pool, so it does not contend for the throttled Opus capacity. Keep the orchestrator and the final synthesis/judge on Opus — only the fan-out workers move. Triage / review / code-tracing / classification fan-outs are well within Sonnet's range. -
Throttle the burst into sequential waves. Instead of one N-wide
parallel(), loop in chunks of ~8 (parallel within a wave, barrier between waves). This spaces the request bursts so you never present 50 simultaneous requests again:const CHUNK = 8 const results = [] for (let i = 0; i < ITEMS.length; i += CHUNK) { const slice = ITEMS.slice(i, i + CHUNK) log(`wave ${i/CHUNK+1}: ${slice.join(', ')}`) const r = await parallel(slice.map((it) => () => agent(prompt(it), { model: 'sonnet', schema: SCHEMA }))) results.push(...r) }
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 12d ago First seen · 98 lines · 207 tokens per session scan A ddcd0910ac53
opus-ratelimit-fanout-retry-on-sonnet-throttled-waves is a skill published in the GitHub repository wan-huiyan/agent-traffic-control (3 stars, last pushed yesterday), licensed MIT. It adds 207 tokens to every session and 1,386 once invoked, about $0.0010 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
cloudflare-workers-observability
Cloudflare Workers observability with logging, Analytics Engine, Tail Workers, metrics, and alerting. Use for monitoring, debugging, tracing, or encountering log parsing, metric aggregation, alert configuration errors.
cloudflare-workers-dev-experience
Cloudflare Workers local development with Wrangler, Miniflare, hot reload, debugging. Use for project setup, wrangler.jsonc configuration, or encountering local dev, HMR, binding simulation errors.
cloudflare-workers-performance
Cloudflare Workers performance optimization with CPU, memory, caching, bundle size. Use for slow workers, high latency, cold starts, or encountering CPU limits, memory issues, timeout errors.
api-error-handling
Implements standardized API error responses with proper status codes, logging, and user-friendly messages. Use when building production APIs, implementing error recovery patterns, or integrating error monitoring services.
skeptical-triage
Reusable 3-round self-challenge + arbiter pattern for filtering false positives from findings/verdicts. Use when the cost of a false-positive gate block exceeds the cost of 4 extra LLM turns.
anti-patterns
Catalogue of known SDLC anti-patterns that greatcto agents must actively reject when reviewing architecture, plans, code, or post-mortems. Used by architect (pre-impl), pm (planning), senior-dev (impl), l3-support (post-incident).