In-memory rolling window for images to reduce 413 and too-many-images errors

Problem

When agent loops use browser tools (Playwright, Chrome DevTools) or iterate on
visual UI tasks, a chat can accumulate many screenshot attachments. Eventually
the provider or gateway may reject the request with errors such as:

413 Request Entity Too Large
Request contains too many images
provider-specific body-size limit errors

Once this happens, sending a plain text message can remain difficult because
the accumulated image payload is assembled again. Compaction can also be
affected if it receives the same raw image data.

Proposed Solution

Add an in-memory rolling window for multimodal image parts during context
assembly, before dispatch to the provider:

Active image window: Keep a configurable number of recent images (for
example, the latest 7) as raw image payloads so recent work keeps full visual
fidelity.
Payload budget: Apply a configurable cumulative image-payload budget in
addition to the count limit. The community implementation uses a default of
16 MiB estimated wire Base64 bytes.
Older images become context cards: Replace images outside either budget
with lightweight text cards containing the file path, what was observed,
why it was captured, and a way to request the image again.
Natural recall: If a user asks about an older screenshot, the model can
read the path from the card and bring that image back into active context.
History untouched: Only the outgoing context is changed. Persisted
conversation history remains complete.
Compaction safety: During compaction, pass text cards instead of raw
image data.

Benefits

Reduces the chance of 413 and image-count failures during long visual
debugging workflows.
Limits image request bandwidth and input-token pressure.
Keeps recent images available at full fidelity while retaining a useful,
best-effort summary of older images.
Does not require a model call or an extra user prompt to prune context.

The community implementation is available at
Sugamsss/opencode-prune-images.
It is source-only and currently not published to npm. Its tests use synthetic
fixtures; provider-specific request limits and native core integration still
need independent verification.

If the core team wants this behavior natively, I would be happy to help adapt
the design to OpenCode's context assembly and compaction paths.

This issue might be a duplicate of existing issues. Please check:

Request Entity Too Large with images blocks session — compaction also fails #14562: Request Entity Too Large with images blocks session — compaction also fails (same root problem, same session-wedge symptom)
Image-count 400s (Azure: "Exceeded maximum number of images (50)") are not classified as context overflow, so media-strip compaction never triggers #39677: Image-count 400s not classified as context overflow, media-strip compaction never triggers (same issue on Azure)
core: request accumulates 52 images, exceeds provider max of 50 #47721: Request accumulates 52 images, exceeds provider max of 50 (same session-bricking scenario)
[BUG] Agent accumulated 51 images via read tool, session bricked by provider 50-image count limit with no recovery #47487: Agent accumulated 51 images, session bricked by provider 50-image count limit with no recovery (same problem with detailed DB analysis)

Your issue proposes a rolling-window solution (which is a different angle from the bug reports above), and the community plugin is a useful reference. It may be worth linking to or commenting on one of the existing issues, especially #47487 which is already assigned and actively tracked.

��

Navigation Menu

Repository navigation

In-memory rolling window for images to reduce 413 and too-many-images errors #48095

Problem

Proposed Solution

Benefits

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

In-memory rolling window for images to reduce 413 and too-many-images errors #48095

Description

Problem

Proposed Solution

Benefits

Activity

github-actions commented on Sep 9, 2026

4Liberty commented on Sep 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions