provider: 413 payload-too-large surfaces as Upstream response was not valid JSON and never triggers compaction #59067

Summary

A request rejected by the provider with HTTP 413 (payload too large) is surfaced as the misleading provider.invalid-request: Upstream request failed: [server_error] Upstream response was not valid JSON, the session is marked failed, and no automatic compaction or retry happens — even though the compaction docs promise one recovery when a provider rejects a request as too long. Every later prompt fails identically until a manual /compact.

Environment

• opencode version: 2.1.4
• OS: Windows 10.0.26200 (win32 x64)
• Terminal: TERM_PROGRAM=vscode, COLORTERM=truecolor
• Shell: cmd.exe
• Install/channel: latest (npm global @opencode/cli)
• Active plugins: none
• Provider/model: opencode-go/deepseek-v4.1-flash

Reproduction

1. Run a long session that inspects screenshots: ~180 tool results, each a read of an emulator PNG, returned as base64 and kept in history.
2. Send any prompt. The outgoing body reaches ~17 MB because every previous image result is re-sent.
3. The provider rejects it with 413. OpenCode reports:

   provider.invalid-request
   Upstream request failed: [server_error] Upstream response was not valid JSON
   status: 413
   body: {"error":{"type":"server_error","code":"server_error","message":"Upstream request failed: [server_error] Upstream response was not valid JSON"}}
   

4. Send another prompt (a one-word devam et). Same failure. The session is stuck.

Diagnostics for that session:

Expected Behavior

• A 413 / payload too large rejection should be classified as an oversize request, not as an invalid upstream response, and should trigger the documented single recovery (compact, then retry once).
• If recovery is impossible, the error should say the request was too large and suggest compaction, instead of implying the provider returned malformed JSON.
• Compaction thresholds should account for request bytes, not only tokens: here the conversation was nowhere near the token limit (~40k tokens after the previous compaction) yet exceeded the gateway's body limit, so token-based buffer/keep never fired.

Actual Behavior

• The provider's raw body text is passed through as the error message, which points at the wrong layer (JSON parsing) and hides the real cause (body size).
• No compaction attempt and no retry; the session becomes permanently unusable because every subsequent prompt resends the same oversized history.
• Session outcome is failed with no hint that compaction would fix it.

Additional Context

• Workaround that resolves it completely:

  opencode api post /api/session/<id>/compact --data '{}'

  Context dropped from 17.1 MB to 160 KB and the session outcome flipped from failed to succeeded; the same session continued normally afterwards.
• GET /api/session/<id>/context was the only way to see the real problem (response size, and that 11.6 MB of it lived in tool results). A size warning in the UI or an entry in /api/session would have made this diagnosable without guesswork.
• Repro is deterministic for this session (100%), and presumably for any session that accumulates enough image tool results.
• Related but distinct: read on a PNG embeds base64 into history permanently, so the request grows monotonically. Even with compaction working, some guidance or a per-result size cap would help.