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

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:

• #8202: pasted image exceeds the 5 MB per-image limit and the session remains broken for later prompts
• #56674: generic Request too large (max 32MB) report
• #9892 / #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:

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

1. 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

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

1. 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

1. 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)

• #43056 — detailed forensic analysis of the base64 accumulation mechanism
• #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.