[BUG] Request-Size-Driven Image Pruning Repeatedly Invalidates Prompt Cache and Amplifies Cache Writes

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When using an image MCP extensively in Claude Code, I’ve encountered an issue where, once the amount of image data exceeds a certain threshold, older images begin to be removed on a rolling basis to keep the serialized request below the request payload size limit. #83898 covers request-size-driven attachment pruning. When this happens, the prefix of the conversation changes on every turn, causing the prompt cache to miss. As a result, a very large prefill/cache write is performed repeatedly on each turn, and the usage allowance is consumed at an unusually fast rate. In my case, this can exhaust the entire subscription allowance within a single session. The impact depends heavily on how much vision context has accumulated by the time rolling pruning begins. With highly compressed images such as JPEGs, substantially more vision tokens can accumulate before the serialized request reaches the size limit. Once pruning starts, that much larger cached prefix begins shifting on every turn, making each cache rebuild far more expensive.

What Should Happen?

I would appreciate it if rolling deletion could be made opt-in, or if an alternative mechanism could be implemented that avoids invalidating the prompt cache whenever older images are removed.

Error Messages/Logs

Steps to Reproduce

1. Start a Claude Code session with an image-producing MCP.
2. Continue sending turns after pruning begins.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.231 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Unlike #65636 and #66815, this does not require an image-processing error or retry loop. It is also distinct from #86075, where cache invalidation is caused by clearing or replacing old tool results. Here, the trigger is request-size-driven rolling image pruning during otherwise successful image-heavy MCP usage. As Vision MCPs become more widely used, I expect more users may encounter this behavior.