Client-side "Request too large (max 20MB)" error for payloads under 1MB

Resolved 💬 6 comments Opened Apr 8, 2026 by shay2911 Closed May 23, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report
  • [x] I am using the latest version of Claude Code

What's Wrong?

Claude Code generates "Request too large (max 20MB)" errors for API requests whose actual wire payload is under 1MB. The error is generated client-side — the request never reaches the API.

Environment

  • macOS (Darwin 25.3.0, arm64)
  • Claude Code v2.1.92 and v2.1.94 (reproduced on both)
  • Opus 4.6 with 1M context
  • Max plan

Evidence

I run a local reverse proxy (ANTHROPIC_BASE_URL=http://localhost:8019) that forwards to api.anthropic.com. I added request body size + response status logging to every /v1/messages POST.

Session: ~1-hour coding session, 681 messages, 242 tool calls. No images, no PDFs, no screenshots.

JSONL analysis (conversation on disk):
| Metric | Value |
|---|---|
| Total JSONL file | 2.67 MB |
| Message content (API payload) | 1.20 MB |
| toolUseResult (undo data, not sent) | 1.08 MB |
| Largest tool result | 23.6 KB |
| Images/PDFs | None |

Proxy log (actual wire sizes during error window):

03:48:49 POST /v1/messages 467,127 bytes (0.45 MB) -> 200
03:48:51 JSONL: "Request too large (max 20MB)" — NO proxy request
03:49:56 JSONL: "Request too large (max 20MB)" — NO proxy request  
03:49:59 JSONL: "Request too large (max 20MB)" — NO proxy request
03:50:52 POST /v1/messages 471,186 bytes (0.45 MB) -> 200

During the 2-minute error window, Claude Code generated 13 errors across 2 sessions (original + fork) while sending zero requests to the proxy. All requests that DID reach the proxy were 0.45–0.58 MB and returned HTTP 200.

/context output at time of error:

241k/1m tokens (24%)
  System prompt: 6.2k tokens (0.6%)
  System tools: 11.7k tokens (1.2%)
  MCP tools: 3.8k tokens (0.4%)
  Messages: 251k tokens (25.1%)
  Free space: 699.7k (70.0%)

Root Cause (Binary Analysis)

The error is generated by V98() in the compiled binary:

// Error message generator
function V98() {
    let H = `max ${l9(pkH)}`; // pkH = 20971520 (20MB)
    return `Request too large (${H}). Double press esc to go back and try with a smaller file.`;
}

// Only call site (besides the error-to-content-type map):
if (H instanceof rq && H.status === 413)
    return r1({ content: V98(), error: "invalid_request" })

The client-side size calculation produces a false >20MB estimate. Once triggered, the session is permanently bricked — all subsequent requests are blocked locally without attempting to send.

How to Reproduce

  1. Start a coding session with Opus 4.6 (1M context)
  2. Perform ~240 tool calls over ~1 hour (edits, reads, greps, bash)
  3. Eventually hits "Request too large (max 20MB)" despite payload being <1MB
  4. Session becomes permanently unrecoverable — fork also fails

Impact

  • Session is permanently bricked — cannot send any message, including /compact
  • Error is misleading — suggests the request is 20MB when it's actually 0.45MB
  • /context shows 24% utilization — nowhere near capacity
  • Only workaround is /clear (loses all context)

Expected Behavior

A 0.45MB request should be sent to the API, not rejected locally as "20MB".

Related Issues

  • #43056 — Accumulated inline image base64 causes 20MB limit (different root cause: actual images)
  • #34751 — 20MB error on small files after extended session
  • #26019 — Error crashes conversation with no recovery

View original on GitHub ↗

This issue has 6 comments on GitHub. Read the full discussion on GitHub ↗