fix(errors): recover from "too many images" instead of dying on it

[ericleepi314]

An agent that reads image files in a loop — video frames, a screenshot series, a page-by-page scan — accumulates one image block per Read in the conversation, and every block rides along on every later request.

Nothing bounds that. Compaction is the only thing that strips images, and it's triggered by the token budget — so on a million-token model it may never fire before the provider's image cap is reached. The two limits are on different axes and only one was tracked.

Observed on terminal-bench 2.1 (video-processing, 2026-08-01): 82 image Reads, then

Exceeded maximum number of images (50) allowed in the request.

Why it was fatal

is_media_size_error matched only three patterns — "image exceeds"+"maximum", "image dimensions exceed"+"many-image", and "maximum of N PDF pages". The count wording matches none, so the error fell through to the generic handler, became Terminal(model_error), and killed a 22-minute run outright.

The recovery lane already existed and was already tested:

classify media_size → withhold (_is_withheld_media_size) → one reactive compaction
→ strip_images_from_messages drops the media → retry

Only the classifier's pattern set was missing the phrasing. Same gap class as is_image_unsupported_error, which had to be added separately for a different provider's wording.

The change

Adds count patterns, and makes the whole predicate case-insensitive — the first two patterns silently required exact lowercase.

Scope — what this does and doesn't buy

It converts a fatal crash into one compaction + retry, and a legible Terminal(image_error) if the cap is hit again (EARLY_STOP_SUBTYPES maps that to a non-success result subtype rather than a silent success).

It is not a full fix. has_attempted_reactive_compact is one-shot per turn-chain, so an agent that keeps reading images will hit the cap a second time and stop.

Nor would it have won that trial. On the same task, in the same container, with the same tools, claude-opus-5 used 15 image reads to luna's 82 (18 of which were re-reads of frames already seen) and never came close to the cap. Hitting the cap at all is a model-behaviour difference — only the crash is the harness's fault.

The root cause — unbounded image accumulation with no per-request bound — is deliberately left for a separate change: a proactive cap changes what the model sees on every image task, and the limit differs per provider (50 OpenAI/Azure, 100 Anthropic). That's a design decision worth making explicitly rather than as a side effect of a bug fix.

Verification

• Tests drive the real query loop with the exact failing string, asserting it reaches the media_size tag and exits as image_error rather than model_error.
• Negative controls: prompt_too_long keeps its own tag (it has a different recovery), a generic server error stays untagged (it has none) — so the widened patterns can't sweep in errors that would be routed wrongly.
• 13-case classifier table covering the observed wording, likely paraphrases, and the pre-existing size/PDF patterns.
• Mutation-tested: removing the count patterns reproduces the shipped failure.
• Full suite at the local baseline; no new failures.

🤖 Generated with Claude Code