Repository navigation
[Bug]: OpenCode thread wedges with "Insufficient context allowance" after delegate_task result when model window is unknown #16147
Description
Activity
Note
Grok responding on behalf of Julius.
Triage
Thanks for such a thorough report, @sree-akkineni! Your reading of the bundled code was spot on, and the numbers match current
main. The error and the stuck thread are the same as #15997, but the cause is different: here it's an OpenCode thread whose measured usage is past the fallback window, with adelegate_taskresult waiting to be delivered.What I found
- When a
delegate_taskfinishes, it writes a readymanual_contexthandoff onto the parent thread (Orchestrator.ts). The next turn prices it withhandoffBudget. If both the storedmaxTokensand the live model window are missing, that function assumes a 128k window and reserves a quarter of it (ContextHandoffBudget.ts). WithusedTokensat 581117, the budget comes out to 0. A real 1M window would leave room. deliverContextHandoffsthen throwsContextHandoffBudgetErrorbefore injecting anything. Thet3_thread_readpointer is only used when its marker fits the budget, so a 0 budget fails the turn instead of deferring. The handoff staysready, later turns pick it up again (ProviderTurnStartService.ts), and each failed turn adds another missed-run handoff. That's why "Status?" and "hi" keep failing.- OpenCode only learns the window from
client.model.list, with a 5 second timeout and errors ignored (OpenCode2AdapterV2.ts,readModels). The directory is marked known when the read starts, so a timeout or failed read isn't retried byreadModelsOnce. Turns that fail in handoff delivery never reach the adapter, so they don't trigger the post-turn catalog retry either. The report doesn't show whethermodel.listtimed out, errored, or omitted this model. /compactdefers delivery when the budget is short instead of failing, so once compaction lowersusedTokensthe queued handoffs go through inline. That matches your workaround.
Likely fix area
- Making the OpenCode window lookup more reliable, for example by retrying a failed or timed-out
model.listinstead of marking the directory known up front. - Having handoff delivery degrade when the budget is 0 (defer it, or use a pointer) instead of failing every turn.
- Revisiting the 128k fallback when measured usage already exceeds it.
A maintainer will decide on the fix direction.
- When a
- added a commit that references this issue
on Oct 9, 2026
Before submitting
delegate_taskresult.Area
apps/server (orchestration v2 context handoff, OpenCode adapter)
Environment
0.0.46-nightly.20261003.2610, macOS arm642.0.22opencode-go/deepseek-v4.1-flash(1M context peropencode models)Steps to reproduce
contextUsage.usedTokenswas ~581k, which is fine for a 1M model.delegate_taskand let it finish. The result is queued as a context handoff (strategy: manual_context,status: ready).Expected behavior
The subagent result is delivered on the next turn (inline, or deferred/pointer if it doesn't fit), and the thread keeps working.
Actual behavior
Every turn fails with:
Provider error: Insufficient context allowance for the provider handoff. Compact the target conversation or use a larger-context model; the current request has not been truncated.Plain messages ("Status?", "hi") fail too, so the thread is unusable until
/compactis run manually. After/compact, the next turn delivered both queued handoffs inline and the thread recovered.Likely cause (from reading the bundled server code)
contextUsagewas{ "usedTokens": 581117 }with nomaxTokens. That means the OpenCode adapter'swindowOf(cwd, model)returned undefined for this thread.readModelsfillscontextWindowsfromclient.model.listwith a 5s timeout and errors ignored, so a slow or failed lookup leaves the window unknown.handoffBudgetthen falls back to a 128k window:128k − 581k − reservegives a budget of 0. Even a short summary handoff can't fit, sodeliverContextHandoffsthrowsContextHandoffBudgetErroron every turn.Suggestions
model.list, or fall back to the model's catalog limit rather than 128k for 1M-context models.t3_thread_readpointer (this already happens when coverage is too large), or show a one-click "Compact and retry" with the error.Workaround
Run
/compactin the thread. To prevent it, cap the model'slimit.context(e.g. 128000) in OpenCode config so OpenCode auto-compacts before T3's fallback window is reached.Note from the reporter
Big fan of the product and happy to be using it. I'm a non-technical user who has gotten proficient with coding agents. My Claude Code was helping me manage T3 and caught this, so take that for what it's worth.