Show request body byte usage and preflight pasted/uploaded images before 32MB request_too_large

[zouchenzhen]

Feature request

Claude Code currently shows token/context usage, but image-heavy sessions can still fail with:

Request too large (max 32MB). Try with a smaller file.

This is confusing because the visible token context can still look healthy while the serialized HTTP request body is near or over the Messages API request-size limit. The mismatch is especially easy to hit in UI/frontend workflows where users paste screenshots, contact sheets, rendered PDF pages, or other image-heavy artifacts across multiple turns.

Related symptom reports I found before filing:

• [Bug] Anthropic API Error: Image Exceeds 5 MB Size Limit breaks session for subsequent text prompts. Also breaks --continue mode if exit/re-enter. #8202: pasted image exceeds the 5 MB per-image limit and the session remains broken for later prompts
• [BUG] Claude CoWork : Request too large (max 32MB). Try with a smaller file. #56674: generic Request too large (max 32MB) report
• Are you able to read that directory for the menu items? #9892 / [Bug] Anthropic API Error: Image Upload Size Blocking All Message Attempts #8039: similar image/request-size failure modes

This request is for a client-side prevention and recovery UX rather than another single symptom report.

Problem

There appear to be two different budgets users need to reason about:

1. Model token context, which Claude Code already surfaces.
2. Serialized request body bytes, which can fail earlier due to base64 images, large tool results, and accumulated conversation history.

For text-heavy sessions those budgets tend to correlate well enough. For image-heavy sessions they do not. A small number of screenshots can add substantial request-body bytes while showing only modest token usage in the UI. Users then keep working because the context meter looks safe, only to hit a 400/413 request-size error later.

Once a large pasted/uploaded image or large tool result is already in the session history, every follow-up request can continue to fail until the user compacts, clears, or starts a new session. The error message suggests using a smaller file, but by that point the problematic payload may already be in history, not just in the next file.

Requested behavior

Please consider adding some combination of the following:

1. Show request-body byte usage alongside token context, for example:

   Context: 240k / 1M tokens
   Request body: 24.5 MB / 32 MB
   

2. Preflight pasted/uploaded images before adding them to the conversation:

   • show original byte size and estimated serialized/base64 size
   • warn or block when an image is near the per-image or total request limit
   • offer automatic downsampling/compression before insertion

3. Warn before tool results or file reads push the session near the request-size limit.

4. On 400/413 request-size failures, offer a recovery path such as:

   • remove the most recent pasted/uploaded image from the session
   • remove or summarize the most recent large tool result
   • run a compact flow targeted at large binary/image blocks
   • open a new session carrying only a text summary of the current state

5. For repeated image use across turns, prefer the Files API / file_id internally where possible instead of repeatedly carrying base64 image content through the messages payload.

Why this matters

This is a common workflow for frontend/UI work: paste a screenshot, ask Claude Code to adjust a layout, paste another screenshot, inspect again, repeat. The current token-only context UI does not give users enough information to avoid request-body failures in that workflow.

Longer context models do not solve this class of failure because it is a serialized request-size limit, not only a token-window limit. A 1M-token context can still fail from image bytes well before the token context is full.

Related issues (post-filing)

• Accumulated inline image base64 in session history causes 'Request too large (max 20MB)' — blocks all messages including /feedback #43056 — detailed forensic analysis of the base64 accumulation mechanism
• Read tool sends requests exceeding 20MB API limit without pre-checking payload size #26018 — long-running thread with multiple independent "me too" reports

Environment

• Claude Code: 2.1.112
• OS: Windows
• Platform: Anthropic API / compatible Messages API usage

No private logs, screenshots, API keys, local paths, provider domains, or request IDs are included here.

[github-actions]

Found 3 possible duplicate issues:

1. Read tool sends requests exceeding 20MB API limit without pre-checking payload size #26018
2. Accumulated inline image base64 in session history causes 'Request too large (max 20MB)' — blocks all messages including /feedback #43056
3. No auto-compact or guidance when hitting 20MB request limit #40004

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

[obaoye0906-a11y]

Experiencing the same issue on Cowork (macOS Desktop app, latest version).

Uploaded a single 2.5MB PDF to a Cowork conversation. First message returned:

Request too large (max 32MB). Try with a smaller file.

Every subsequent message — including plain text with no attachment — returns the same error. The conversation is permanently broken. "Try again" does nothing. The only option is to abandon it entirely and lose all prior context.

This is a 2.5MB file hitting a 32MB limit. The error is clearly not about the file itself — it's the serialised request body issue described in this ticket.

The lack of any recovery path is the real pain point. Once this error fires, the conversation is dead. no compact flow, nothing. You just have to start over.

Fully support the requests in this issue, especially:

• Showing request body byte usage alongside token context
• Preflight checks before files are added to the conversation
• A recovery path when this error occurs (remove file from history, summarize and continue, etc.)

This is blocking real work on a paid plan. Screenshots below.

Environment:

• Claude Desktop (macOS), Cowork mode
• File: PDF, 2.5MB
• Paid subscriber

[zahir-w]

Is there any solution for this problem? I met the same que.
I just upload one one picture(<1mb) and a pdf(~1mb).

Environment
Claude Code: 2.1.138
OS: Ubuntu 22.04
Platform: Anthropic API + vscode cc

[jcogilvie]

I don't use any images in my workflow but I hit this a lot for some reason. My recovery workflow (which is pretty gross) is:

• double-esc to rewind to the previous message
  • choose "summarize messages" beyond this point (leave code alone)
• immediately /compact

This seems like something claude code should do for us.

[junaidtitan]

The invisible request size growth from accumulated images is a real pain — context looks healthy but the serialized payload is already near 32MB. Cozempic has an image-strip strategy that removes base64 image data from older turns while keeping the text, so screenshots don't silently poison your session. pip install cozempic — hooks auto-wire on first run. https://github.com/Ruya-AI/cozempic — let me know if it prevents the surprise 32MB errors.

[junaidtitan]

Great feature request — the mismatch between token context and serialized request bytes catches a lot of people. Until this ships natively, Cozempic (https://github.com/Ruya-AI/cozempic) has an estimate_tokens command that shows your session's actual token usage breakdown, and its image-strip strategy removes the base64 image blocks that are usually the biggest byte-budget offenders. pipx install cozempic && cozempic estimate to see where your session bytes are going.

[zouchenzhen]

Thanks for the additional reports. I think they clarify one more UX requirement beyond the byte-budget display and upload preflight mentioned above: a native recovery path after request_too_large.

The common failure mode seems to be:

• a relatively small upload can push the serialized request body over the limit;
• after the first failure, plain-text follow-up messages can keep failing because the oversized history is still resent;
• users currently have to discover manual recovery workflows such as rewind, summarize, and /compact.

So I would refine the request as:

1. Show serialized request-body byte usage, not only token usage.
2. Preflight uploaded/pasted files before they are added to conversation history.
3. When request_too_large happens, offer a built-in recovery action, such as compacting/pruning oversized attachment or image blocks, summarizing older turns, or letting the user remove the offending uploaded content without abandoning the conversation.

The recovery path feels important because the current error suggests trying a smaller file, but after the failure the conversation itself may already be unrecoverable.

[jiseongnoh]

+1 — hit the same problem today in a primarily text/tool-output session (not image-heavy), which reinforces the byte/token mismatch framing in the OP.

Data point

• Claude Code reported payload est ~24 MB / 32 MB - consider /compact soon
• /context showed only 26% token usage (257.9k / 1M, Opus 4.7) — Messages bucket: 212.5k tokens
• One small image paste total; rest was text/tool-output heavy
• Source of byte bloat: repeated Bash tool outputs (60-line snapshots × 14 cycles), one 260KB persisted grep result, and API tool responses that echo the request prompt back

This reinforces the report: the byte/token mismatch isn't exclusive to image-heavy workflows. Sessions with chatty tools (long curl outputs, JSON dumps, API echoes) accumulate bytes much faster than tokens. /context doesn't help here because it's token-denominated — exactly the gap the OP identifies.

What helped (and didn't)

• /context — diagnostic only, doesn't address bytes directly
• /compact — would work but loses detail; user resisted mid-task
• Manual head -c truncation on subsequent tool calls — reduced future growth but doesn't recover past bloat

Operational impact

In multi-hour sessions the 24/32MB warning arrives precisely when context is most loaded — so /compact is most expensive at the moment it's needed. Users get three bad options: (1) compact and lose detail, (2) clear and lose state, (3) keep going until 32MB hard-fails. A pre-emptive byte indicator (OP option 1) + large-output preflight (OP option 2) would let users plan compaction earlier when it's cheaper.

Marking as additional evidence rather than a separate report.