bug(v2): inline image results make compaction fail with HTTP 413 #36552

Summary

In OpenCode V2, image tool results persisted as inline base64 can push the provider request above an HTTP body-size limit. Once that happens, automatic compaction submits the same oversized history and also fails, leaving the session unable to recover.

This was observed after a session inspected 16 PNG frames whose inline tool results totaled about 24.57 MiB. Persisted event data reached about 26.01 MiB. Compaction then failed six times, followed by 413 Request Entity Too Large responses from nginx.

This is a current V2 reproduction of the failure previously described in #14562, which was closed for inactivity rather than as fixed.

Environment

• OpenCode version: 0.0.0-next-15363
• Model: opencode/gpt-5.6-sol, xhigh
• OS: Unavailable
• Terminal: Unavailable
• Shell: Unavailable
• Install/channel: V2 next build
• Active plugins: Unavailable

Reproduction

1. Start a long session with substantial cached input (the observed session had 146,910 cached input tokens after its last successful step).
2. Inspect multiple PNG frames so image tool results are persisted inline as base64; the observed 16 frames totaled about 24.57 MiB.
3. Continue the session until the provider request exceeds the nginx request-body limit.
4. Observe automatic compaction retrying against the same oversized history.

Expected Behavior

OpenCode should keep large binary tool results out of provider history, or prune/replace them with references before compaction. If the provider rejects a request as too large, the session should recover through safe pruning, compaction, or a fork/new-session path.

Actual Behavior

Automatic compaction failed six times over roughly six minutes. Each attempt first emitted:

session.compaction.failed
provider.transport: HTTP transport failed

The normal model request then emitted:

session.step.failed
provider.invalid-request: Provider request failed with HTTP 413
413 Request Entity Too Large
nginx

Because compaction also needs to submit the oversized history, every retry resends effectively the same payload and fails again.

Additional Context

Potential fixes or design questions:

• Replace image tool results with references, resize them, or remove them from provider history after inspection.
• Prune large binary tool results before issuing a compaction request.
• Preserve the underlying HTTP 413 in the provider transport error rather than reporting only HTTP transport failed.
• Detect this unrecoverable state and offer a recoverable fork/new-session path.

The local background service remained healthy during the failure, so this did not appear to be a stuck-service issue.

Related issues:

• Request Entity Too Large with images blocks session — compaction also fails #14562 — same core failure, closed automatically after inactivity
• [Feature Request] Auto-resize large images to prevent API errors and broken sessions #19525 — image resizing proposal, closed
• bug(v2): Fable/Zen request-size 400 bypasses auto-compaction #35013 — V2 request-byte envelope can bypass auto-compaction