Repository navigation
[Bug]: OpenCode run on oversized session fails with opaque provider.invalid-request, orphaned opencode serve #20142
Description
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-requeston 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
- 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-contributorvariantxhigh). - Send another message (run ordinal 12). The provider turn executes tool calls successfully, then the next model step fails.
- 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 istype: "error",title: "Provider error", withfailure: {"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=42343process 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.
Activity
ImBIOS commentedon Oct 16, 2026
Second data point confirming the diagnosis: a fork of the affected thread (forked from run 11, same model) failed identically on its first run at 2026-10-16T04:07:04Z — two tool calls succeeded, then the next model step ended with the same terminal
provider.invalid-request/Failed to drain Session ... invalid parametersin the opencode log. Forking from the latest run does not shed the oversized history, so Retry/fork-in-place cannot recover; only a fresh thread (or fork from a much earlier point) works. A third identical failure from another run was logged the same day at 03:41:46Z.ImBIOS commentedon Oct 22, 2026
Third occurrence, now in a different project (a second private project) — so this is not specific to one thread's history. 12 completed-or-long runs, 925 turn items, 166 messages; run 12 failed at 2026-10-22T10:38:34Z with the identical terminal failure (provider.invalid-request, same message), matching Failed to drain Session in the opencode log at the same second. Notably, the run also shows the model emitting a malformed tool call just before the end (shell call with missing command arg rejected client-side), consistent with degraded model behavior once the session gets this large — the provider then rejects the follow-up request outright. Same model family (opencode-go/muse-spark, xhigh).
ImBIOS commentedon Oct 23, 2026
Fourth occurrence, another project (a third private project): 5 runs, 674 items, 101 messages, run 5 failed at 2026-10-22T23:50:08Z with the same terminal provider.invalid-request, matching Failed to drain Session in the opencode log to the second. New observation on the lead-up: the run flailed for ~25 minutes first — dozens of failed command_execution / file_change items and a ~10-minute stall — before the provider rejected the request outright. Same model family (opencode-go/muse-spark, xhigh). Pattern is consistent: oversized sessions degrade visibly, then die opaquely.
ImBIOS commentedon Oct 23, 2026
Fifth occurrence, the largest yet (a fourth private project): 23 runs, 1348 items, 194 messages, run 23 failed at 2026-10-23T01:53:29Z with the identical terminal provider.invalid-request, matching Failed to drain Session in the opencode log to the second. Same model family (opencode-go/muse-spark, xhigh). Pattern holds: very long sessions die opaquely.
ImBIOS commentedon Nov 6, 2026
Sixth occurrence, same signature, with two new observations.
Instance: thread
c47e7d0b("Build Better FastBots Alternative"), projectpassoff, server 0.1.8-nightly.20261106.4247 (myrehat-dev, Linux). Modelopencode-go/muse-spark-1.3-contributorvariantxhighvia local CLIProxy pool. Only 4 runs / ~100+ turn items — much smaller than prior instances, so size alone is not the trigger here.Timeline:
timeout: "60000</atem:phase>NEEDS_FIX",timeout: "60000</Tamil tag>",timeout: "90000</atem:phase>NEEDS_FIX"(strings with garbage XML tags where a number belongs), pluscommand: {}andinput: "x". Each rejected client-side ("Invalid arguments for tool shell"). Then terminal failure:type: "error",title: "Provider error",failure: {"class": "provider_error", "message": "The request contains invalid parameters...", "code": "provider.invalid-request"}at 2026-11-05T02:50:18Z.ses_e5b9ba11...) and can never succeed.Both match
Failed to drain Session cause="AI.Error: The request contains invalid parameters..."in the opencode serve log to the second. Noatem:/NEEDS_FIXstrings exist anywhere in the worktree (checked excluding node_modules/.git/.next) — not prompt injection; model-side generation glitch.New data point 1 — verified recovery: started a fresh thread in the same project with a handoff prompt (same model). It ran
completed: pool health-check passed and it finished the interrupted Chrome-QA task. Confirms only a fresh provider session recovers; retry-in-place is hopeless.New data point 2 — CLI gap:
t3 thread send/starthas no fresh-context or fork option, so recovery required a manual new thread via SSH + local CLI (t3_thread_sendover a linked environment is also denied when links are off). A supported "retry this thread with a fresh provider session" path (CLI + UI) would have made this a one-click fix.