Image/file payload not counted toward context — long sessions die with generic 400 invalid_request_error instead of compacting #54690

Activity

1. opencode-agent commented on Oct 12, 2026

   

   opencode-agentBot

   on Oct 12, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report. I think this is a duplicate of #46564: the provider rejects the request with a bare HTTP 400 invalid_request_error, OpenCode doesn't classify that as a context overflow, so the automatic compact-and-retry recovery never runs and every later prompt (even "Continue") re-sends the same history and fails. Someone there reproduced it on the first-party provider with muse-spark-1.3-contributor, the same model you're using.

   One note on the image part: v2 already counts attached images in its context estimate, as a fixed ~1,500 tokens per image (and ~2,000 per PDF) rather than by base64 length. That matches how providers count images; they don't tokenize the base64 as text. So the undercount is unlikely to come from images alone. A gateway payload or limit rejection that ends up as an unclassified 400 fits your symptoms better.

   Possible duplicates and related issues, ordered from most to least likely:

   • [v2] One-shot provider-overflow recovery does not engage when the provider returns an opaque 400 (e.g. bare "invalid request") — session dead-ends with no recovery #46564: opaque 400 "invalid request" isn't treated as overflow, so recovery never runs and the session dead-ends (reproduced with muse-spark-1.3-contributor)
   • compaction: 1M-context sessions never auto-compact before the provider returns HTTP 400, and the 400 is not treated as context overflow #50574: 1M-context sessions never auto-compact before the provider returns HTTP 400, and the 400 isn't treated as overflow; a comment there also covers the token estimate undercounting
   • provider: opencode-go gateway rejects ~148k input while catalog claims 1M context — 400 unrecoverable, body never surfaced #50446: the opencode-go gateway rejects requests well below the advertised 1M context; the 400 is unrecoverable and its body is never shown
   • provider: opencode-go route-dependent context limits cause unparseable HTTP 400 in long sessions #50761: opencode-go route-dependent limits cause unparseable 400s in long sessions
   • Problem: 6MB request body size limit blocks legitimate image inputs on Qwen3.7Plus (OpenCode Go) #35112: an earlier request-body size limit on OpenCode Go blocking large image payloads
   • In-memory rolling window for images to reduce 413 and too-many-images errors #48095: proposal to keep only a rolling window of recent images in outgoing requests

   The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
2. opencode-agent

   added

   pending close

   triaging

   on Oct 12, 2026
3. ImBIOS commented on Oct 12, 2026

   

   ImBIOS

   on Oct 12, 2026

   ContributorAuthor

   More actions

   Related (not a duplicate): #53107 covers HTTP 413 payload-too-large never reaching recovery; the open fix #53108 handles that path. This report is the HTTP 400 variant — invalid_request_error with null code/param from an OpenAI-compatible proxy on an oversized (image-heavy) body — which is classified as neither overflow nor payload-too-large, so no compaction recovery triggers either. If #53108's classification can be extended to generic 400 payload rejections, it would cover this case too.
4. opencode-agent commented on Oct 12, 2026

   

   opencode-agentBot

   on Oct 12, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks, that's a helpful distinction, and I agree #53107 is related but not the same: it covers HTTP 413 payload-too-large, and its fix #53108 only adds that case to the one-shot compaction recovery. A 400 classified as provider.invalid-request still wouldn't start recovery with that change alone.

   The 400 case you describe (invalid_request_error, no code or param, so the error is classified as neither overflow nor payload-too-large and compaction never starts) is what #46564 tracks. Someone there reproduced it on the first-party provider with muse-spark-1.3-contributor, the same model you're using. So I still think this is a duplicate of #46564. Your suggestion to extend #53108's handling to generic 400 payload rejections would be useful as a comment on #46564 or #53108, where maintainers will decide the fix.

   Related issues, most relevant first:

   • [v2] One-shot provider-overflow recovery does not engage when the provider returns an opaque 400 (e.g. bare "invalid request") — session dead-ends with no recovery #46564: bare 400 "invalid request" isn't treated as overflow, so recovery never runs (same model)
   • fix(core): recover sessions after HTTP 413 payload rejections #53107 / fix(core): recover sessions after payload size rejection #53108: the 413 payload-too-large variant and its open fix
   • compaction: 1M-context sessions never auto-compact before the provider returns HTTP 400, and the 400 is not treated as context overflow #50574: 1M-context opencode-go sessions don't auto-compact before the 400
   • provider: opencode-go gateway rejects ~148k input while catalog claims 1M context — 400 unrecoverable, body never surfaced #50446 / provider: opencode-go route-dependent context limits cause unparseable HTTP 400 in long sessions #50761: the opencode-go gateway's real limits are lower than advertised, and the 400 body is never shown

   Unless something else shows how your problem differs from #46564, this issue will still be closed as a duplicate of it.
5. opencode-agent

   closed this as duplicateon Oct 13, 2026
6. opencode-agent commented on Oct 13, 2026

   

   opencode-agentBot

   on Oct 13, 2026 – with OpenCode Agent

   Contributor

   More actions

   Closing this as a duplicate of #46564. That issue tracks the same failure: a bare HTTP 400 invalid_request_error isn't treated as context overflow, so compaction recovery never runs and the session stays stuck. It was reproduced there with muse-spark-1.3-contributor, the same model you're using. Please follow #46564 for updates, and feel free to add your details there, including the image-heavy session and your idea of extending #53108's payload-too-large handling to generic 400 rejections. Related: #53107 / #53108 (the 413 variant and its open fix), #50574 and #50446. Thanks for the thorough report! If you find this behaves differently from #46564, reply here and we can reopen.
7. ImBIOS commented on Oct 14, 2026

   

   ImBIOS

   on Oct 14, 2026

   ContributorAuthor

   More actions

   Fix PR open: #55286 (also linked on #46564).