›_ Claude Code Issues
Claude Code Issues / #44850

[Bug] Telemetry events competing with API requests for rate limit budget

Status Fixed / completed
Reported on v2.1.92
Maintainer reply None cached
Activity 6 comments · opened Apr 7, 2026 · closed Apr 24, 2026

Bug Description
Key findings:

  1. Token count is tiny: autocompact: tokens=52172 threshold=967000 - you're at 52K tokens out of 980K. This is NOT

a token-based rate limit.

  1. 589 deferred tools, only 1 sent: Dynamic tool loading: 1/589 deferred tools included - so the tools aren't the

problem, confirmed.

  1. Rejections happen in ~19ms: Request sent at 19:51:19.989, rejected at 19:51:20.008. That's a

gateway/load-balancer rejection - it's not even reaching the model.

  1. Both "Type 2a" AND "Type 2b" within seconds: You're hitting two different rate limit buckets in rapid

succession.

  1. THIS IS THE BIG ONE - Claude Code's own telemetry is ALSO getting 429'd:

1P event logging: 39 events failed to export (status=429)
1P event logging: 80 events failed to export (status=429)

  1. Claude Code is firing batches of 39-80 telemetry events to the same API endpoint, and those are competing with

your actual requests for rate limit budget.

  1. The cloudflare-api MCP server is in a retry loop hammering Cloudflare ("No token data found" every ~1.3 seconds

for 40+ attempts), which may also be contributing noise.

The smoking gun is #5. Anthropic's own internal telemetry events are eating your rate limit. When you type
"continue," Claude Code fires off telemetry AND your API request simultaneously, and the telemetry batch can
starve the actual request.

This is a bug in Claude Code, not a problem with your usage. You should file this with the request IDs from the
log:

  • x-client-request-id=8c33ac75-4a82-4f52-96f3-2ee7185e220a (Type 2a)
  • x-client-request-id=53813b82-4fd3-4fc2-bb8e-e82308f2fd9e (Type 2b)

Environment Info

  • Platform: darwin
  • Terminal: WarpTerminal
  • Version: 2.1.92
  • Feedback ID: 3c6cf0dd-dca2-4ca0-a619-6918486d2db5

Errors

[{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/coreydylan/.local/share/claude/versions/2.1.92 (expected in multi-process scenarios)\n    at im_ (/$bunfs/root/src/entrypoints/cli.js:1884:2153)\n    at An6 (/$bunfs/root/src/entrypoints/cli.js:1884:1233)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-04-07T19:47:41.423Z"},{"error":"Error: Plugin MCP server error - mcp-config-invalid: MCP server github invalid: Missing environment variables: GITHUB_PERSONAL_ACCESS_TOKEN\n    at lAH (…

Note: Content was truncated.

View original on GitHub ↗

6 Comments

github-actions[bot] · 6 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/30616
  2. https://github.com/anthropics/claude-code/issues/37537
  3. https://github.com/anthropics/claude-code/issues/41891

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

coreydylan · 6 months ago

Update: mitmproxy capture proves this is NOT a quota issue

Captured full HTTP traffic using mitmproxy (mitmdump --set flow_detail=3) routed via HTTPS_PROXY + NODE_EXTRA_CA_CERTS to inspect every request/response between Claude Code and the Anthropic API.

Evidence

Last successful request immediately before the 429:

POST https://api.anthropic.com/v1/messages?beta=true
<< 200 OK

anthropic-ratelimit-unified-status: allowed
anthropic-ratelimit-unified-5h-status: allowed
anthropic-ratelimit-unified-5h-utilization: 0.04
anthropic-ratelimit-unified-7d-status: allowed
anthropic-ratelimit-unified-7d-utilization: 0.72
anthropic-ratelimit-unified-overage-status: allowed
anthropic-ratelimit-unified-overage-utilization: 0.0
anthropic-ratelimit-unified-representative-claim: five_hour

The very next request, seconds later:

POST https://api.anthropic.com/v1/messages?beta=true
<< 429 Too Many Requests 115b

Retry-After: 0
(NO anthropic-ratelimit-unified-* headers present)

{"error":{"type":"rate_limit_error","message":"Type 2b rate limited. Please try again later."}}

Why this proves it's a bug

  1. 4% of 5-hour quota used. The unified rate limiter explicitly returned status: allowed on the preceding request. Nowhere near any quota limit.
  1. Retry-After: 0 — the server tells the client to retry with zero delay. A real rate limit would have a nonzero retry-after value.
  1. No anthropic-ratelimit-unified-* headers on the 429 — the unified rate limiter never evaluated this request. Something upstream (Cloudflare gateway? load balancer?) is rejecting it before it reaches the actual rate limiter.
  1. Both "Type 2a" and "Type 2b" errors occur within seconds of each other in the same session, alternating:

``
19:51:20.008 - Type 2a rate limited (x-client-request-id: 8c33ac75-4a82-4f52-96f3-2ee7185e220a)
19:51:33.342 - Type 2b rate limited (x-client-request-id: 53813b82-4fd3-4fc2-bb8e-e82308f2fd9e)
19:51:36.541 - Type 2a rate limited
19:51:37.795 - Type 2a rate limited
19:51:38.979 - Type 2b rate limited
19:51:40.146 - Type 2b rate limited
19:51:41.317 - Type 2b rate limited
``

  1. Rejections happen in ~19ms — far too fast for any token-counting rate limiter. This is a gateway-level rejection.
  1. 1P telemetry events are also getting 429'd simultaneously:

``
1P event logging: 14 events failed to export (status=429)
1P event logging: 39 events failed to export (status=429)
1P event logging: 80 events failed to export (status=429)
``
Internal Claude Code telemetry batches appear to be competing for the same rate limit budget as actual API requests.

Additional noise: cloud-managed MCP server retry storm

The cloud-managed cloudflare-api MCP server (fetched from api.anthropic.com/v1/mcp_servers) generated 234 log entries in a single session, retrying "No token data found" every ~1.3 seconds for the entire session duration before eventually disconnecting. This server has no configured OAuth token and cannot connect, but it retries indefinitely.

Environment

  • Claude Code v2.1.92
  • Opus 4.6 (1M context), Claude Max subscription
  • macOS Darwin 25.3.0, single session, zero concurrent usage
  • Token count at time of rejection: 52,172 (out of 980,000 effective window)

Request IDs for server-side lookup

  • 6a91fd1c-6d09-42f1-841f-c5ae82c9530a (200 OK, shows 4% utilization)
  • 8c33ac75-4a82-4f52-96f3-2ee7185e220a (429 Type 2a)
  • 53813b82-4fd3-4fc2-bb8e-e82308f2fd9e (429 Type 2b)

Reproduction

# Start mitmproxy
mitmdump --mode regular --listen-port 8080 -w /tmp/claude-traffic.flow --set flow_detail=3

# Start Claude Code through proxy
HTTPS_PROXY=http://127.0.0.1:8080 NODE_EXTRA_CA_CERTS=~/.mitmproxy/mitmproxy-ca-cert.pem claude --debug-file /tmp/claude-debug.log

# Use normally — 429s appear within minutes even on a fresh session
coreydylan · 6 months ago

Additional context

This issue reproduces on two separate machines (MacBook Pro and MacBook Air via SSH), and on multiple networks, so this is not a local configuration or network-specific issue.

One potentially relevant detail: around the time this started, I set up Syncthing to sync Claude Code conversation history (~/.claude/history.jsonl and related session files) between the two machines. I'm not sure how or if this could contribute — the sync only touches local files, not API requests — but it's the only environmental change that coincides with the onset of this issue. Mentioning it for completeness in case the device_id or session_id in the API metadata (visible in the mitmproxy capture) could cause server-side rate limit bucket confusion when history is shared across devices.

coreydylan · 6 months ago

Update: Confirmed NOT a client configuration issue

Ran a definitive test: emptied ~/.claude/mcp.json (zero MCP servers) and ~/.claude/settings.json (zero hooks, zero plugins, zero env vars). Started a completely clean Claude Code session:

claude --debug-file /tmp/claude-clean-test.log

Result: 429 "Type 2a rate limited" after just 2 messages.

This rules out:

  • MCP servers / tool count
  • Plugins
  • Hooks
  • Any client-side configuration
  • Session sync between machines (tested separately)

Also tested with multiple Anthropic accounts on the same machine — same issue. And the issue reproduces on two different machines across multiple networks.

The only constant is Anthropic's API gateway. Combined with the mitmproxy evidence (4% utilization, Retry-After: 0, no anthropic-ratelimit-unified-* headers on the 429, 19ms rejection time), this is definitively a server-side issue in the gateway/load-balancer layer that sits in front of the actual rate limiter.

coreydylan · 5 months ago

Closing — figured out the root cause on my end. Thanks!

github-actions[bot] · 5 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: Rate limit errors, MCP server connection issues, Context window & memory limits

Browse all Claude Code issue topics →