[Bug]: OpenCode run on oversized session fails with opaque provider.invalid-request, orphaned opencode serve #20142

Before submitting

• I searched existing issues and did not find a duplicate. (Related but different: [Bug]: OpenCode Go usage limit fails threads as a generic provider error: no reset time, no auto-resume, not exposed to orchestrator MCP tools #16366 covers opencode-go usage limits surfacing as a generic error; [Bug]: OpenCode thread wedges with "Insufficient context allowance" after delegate_task result when model window is unknown #16147 and [Bug]: Provider handoff fails with "Insufficient context allowance" when switching Antigravity instances after usage limit, wedging both #15997 wedge with a clear "Insufficient context allowance" message; Claude "Prompt is too long" (terminal_reason blocking_limit) is shown as "Usage limit reached" #19832 is about mislabeled Claude length errors. This report is an opaque invalid-request on an oversized session, a hard failed run, and an orphaned provider server.)
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Run a long-lived OpenCode thread until the underlying session grows very large (here: 12 T3 runs, 372 thread messages; underlying opencode session ~8.7M input tokens, 771 messages, 3006 parts, model opencode-go/muse-spark-1.3-contributor variant xhigh).
2. Send another message (run ordinal 12). The provider turn executes tool calls successfully, then the next model step fails.
3. Observe the run status and the timeline.

Expected behavior

When the request fails because the session exceeds what the provider accepts, the run should end with an actionable state: e.g. a context-overflow indication telling the user to fork from an earlier checkpoint, compact, or start a fresh thread — the way #16147's path produces "Compact the target conversation or use a larger-context model". Retry of the identical oversized provider thread should not be presented as the path forward, and the per-thread opencode serve process should be reaped when its run terminally fails.

Actual behavior

• The run ends failed. The terminal timeline item is type: "error", title: "Provider error", with failure: {"class": "provider_error", "message": "The request contains invalid parameters. Check the request body for any errors or inconsistencies.", "code": "provider.invalid-request"}. Nothing indicates context size is the cause.
• The opencode server log shows only: Failed to drain Session cause="AI.Error: The request contains invalid parameters. ..." — the same opaque text, no parameter or size detail.
• Retrying the thread reuses the same oversized provider thread, so it fails the same way; the UI offers no fork/compact guidance.
• The per-thread opencode serve --hostname=127.0.0.1 --port=42343 process is still running after the run terminally failed.

Impact

Major degradation or frequent failure

Version or commit

0.0.46-nightly.20261013.3080 (headless t3 serve on Linux)

Environment

Ubuntu 24.04 (GCP VM, x86_64), OpenCode v2.0.30, model opencode-go/muse-spark-1.3-contributor variant xhigh

Logs or stack traces

timestamp=2026-10-14T14:43:01.067Z level=ERROR run=<id> message="Failed to drain Session" cause="AI.Error: The request contains invalid parameters. Check the request body for any errors or inconsistencies.
    at UJ (/$bunfs/root/chunk-fg4bsngy.js:6:3619)
    ...
    [cause]: AI.Error.InvalidRequest: The request contains invalid parameters. Check the request body for any errors or inconsistencies.
      at yf (/$bunfs/root/chunk-fg4bsngy.js:6:1078)
      ...
}" role=server sessionID=ses_<redacted>

Run row: status: "failed", requestedAt: 2026-10-14T14:40:33Z, completedAt: 2026-10-14T14:43:01Z. Provider thread row stays idle.

Workaround

Fork the thread from an earlier checkpoint (or start a fresh thread) instead of retrying; keep sessions short. Manually kill the orphaned opencode serve for the failed run.