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 LargeRequest 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.
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 LargeRequest contains too many imagesOnce 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:
example, the latest 7) as raw image payloads so recent work keeps full visual
fidelity.
addition to the count limit. The community implementation uses a default of
16 MiB estimated wire Base64 bytes.
with lightweight text cards containing the file path, what was observed,
why it was captured, and a way to request the image again.
read the path from the card and bring that image back into active context.
conversation history remains complete.
image data.
Benefits
debugging workflows.
best-effort summary of older images.
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.