[BUG] Agent accumulated 51 images via read tool, session bricked by provider 50-image count limit with no recovery #47487

Activity

1. github-actions

   assigned

   rekram1-node

   on Sep 5, 2026
2. github-actions commented on Sep 5, 2026

   

   github-actionsBot

   on Sep 5, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Image-count 400s (Azure: "Exceeded maximum number of images (50)") are not classified as context overflow, so media-strip compaction never triggers #39677: Same root cause — agent accumulates 50+ images in a session, provider returns a 400 image-count error, and the session becomes permanently unrecoverable because the error is not classified as context_overflow so compaction/media-strip never triggers. That issue also includes a suggested fix and covers the Azure and OpenRouter variants of the same provider cap.
3. royalpinto007 commented on Sep 5, 2026

   

   royalpinto007

   on Sep 5, 2026

   Author

   More actions

   Fix proposed in #47493: classify image-count rejections as context overflow and cap outgoing images at 40 newest per request with placeholders for older ones. Verified with new tests plus existing session suites.
4. Sugamsss commented on Sep 9, 2026

   

   Sugamsss

   on Sep 9, 2026

   More actions

   We hit this exact problem while doing visual verification loops with Playwright — once you accumulate screenshots, sessions hit 413 payload caps or provider count limits (like the 50-image ceiling here). When that happens, the session gets wedged because the raw base64 stays in the transcript.

   While core handling is being designed, I put together a zero-dependency plugin that solved this for our workflow: opencode-prune-images (added in PR #48096).

   How it works:

   • It hooks into context right before dispatch so your persisted SQLite history is never touched or corrupted.
   • It keeps the latest 7 images as normal raw pictures for the model.
   • Any older images beyond the 7 are transformed in-memory into a 3-point text card capturing the file path, what the model observed in that turn, and the user's intent.
   • If you ask about an older image later ("remember that screenshot with the alignment bug?"), the model sees the path on the card and simply uses its read tool to pull that specific image back into the active 7 slots.
   • It backs up ephemeral /tmp screenshots and pasted base64 data to a small rolling local cache (~/.cache/opencode/recent-images/, capped at 100 files FIFO) so images don't vanish if /tmp gets cleared.

   Sharing here in case it helps unblock anyone running into this right now.
5. ez2sarang commented on Sep 16, 2026

   

   ez2sarang

   on Sep 16, 2026

   More actions

   Same failure on 1.18.30, provider opencode / muse-spark-1.3-contributor-free (Console), macOS 26.6.2: a UI-iteration session where the agent read 52 screenshots ended with

   Error from provider (Console): Upstream request failed: [invalid_request_error] request contains 52 images, exceeding the maximum of 50 allowed per request
   

   and every later prompt (plain text included) failed identically. Auto-recovery never ran, consistent with the classification gap in #39677.

   A second gap that I don't think has been mentioned yet: the existing prune pass can't help even when it does run, because it budgets by text only:

   • SessionCompaction.prune walks old completed tool parts and sums Token.estimate(part.state.output) against PRUNE_PROTECT = 40_000 (https://github.com/anomalyco/opencode/blob/3104c1428e/packages/opencode/src/session/compaction.ts#L286-L318, estimate at L299).
   • For an image read, state.output is the 23-char string Image read successfully; the attachment (base64 bytes, image count) is not part of the estimate. So 52 screenshots ≈ 0 tokens, the budget is never exceeded and nothing gets time.compacted.

   Suggestion, complementary to #47493's per-request cap: make prune count attachments too (a fixed token weight per image attachment, and/or an attachment-count budget), so old screenshots get time.compacted like any other large tool output. Once the flag is set, toModelMessages already does the right thing: [Old tool result content cleared] + attachments dropped (https://github.com/anomalyco/opencode/blob/3104c1428e/packages/opencode/src/session/message-v2.ts#L293-L296).

   Recovery that works today for a bricked session (same mechanism prune uses, fully reversible — just delete the key):

   import sqlite3, json, time
   db = sqlite3.connect('~/.local/share/opencode/opencode.db'.replace('~', __import__('os').path.expanduser('~')))
   sid = 'ses_...'; keep_after_ms = 0  # e.g. time_created of the first part you still want as an image
   rows = db.execute("""select id, data from part where session_id=? and json_extract(data,'$.type')='tool'
     and json_extract(data,'$.state.status')='completed'
     and json_array_length(json_extract(data,'$.state.attachments'))>0
     and json_extract(data,'$.state.time.compacted') is null and time_created < ?""", (sid, keep_after_ms)).fetchall()
   now = int(time.time()*1000)
   for pid, data in rows:
       d = json.loads(data); d['state']['time']['compacted'] = now
       db.execute("update part set data=?, time_updated=? where id=?", (json.dumps(d, ensure_ascii=False), now, pid))
   db.commit()

   Back up opencode.db first. Verified on 1.18.30: 35 old image parts flagged → 17 images sent → session usable again, no restart needed (history is re-read from the DB on each turn). Only state.time.compacted is touched — don't put anything non-object into the part's top-level metadata, that field is forwarded as providerOptions and will fail the AI SDK ModelMessage[] schema.

   Also, reading the code, /compact on 1.18.30 serializes history to text with [Attached image/png: file] placeholders (compaction.ts L73-L78), so it shouldn't hit the image cap either; I didn't test it because I'd already recovered via the flag.
6. Sugamsss commented on Sep 17, 2026

   

   Sugamsss

   on Sep 17, 2026

   Last edited by Sugamsss

   More actions

   Thanks for the clear notes. We hit the same wall. Past the image cap, even plain text fails and recovery never kicks in.

   Your second gap looks right. Prune budgets text output only, so image reads barely count and nothing gets flagged. Counting attachments makes sense, next to the cap in 47493. And once flagged, core already drops attachments as it should.

   Thanks for the reversible fix too. Backup first, touch only time.compacted, stay out of metadata. Noted on providerOptions.

   On compact, you are right. V1 uses text placeholders, so it should not hit the cap like normal dispatch. Forcing compaction on every image cap still feels heavy to me. It rewrites history to clear old results. I prefer a rolling window first. History stays intact, newest images stay raw, older ones become cards.

   That is what my plugin does. Latest 7 within 16 MiB stay raw. Older ones become small cards with path and context. No DB writes. I also fixed pruned V1 attachments breaking downstream shapes. They now leave the array and their cards join the tool output.

   Plugin here if useful: https://github.com/Sugamsss/opencode-prune-images

   Shared goal. Sessions should not die from screenshots.
7. thdxr commented on Oct 11, 2026

   

   thdxr

   on Oct 11, 2026

   Member

   More actions

   Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

   — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
8. thdxr

   closed this as not plannedon Oct 11, 2026