[Bug]: OpenCode thread wedges with "Insufficient context allowance" after delegate_task result when model window is unknown

Before submitting

I searched existing issues and did not find a duplicate. Related: [Bug]: Provider handoff fails with "Insufficient context allowance" when switching Antigravity instances after usage limit, wedging both #15997, which has the same error and the same thread wedging but a different trigger (Antigravity/Pi). This one is OpenCode with a delegate_task result.
I included enough detail to reproduce or investigate the problem.

Area

apps/server (orchestration v2 context handoff, OpenCode adapter)

Environment

T3 Code Nightly 0.0.46-nightly.20261003.2610, macOS arm64
OpenCode 2.0.22
Model opencode-go/deepseek-v4.1-flash (1M context per opencode models)

Steps to reproduce

Run a long OpenCode thread. Here contextUsage.usedTokens was ~581k, which is fine for a 1M model.
From that thread, delegate work to Codex with delegate_task and let it finish. The result is queued as a context handoff (strategy: manual_context, status: ready).
Send any message in the thread.

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 /compact is run manually. After /compact, the next turn delivered both queued handoffs inline and the thread recovered.

Likely cause (from reading the bundled server code)

The provider thread's contextUsage was { "usedTokens": 581117 } with no maxTokens. That means the OpenCode adapter's windowOf(cwd, model) returned undefined for this thread. readModels fills contextWindows from client.model.list with a 5s timeout and errors ignored, so a slow or failed lookup leaves the window unknown.
handoffBudget then falls back to a 128k window: 128k − 581k − reserve gives a budget of 0. Even a short summary handoff can't fit, so deliverContextHandoffs throws ContextHandoffBudgetError on every turn.

Suggestions

Make the OpenCode window lookup reliable: retry model.list, or fall back to the model's catalog limit rather than 128k for 1M-context models.
When the handoff budget is 0, degrade instead of failing the turn. For example, defer the handoff or deliver a t3_thread_read pointer (this already happens when coverage is too large), or show a one-click "Compact and retry" with the error.

Workaround

Run /compact in the thread. To prevent it, cap the model's limit.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.

@sree-akkineni

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 a delegate_task result waiting to be delivered.

What I found

When a delegate_task finishes, it writes a ready manual_context handoff onto the parent thread (Orchestrator.ts). The next turn prices it with handoffBudget. If both the stored maxTokens and the live model window are missing, that function assumes a 128k window and reserves a quarter of it (ContextHandoffBudget.ts). With usedTokens at 581117, the budget comes out to 0. A real 1M window would leave room.
deliverContextHandoffs then throws ContextHandoffBudgetError before injecting anything. The t3_thread_read pointer is only used when its marker fits the budget, so a 0 budget fails the turn instead of deferring. The handoff stays ready, 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 by readModelsOnce. 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 whether model.list timed out, errored, or omitted this model.
/compact defers delivery when the budget is short instead of failing, so once compaction lowers usedTokens the 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.list instead 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.

fix(server): a full target no longer fails every turn on a context ha…

Additional related incident with a Codex parent, rather than OpenCode. This confirms the same handoff error in another provider; it does not establish the missing-model-window root cause described above.

Environment:

Linux desktop AppImage/backend, viewed from the T3 mobile app.
Installed T3 Code: 0.0.46-nightly.20261011.2955 (read from the running application's package metadata).
Installed Codex CLI: 0.162.1; live Codex app-server processes present.
Parent model: gpt-6.1-sol, full-access; long conversation with multiple app-owned delegated repair/review tasks, including gpt-6-luna and gpt-6.1-sol children.

Observed timeline on 2026-10-11 (UTC), from t3_thread_read durable activity and run state:

Parent run 28 started at 07:18:37.350.
Its last normal tool result was at 07:33:19.363; a compaction activity item became running at 07:33:19.399.
Several child results/notifications arrived afterward (including at 07:45, 08:13, and 08:23), but no subsequent parent provider activity appeared. A user status message at 08:57:21 went unanswered. At approximately 09:58, the parent still reported running with the same active run. This was over two hours without coordinator progress.
At 09:59:41, t3_thread_send(mode="restart") returned delivery="restarted", status="starting", and the same run 28 ID. At 10:00:30, there was still no new provider activity; the thread remained starting. The accepted restart receipt did not demonstrate actual recovery.
The user pressed Stop. At 10:00:51.981, durable activity recorded interruption with Run interrupted before provider start.

A mobile Continue message started run 29 at 10:01:16. It failed at 10:01:16.897 with the exact 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.

The user sent /compact at 10:01:34.162. Run 30 started and recorded Compacting context at 10:01:34.958. The user subsequently confirmed that manual /compact, followed by resuming with a new message, fixed the thread and restored progress. Stop followed by another ordinary message alone had produced the handoff error above.

A recurring child monitor also stalled on an older active turn while newer scheduled turns accumulated (latest queued ordinal observed: 225). We paused that existing schedule to prevent further queue growth. This may be a separate failure; it is not evidence that the monitor caused the parent's stall. Another thread in the same app remained responsive, so we have not established a server-wide lockout.

No deterministic reproduction, token/window measurements, raw provider error explaining the original compaction stall, or effect-outbox inspection yet. The hypothesis is that a long conversation plus pending child-result handoffs exhausted the handoff allowance, with compaction/restart failing to recover cleanly; the cause is unconfirmed.

Related but distinct: #17468 (Codex stop/start stalls), #17512 (lost child completion), #17825 (checkpoint capture stalls). Useful investigation areas are bounded compaction/restart recovery, visible restart completion/failure, and deferring queued result handoffs when the allowance is exhausted rather than preventing the parent from resuming.

Sanitized report only: no prompts, raw logs, database, screenshots, host addresses, or local project paths attached.

fix(server): retry deferred handoffs after completed turns

fix(server): retry only explicitly deferred context handoffs

fix(server): retry deferred handoffs after completed turns

fix(server): retry only explicitly deferred context handoffs

fix(server): retry deferred handoffs after completed turns

fix(server): retry only explicitly deferred context handoffs

fix(server): retry deferred handoffs after completed turns

fix(server): a handoff too large for the context window no longer wed…

Additional verified incident on macOS arm64, T3 0.0.46-nightly.20261015.3145, Codex parent gpt-6-astra, with app-owned Claude subagents. Reporting here following the duplicate guidance on #19768.

This occurred on the older installed build, not on the build containing #22117.

Observed sequence — 20 October 2026, UTC

09:39:58: a delegated-task completion woke the parent; startup failed with:

Insufficient context allowance for the provider handoff. Compact the target conversation or use a larger-context model; the current request has not been truncated.
09:40:59: an ordinary user “resume” message started another run; it failed with the same error at 09:41:08.
With no active parent run, we sent the native /compact command once at 09:42:16.
09:44:37: durable activity recorded Context compacted and the compaction run completed.
Another delegated result arrived during compaction. Its queued notification automatically started the next parent run afterward.
By 09:45:45, the parent had fetched both completed tasks through task_status and read their saved deliverables. No additional “resume” command, model change, fork, global threshold change or server restart was needed.

Evidence was checked through t3_thread_read activity and run states, rather than treating command acceptance as recovery. Token occupancy and the exact handoff-budget calculation were not measured for this occurrence. This is an observed incident and recovery, not a deterministic minimal repro.

Relevant upstream fix / recommendation

While preparing this report, we found #22117 merged at 07:03 UTC today. It removes the redundant subagent-result history handoff, delivers results through the normal completion message with bounded inline content / task_status fallback, and filters legacy result handoffs at startup.

GitHub ancestry confirms that release v0.1.1-nightly.20261020.3401 contains merge commit 4f5ff17172c5f2bde61a09aafb23011ae4d38538. We have not yet upgraded or live-tested that release, so this is not a claim that recovery on our affected installation is verified with the new code.

For this delegated-result trigger, adopting and validating #22117 appears preferable to introducing a separate automatic-compaction policy. #19414 remains relevant to the broader oversized-history-handoff case. The useful acceptance check is that an existing long parent with legacy result records can receive multiple child completions without manual compaction, while preserving result retrieval and delivery acknowledgements; #22117 already includes regression coverage in that direction.

No new or independent root cause is claimed. No private prompts, conversation IDs, local project paths, raw logs, database files or credentials are attached.

fix(server): a full target no longer fails every turn on a context ha…

Note

🤖 Claude Opus 5.5 responding on behalf of Theo

Thanks for the report. One part of this is fixed on main in #22117. Please test on the nightly built from main on 2026-10-21, or on the next stable release. One part is still open: unknown OpenCode window still falls back to 128k, so other manual handoffs can still wedge the thread. If that part still matters to you, please open a new issue for that part only.

fix(server): a full target no longer fails every turn on a context ha…

Thanks. I tested the v0.1.2 stable source tag (published 2026-10-22; tag commit 044f072, which includes the #22117 merge commit 4f5ff171) with the targeted server tests on Windows/Node 26.12.1. DelegatedCompletionDelivery.test.ts and ContextHandoffBudget.test.ts passed. In the broader four-file run, ProviderTurnStartService.test.ts had two startup-order assertion failures (cleanup-first and startup-first); both OrchestratorMcpToolkit.integration.test.ts cases failed before their assertions because the test fixture path resolved with a duplicated Windows drive prefix. Overall, 73/77 tests passed. The ProviderTurnStartService.memory.test.ts file named in the PR was absent at the v0.1.2 tag; the result-message regression is present in DelegatedCompletionDelivery.test.ts and passed.

This was source-level regression testing at the stable release tag, not a run of the packaged desktop app or a live OpenCode thread, so I cannot claim a live-use retest.

My additional report here used Codex with a known 475k context window, not the separate unknown-OpenCode-window case. I have no first-hand evidence that the latter affects my report, so I did not open a new issue for it.

Navigation Menu

Repository navigation

[Bug]: OpenCode thread wedges with "Insufficient context allowance" after delegate_task result when model window is unknown #16147

Before submitting

Area

Environment

Steps to reproduce

Expected behavior

Actual behavior

Likely cause (from reading the bundled server code)

Suggestions

Workaround

Note from the reporter

Triage

What I found

Likely fix area

74 remaining items

Observed sequence — 20 October 2026, UTC

Relevant upstream fix / recommendation

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: OpenCode thread wedges with "Insufficient context allowance" after delegate_task result when model window is unknown #16147

Description

Before submitting

Area

Environment

Steps to reproduce

Expected behavior

Actual behavior

Likely cause (from reading the bundled server code)

Suggestions

Workaround

Note from the reporter

Activity

juliusmarminge commented on Oct 5, 2026

Triage

What I found

Likely fix area

Runiir commented on Oct 11, 2026

74 remaining items

davidjd7 commented on Oct 20, 2026

Observed sequence — 20 October 2026, UTC

Relevant upstream fix / recommendation

t3dotgg commented on Oct 21, 2026

dajiaohuang commented on Oct 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions