PDF page images add ~190KB/page to every subsequent request but are near-invisible in the context meter

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 2 comments · opened Jul 27, 2026

What happened

Reading a multi-page PDF injects one base64 JPEG per page into the conversation (~190 KB of base64 each). These images stay in the message history and are re-sent with every subsequent request, but they are effectively invisible in the context meter because their token cost is small relative to their byte cost.

A session of mine became permanently unusable at 78,859 tokens — roughly 5% of a 1M context window — because a single 8-page PDF read had added ~1.5 MB of base64 to every request.

The numbers

One Read call with pages: "1-8" produced:

| | |
|---|---|
| images emitted | 8 (JPEG, 850x1100 px each) |
| base64 added | 1.49 MB |
| token cost | ~10,000 (~1,250/image) |
| total request payload after | 1.61 MB |
| of which images | 93% |
| context meter showed | 78,859 tokens |
| effective density | 20.4 bytes/token (normal text is ~6) |

The last successful turn was the one immediately preceding the image insertion. Every request after it failed. Nothing else about the session changed.

Why it matters

The context meter is the only signal a user has for "is this session getting too heavy," and it measures the wrong dimension for image content. A user can wedge a session at a small fraction of its context limit with no warning and no indication of the cause. From the user's side it presents as "this conversation randomly stopped working."

Recovery is also awkward: re-running the read to get the content back regenerates the same images and re-breaks the session. The workaround is to extract the PDF text separately and read that instead (~10K tokens of text vs 1.5 MB of images).

Reproduction

  1. Read any multi-page PDF via the Read tool with a pages range.
  2. Compare the serialized request payload size against the reported context usage.

Payload grows ~190 KB per page while the context meter barely moves.

Suggested fixes

Any of:

  • Account for image byte payload in the context/usage display, not just tokens.
  • Warn when a single tool result adds more than some threshold of payload.
  • Default PDF reads to text extraction, with images opt-in.
  • Drop or downsample page images once they fall outside a recency window.

Environment

  • Claude Code 2.1.220
  • macOS (darwin 25.1.0)
  • Model: Opus, 1M context

View original on GitHub ↗

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