fix(llm): classify image-count limit errors as context overflow (#51073) - #52702

Issue for this PR

Closes #51073

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

A session whose history exceeds the gateway's per-request image cap receives 400 [invalid_request_error] Too many images in request: N > 30 on every full-history turn. That message was not recognised by the provider-error classifier, so the 400 was surfaced as a hard invalid-request failure instead of a recoverable overflow. Overflow recovery never engaged, every retry repeated the identical 400, and the session was permanently bricked — matching the /compact-also-fails symptom in the report.

This classifies the image-count limit as a context-overflow condition so the existing overflow-recovery path takes over.

1. packages/llm/src/provider-error.ts — added two patterns to patterns:

   • /too many images?/i — matches the gateway message (Too many images in request: 31 > 30) and the upstream variant (.messages[0]: Too many images: max 600 images per request, got 601).
   • /(?:exceed|maximum|limit).*images?|images?.*(?:exceed|maximum|limit)/i — covers upstream phrasings such as Maximum number of images exceeded / Image limit exceeded.

   Both require the word image, so there is no bare /too many/ pattern. The existing exclusions (throttling error: / rate limit / too many requests) are evaluated first, so rate-limit and throttling messages stay out of context-overflow.

2. packages/llm/test/provider-error.test.ts — added 4 positive cases and a negative test asserting that throttling/flood messages containing "too many" are not classified as context overflow.

No changes were needed in the recovery path itself. executor.ts:262 sets classification: "context-overflow" from isContextOverflow(body) on HTTP 400 and the protocol handlers (anthropic-messages, openai-responses, bedrock-converse) set it from isContextOverflow(message); isContextOverflowFailure already handles both the InvalidRequestReason and ProviderErrorEvent shapes. With the classification in place, packages/core/src/session/runner/llm.ts:294 runs compactAfterOverflow, whose summary request is text-only (compaction.ts serialises attachments to [Attached <mime>: <name>] placeholders and persists text + recent as strings), so the rebuilt window carries no images and the retried request fits under the cap.

This is the client-side half of the report's ask 2 ("classify Too many images in request: ... as a recoverable/overflow condition so compaction can run"), and ties into #47493 and #39677. Ask 1 (uniform cap configuration across gateway routing targets) is server-side and out of scope here.

How did you verify your code works?

• bun test test/provider-error.test.ts from packages/llm: 3 pass, 0 fail.

• bun test from packages/llm (whole package): 299 pass, 30 skip, 0 fail, 667 expect() calls, 329 tests across 30 files — no regressions.

• Independent spot check of the classifier, including the exact production strings from the report:

  message	context-overflow
  Too many images in request: 31 > 30	true
  Too many images in request: 33 > 30	true
  Upstream request failed: [invalid_request_error] Too many images in request: 31 > 30	true
  .messages[0]: Too many images: max 600 images per request, got 601	true
  Maximum number of images exceeded / Image limit exceeded	true
  Too many requests / Throttling error: too many requests / rate limit exceeded	false
  Unsupported parameter: image_url.detail is not supported	false
  Bad request: model does not exist	false

Screenshots / recordings

N/A (provider error classification bugfix)

Checklist

• I have read the CONTRIBUTING document.
• My code follows the code style of this project.
• I have added tests to cover my changes.
• All new and existing tests passed.