[BUG] Bedrock "400 Input is too long." (oversized image payload) isn't treated as request_too_large, so the session is stuck for good
Summary
On Amazon Bedrock, when a session's request gets too big because of image content, Bedrock answers 400 Input is too long. Claude Code doesn't treat that as request_too_large (or as prompt-too-long), so it never strips media or compacts. Every later turn re-sends the same oversized history and fails the same way, which makes the session unusable for good.
On the Anthropic API, the same overflow comes back as a 413 request_too_large. Claude Code handles that one correctly by stripping images and documents, then compacting if that isn't enough.
Environment
- Claude Code 2.1.288 via
@anthropic-ai/claude-agent-sdk0.3.288, headless (-p/ stream-json) CLAUDE_CODE_USE_BEDROCK=1, modelglobal.anthropic.claude-fable-5-1(Invoke API, us-east-1)
What happened
- The session read 72 screenshots with the Read tool (1920×1080 PNGs, re-encoded by Read to JPEG/PNG of at most 512 KB each): about 22.6 MB raw, about 30 MB base64.
- Context was about 670K tokens, well under the model's window.
- The next turn's request failed with
API Error: 400 Input is too long.Five later user turns in the same session failed identically. - No compaction or media stripping happened.
Cause (from reading the bundled classifier)
The prompt-too-long check matches "Prompt is too long" / "Input is too long for requested model", and the media path keys on request_too_large / "too much media". Bedrock's message here is just Input is too long., so it falls through to an unrecognised provider error.
Expected
Treat Bedrock's bare Input is too long. (status 400) like request_too_large: strip older images and documents first, then compact. Then a long, screenshot-heavy session recovers on Bedrock the way it does on the Anthropic API.
Repro
On Bedrock, have a session Read about 70+ full-HD screenshots across turns (so total request bytes pass about 30 MB while tokens stay well under the context window), then send another message.