{{ message }}
Repository navigation
pdf: multiple PDF reads accumulate images exceeding provider limit, causing unrecoverable error #48781
Closed as duplicate
Description
Summary
When the agent reads multiple PDF files in a single session, all PDF page images accumulate in the request context. Once the total image count exceeds the provider's per-request image limit (50 for Console Go), every subsequent request fails with invalid_request_error. The agent cannot recover because the accumulated images remain in context and are re-sent on every retry.
Environment
- opencode version: 2.0.2
- OS: Windows_NT 10.0.26200 (win32 x64)
- Terminal: xterm-256color
- Shell: C:\WINDOWS\system32\cmd.exe
- Install/channel: latest
- Active plugins: None
Reproduction
- Open a session and ask the agent to read several PDF files (e.g., 6+ lecture PDFs with multiple pages each).
- The agent reads all PDFs in parallel using multiple
readtool calls. - Each PDF page is rendered as an image and added to the request context.
- Once the total image count exceeds 50, the next provider request fails with:
Error from provider (Console Go): Upstream request failed:
[invalid_request_error] request contains 98 images, exceeding the
maximum of 50 allowed per request
- Every subsequent message (including "try again" or new instructions) fails with the same error because the accumulated images persist in context.
Expected Behavior
The agent or opencode core should either:
- Limit the number of PDF pages sent per request to stay within provider image limits, or
- Remove stale PDF page images from context before sending new requests, or
- At minimum, surface a clear recovery path so the session is not permanently broken.
Actual Behavior
After reading ~6 multi-page PDFs, the session becomes permanently broken. Every retry fails with the same invalid_request_error. The user must start a new session to continue working.
The agent attempted to work around this by:
- Saying "try again" — failed (same error, same images in context).
- Saying "don't process all the images at once" — failed (same error, images already accumulated).
- Attaching a single PDF via
@mention — failed (101 images now, still over limit).
None of these recoveries work because the old images remain in context.
Additional Context
- Provider: Console Go (opencode-go), model
muse-spark-1.3-contributor(xhigh variant). - The provider limit is 50 images per request.
- The accumulated images come from base64-encoded PDF page renders stored in message content.
- Session outcome:
failed. Total cost before failure: ~$0.003. - This may affect other providers with different image limits, but Console Go's 50-image limit is the one encountered here.
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Sep 13, 2026
This issue might be a duplicate of existing issues. Please check:
angeloruggieridj commentedon Oct 2, 2026
Same root cause on a variant: the built-in
readtool on PNG files (not PDF), with provideropencode-go/ modeldeepseek-v4.1-flash, where the gateway cap is 30 images.2.0.22, Windows 11 (NT 10.0.26300.0, win32 x64), VS Code integrated terminal,cmd.exe. No plugins.session_messageheld exactly 31type: "file"parts withmime: "image/png"— one perreadof a PNG. Some files were read 3–7 times, so the count grows fast. Every subsequent turn then fails:finish: "error",provider.invalid-request,status: 400; the session goesidlewithoutcome: "failed"and is unrecoverable.GET /api/session/{id}/contextstill assembles all images, sosession.generatefails too. Compaction doesn't rescue it: it is token-based, not image-aware, and on the capped route it is itself rejected (see [gateway] 30-image cap applied only to some session routes: identical request flips 400/200 with only x-opencode-session changed; capped sessions cannot /compact #51073).session_message.data(keeping the 5 most recent) dropped the assembled context to 5 images, after whichPOST /api/session/{id}/generatereturned200.So this is not PDF-specific: any workflow that repeatedly
reads rendered PNGs (e.g. reviewing generated report/figure pages) hits it. The fix direction is discussed in #48095; the gateway 30-image cap and the blocked/compactare in #51073.neriousy commentedon Oct 20, 2026
Thanks for the detailed report about PDF page images building up and blocking further messages. This is the same image-count problem as #47721, and we're tracking it there. Please subscribe or add a 👍 there; your PDF example and the follow-up about the 30-image limit are useful details worth adding.