API Error 500 (api_error) — multiple requests in a long Opus 4.6 session

Summary

Encountered HTTP 500 with {"type":"error","error":{"type":"api_error","message":"Internal server error"}} on three consecutive requests during a long-running Claude Code session. The CLI surfaced each one with a check status.claude.com hint, but https://status.claude.com showed no ongoing incident at the time.

The errors interrupted a multi-hour subagent-driven development workflow (implementing a plan across multiple dispatched subagents). Each retry eventually succeeded on its own, but the 500s appeared without the usual 529 / overload signals.

Request IDs

Please investigate these specific requests — they should pinpoint the failure mode in your logs:

• req_011Ca5jhtuxHWGoCYMuxBbUB
• req_011Ca5jiczXNQRG4yhBUAANs
• req_011Ca5jjusZ3DYjxgUVAXvGv

All three came back-to-back within a few minutes.

Environment

• Model: Claude Opus 4.6 (1M context) — claude-opus-4-6[1m]
• Client: Claude Code CLI
• Platform: darwin 24.6.0 (macOS)
• Session type: long single session with many subagent dispatches (superpowers:subagent-driven-development)

Observations

• Errors were not 429 / 529 — they reported api_error / Internal server error, suggesting something upstream of overload.
• The same session had ~5 hours of successful traffic before and after these 500s, so it doesn't look like a client-side auth/plan issue.
• /feedback is disabled in my setup via CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1, so I'm filing here instead. It would be useful if the CLI surfaced a more actionable hint in this case (e.g., distinguishing true api_error from routing/overload conditions, or suggesting a simple retry instead of check status.claude.com when the status page is green).

Ask

1. Check the request IDs above against backend logs to identify the actual failure.
2. Consider whether the check status.claude.com hint is accurate for api_error responses when the status page reports no incident — a plain retry suggestion might be more useful.

Thanks!