[BUG] /deep-research — default workflow frequently hits "API Error: Server is temporarily limiting requests"

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/65500
2. https://github.com/anthropics/claude-code/issues/64328

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

@claude Not a duplicate of #64328 or #65500, though related. Those two describe the verify phase dying. #64328 is the 429 retry loop with no backoff or circuit breaker (token burn); #65500 is the non-catchable fatal abort when a schema-bound subagent fails to emit StructuredOutput.

This issue reports a distinct second defect neither of those covers: a failed or abstaining verifier is scored as a refutation, not as "unverified". The consequence is qualitatively different. The run does not die. It completes and reports the opposite of the truth: search and fetch succeed (24 sources, 64 claims extracted), then the throttled verify phase causes the tool to return "All 25 claims refuted by adversarial verification. Research inconclusive."

So the user-visible outcome is not an error or a crash. It is a confident wrong answer ("no evidence found") on research that actually succeeded. That is harder to detect than a fatal abort and is the part not tracked elsewhere.

Fix #1 in this report (abstain ≠ refuted) is needed regardless of whether the 429 backoff (#64328) or the catchability fix (#65500) lands, because it is what converts a transient throttle into total, silent loss of output. Happy to consolidate if maintainers prefer, but flagging that this scoring bug would survive the fixes proposed in both linked issues.

One broader point. The suggested workaround by claude in the conversation was to build a custom workflow (plain general-purpose subagents, no forced schema, direct WebSearch/WebFetch), which #65500's commenter confirms works first try at lower token cost. That is a sound workaround, but it should not be the answer. The default /deep-research workflow ships as a headline feature; a ~3/10 success rate means the happy path is not reliable even at modest fan-out. At minimum the default should degrade gracefully under throttling (keep flagged-unverified findings) rather than inverting the result, and ideally cap verify concurrency so the common case completes. Asking every user to hand-roll a replacement defeats the purpose of shipping the workflow.

Deep Research workflow should be able to hit a limit, stall out, and then be resumed on command by the model in the main claude code chat - its a huge waste for it to not be able to pick up where it left off when for whatever reason claude calls stopped completing (limit hit, lost internet, etc)

The 429s here have a worse consequence than wasted tokens: a false-null correctness bug. When verifier votes get rate-limited, /deep-research reports cleanly-extracted real claims as "refuted by adversarial verification — research inconclusive, sources may be low-quality or claims overstated."

Two bugs in the verify phase (verbatim from the v2.1.183 binary-embedded workflow):

1. error ≠ refutation conflation. A 429'd verifier agent() returns null; nulls are dropped, then:

const survives = valid.length >= REFUTATIONS_REQUIRED && refuted < REFUTATIONS_REQUIRED

When all votes 429, valid.length === 0 → survives === false → the claim is bucketed as killed, indistinguishable from a genuinely-refuted claim.

2. misleading terminal summary. The confirmed.length === 0 branch hardcodes:

summary: "All N claims refuted by adversarial verification. Research inconclusive — sources may be low-quality or claims overstated."

and dumps the un-adjudicated claims into a field literally named refuted. There is no verificationDegraded signal.

Live repro: one run hit 100% verifier-vote 429 (42/42 votes). 14 valid claims extracted from primary arXiv sources were reported as "all refuted, sources low-quality." A re-run with serialized verification (≤3 concurrent) hit 0% vote failures and confirmed 13/14 — i.e. the research was fine; only verification was rate-limited.

Suggested fixes: (a) make "unverified (votes errored)" a first-class third state, never reported as refuted; (b) branch the zero-confirmed summary on why nothing confirmed — emit verificationDegraded: true and return claims as leads when the vote-failure rate is high, reserving "sources low-quality" for genuine refutation. Root cause is the missing agent() 429 backoff (#64328); retrying also hit the resume-cache bug (#67488). Reducing verify+fetch concurrency (serial verify, bounded fetch) avoids the self-induced burst, but harness-level backoff is the real fix.

Corroborating from a different angle: this failure mode isn't specific to /deep-research's implementation — I hit the identical error today running a manually-orchestrated multi-agent code review (no /deep-research involved).

Setup: a full-review-style pass across two sister repos (~47k LOC). I dispatched 5 parallel general-purpose subagents via the Agent tool, each scoped to a different subsystem. Per Claude Code's own default subagent guidance (encouraging delegation for independent research), several of those first-level agents themselves spawned further child agents to investigate sub-areas — producing a burst of 20+ concurrent API-calling agents from one session, none of which I explicitly asked for.

Result: multiple of the aggregating parent agents' turns terminated with

API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited

as their entire output — before they could synthesize or report their children's findings. Children that had already finished still delivered results as separate notifications (so no data was silently lost), but every parent's synthesis step was destroyed, and I had to manually recover findings from the child transcripts.

Confirms your fix generalizes: capping/serializing concurrent subagent calls is what worked for me too. My variant: switching my second wave of review agents to a subagent type with no Agent-tool access at all (so it's structurally incapable of a second level of fan-out) eliminated the concurrency spike and let the review complete cleanly — functionally the same lever as your confirmed ≤3-concurrent serialization, just enforced by removing the capability rather than throttling the call rate.

Why this matters beyond one workflow: the root cause here is not /deep-research-specific — it's a general property of any Claude Code session where a first-level subagent can itself spawn further subagents, with no concurrency cap anywhere in the chain. That's a much broader blast radius than one built-in workflow. It also means this can silently wreck a previously-reliable, hand-built review/research workflow with zero prompt or code change on the user's side — the only variable that flipped was how much fan-out volume the recursive-spawning behavior happened to produce in that particular session. No warning, no backoff, no partial-completion signal — just a dead aggregator and lost synthesis.

Cross-linking #73829, which documents the same recursive-spawning root cause (there, manifesting as an infinite no-op loop + permanently orphaned tasks rather than a hard rate-limit death) — worth reading these as one shared enabling bug with at least two different downstream symptoms.

Following up with a concrete cost figure, since this bug class isn't just a workflow annoyance — it's a real billing problem.

I measured token consumption for that session via my own conversation-logging setup: the rate-limited fan-out incident alone consumed ~770k tokens across 45 human turns / 1,543 total messages. My entire other legitimate work that same day — real feature development across sessions with little to no concurrent Agent-tool fan-out — totaled ~564k tokens across 163 human turns / 3,865 total messages.

Put another way: the failed session cost ~5x more tokens per human turn (~17.1k/turn) than every other productive session that day combined (~3.5k/turn). This wasn't a case of doing less work and burning fewer tokens efficiently elsewhere — the "efficient" sessions had 3.6x more human interaction and still cost less in total. The failure mode itself is what's expensive, not a lack of effort.

One failure episode cost ~40% more tokens than an entire day of actual productive work, almost entirely burned on retries and concurrent-request churn. For anyone paying per-token or watching a usage ceiling, an unbounded concurrent fan-out that trips rate-limiting isn't just slow — it's a cost multiplier with no ceiling of its own, since retry/backoff itself consumes tokens on every failed attempt.

Cross-linking #73829, where I'm also posting fresh corroboration today of the sibling no-op-loop symptom from the same root cause.