[BUG] This error kills the active session: API Error: 413 {"error":{"type":"request_too_large","message":"Request exceeds the maximum size"}}

I have this exact issue on Mac Sonoma.

same issue!

I am getting the same issue when I am giving it an image (size: 1.1Mb), OS: macOS Sequoia.

Similar issue on Sequoia 15.1.1

Was having it look through a directory of PDFs to help rename and organize.

Same issue with Claude Code 2.0.13
When uploading too many images or even a single image that exceeds size limits, Claude Code returns this error:
API Error: 413 {"error":{"type":"request_too_large","message":"Request exceeds the maximum size"}}
After this error occurs, the chat session becomes completely unusable and there is no way to continue working in that session. Even restarting Claude Code and using the /resume command doesn't help - the chat remains permanently broken and unusable. This is a blocking and severe error that forces users to abandon their entire conversation history and context.

I am also facing the exact same error and now it looks like there is no solution but to lose the current chat/context and start with fresh new session.

i have the same issue here, mac mini Tahoe 26.0.1. Claude CLI for Vscode. Now I have to copy the entire message over and hopefully Claude don't lose context, cause I am about to waste a whole hour of conversation for a project, thanks for nothing Anthropics. Bunch of useless bots.

Same issue here. Macbook pro, Sequoia, Version 15.7.2. A long running conversation ended with an API error. Now regardless of what input I provide, each prompt results in the same API error (413)

Ditto! I've tried to feed Claude Code in VSCode a log of .5 mln lines and now session is locked out with error
API Error: 413 {"error":{"type":"request_too_large","message":"Request exceeds the maximum size"}}

OS and versions:
Arch Linux 6.17.8-zen1-1-zen
aur/vscodium-bin 1.105.17075-1
Claude Code for VS Code 2.0.42

Same issue multiple times

Happens to me too:

API Error: 413 {"error":{"type":"request_too_large","message":"Request exceeds the maximum size"}}

and:

Error: Error during compaction: Error: API Error: 413 {"error":{"type":"request_too_large","message":"Request exceeds the maximum size"}}

Same error. Mine happened when Claude was reading various image files I have locally. I imagine it's because it read multiple so each request is sending all of the image files in the conversation history? I wasn't even able to run /compact to try to workaround it. Session is just dead now.

  ⎿  Read image (1.5MB)
  ⎿ API Error: 413 
    {"error":{"type":"request_too_large","message":"Request 
    exceeds the maximum size"}}

Same error. Mine happened when Claude was reading various image files I have locally.

Same. Only seen this when dealing with images (and/or playwright MCP).

The original bug description describes the possibility of needing to open a webpage with an infinite loop. That's not required to cause this bug. It's easy to reproduce locally 100% of the time. I have a minimal reproduction case, but it requires large files that I can't upload to github. Here are steps to reproduce.

1. Create an empty directory.
2. Create a CLAUDE.md file with contents You will read files from ./downloads and answer questions.
3. Create a folder in the directory ./downloads.
4. Insert two PDFs into the downloads directory. I took https://arxiv.org/pdf/2508.02324 and split the pdf into two using the print to pdf function and selecting a page range from 1 to 20 for the first pdf and 20 to 46 for the second pdf.

You should have a structure that looks like this:

.
  ├── CLAUDE.md
  └── downloads/
      ├── qwen_image_part_1.pdf (28.1 MB)
      └── qwen_image_part_2.pdf (18.0 MB)

Then in the top of the directory run claude. In your prompt type read.

same issue. any comments from maintainers/developers?

Same issue occurred in the middle of work! It stopped and i got the message!

API Error: 413 {"error":{"type":"request_too_large","message":"Request exceeds the maximum size"}}

Maybe because they have issues with Claude Opus 4.5!
https://status.claude.com/

<img width="904" height="753" alt="Image" src="https://github.com/user-attachments/assets/077dc314-c963-4310-972e-b838f3c7527e" />

Same issue here. Happened when reading PDF.

Yeah, this wouldn't bother me much except that it permanently nukes my session.

It's kind of a big deal that without warning, you can cross a threshold that forces you to start a new session with a complete (potentially significant) loss of context.

for a quick (hacky) fix until this is more permanently addressed: use /export to dump the context into a text file, and then /clear to start a new conversation, then reference the exported text file and continue the chat. Explicitly asking it not to load the problematic large file/image was sufficient to avoid falling into the same trap.

Months later, hitting same issue. Yet another issue that the Claude team successfully ignored for months

Using CLI, you can now press ESC twice to roll back to a point where the session still worked, and then use a prompt that prevents the issue from happening. (For me, it happens when it reads PNG files that are too big, and converting them to smaller JPEG files first fixes the issue.)

Using CLI, you can now press ESC twice to roll back to a point where the session still worked, and then use a prompt that prevents the issue from happening. (For me, it happens when it reads PNG files that are too big, and converting them to smaller JPEG files first fixes the issue.) - THIS REALLY HELPED.

Still getting the same error.

Error happens frequently with large PDFs. My workaround rn is to crop them before feeding to claude + restore the conversation to before the crash.

I kept hitting this exact issue - oversized file gets read, session is toast, no recovery path. After losing context one too many times, I built a workaround.

It's a PreToolUse hook that checks file size before the Read tool runs. Anything over 5MB gets blocked before it can corrupt the session. Also put together a recovery process for sessions that are already bricked.

https://github.com/greghughespdx/claudecode-file-guardian

Doesn't fix the underlying issue (Anthropic needs to add the check upstream), but it's kept me out of trouble since I installed it.

• g

Seeing this as well, with computer-use sessions. Used to occur only when claude got 'stuck' trying to achieve the stated objective, whereupon it entered a loop trying various alternatives in vain. But now I see it happening even when things are progressing well, and even though I'm making use of the _maybe_filter_to_n_most_recent_images functionality described in the sample code

for a quick (hacky) fix until this is more permanently addressed: use /export to dump the context into a text file, and then /clear to start a new conversation, then reference the exported text file and continue the chat. Explicitly asking it not to load the problematic large file/image was sufficient to avoid falling into the same trap.

Unfortunately, this doesn't look like an option for folks using Claude Code through VS Code.

I get this error aswell. when using Claude Code in the terminal. It went thru several documents and stopped at a pdf:

Read(GHSP_v1.0.pdf)
⎿  Read PDF (568.3KB)
⎿  API Error: 413 {"error":{"type":"request_too_large","message":"Request exceeds the maximum size"}}

and it stays in a loop giving that reply.

Mac OS 15.7.3

<img width="1266" height="136" alt="Image" src="https://github.com/user-attachments/assets/977ddad1-4e35-4c75-919e-aab9530138c5" />I'm having the same issue where the system keeps getting an API error 413 error and keeps looping back and forth.

The amazing thing is that even if you open a new dialog window, as long as you upload two or three images, it will report this error.

What is the solution? It's bit frustrating.

After analyzing a bricked session (117 MCP screenshots, 64MB, 0 compactions), I think the root cause is that compaction only triggers on token count, not byte count. Base64 images are byte-heavy but token-light — a 500KB screenshot costs maybe ~1K tokens. So you can hit 63MB of payload while only using ~50-100K tokens, never coming close to the compaction threshold.

Adding estimated payload byte-size as a second compaction trigger (alongside token count) should fix this class of issues.

Shared a PostToolUse hook that monitors cumulative session file size and a manual JSONL recovery technique over in #37418 — might help others hitting this.

here is what I did to temporarily solve the issue and complete my task, put this prompt at the end of your prompt: "Always use subagents to carryout tasks that can cause bloating context, this is of upmost importance."