You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
V2 TUI silently succeeds on empty length turns until manual compaction #52015
In OpenCode v2.0.18's TUI, a long session stopped answering despite accepting prompts. Four consecutive assistant turns were stored with finish: "length", tokens.output: 0, and empty assistant content. Each was followed by an idle outcome of succeeded; the TUI showed no error. Manually running compaction made the session work again.
The model used an OpenAI-compatible provider and was configured for 1,050,000 context tokens and 128,000 output tokens. Input including cache rose from 921,222 to 921,238 tokens while reasoning fell from 344 to 328; input plus reasoning stayed at 921,566 for all four turns. No automatic compaction was recorded. This is consistent with context pressure, though the source of the effective cap is unconfirmed.
Expected: automatic recovery when safe, or a visible truncation error. An empty turn should not be marked successful. Related reports: #44609, #50949, and #37372; this report adds a v2.0.18 TUI reproduction and manual-compaction recovery.
Plugins
No plugin tool call occurred in the failing turns.
OpenCode version
v2.0.18
Steps to reproduce
Use a reasoning model with a long, tool-heavy TUI session until input including cache is about 921,000 tokens under the limits above.
Submit a normal request, then short follow-ups. The model runs, but no answer or error appears.
Manually compact the session. Responses work again.
This is #50949 (already flagged as the duplicate). A fix is open in #51741.
The change: a normalized length finish with no streamed output now fails the Step with a visible error instead of settling as a success, so an empty turn stops looking like a healthy one. Partial output is unaffected - a length finish that streamed any content still settles normally with its visible text - and a length finish with tool calls still continues.
Your detail that manual compaction recovers the session is consistent with the same code path: nothing marks the empty turn as failed, so there is no reason to surface an error or recover automatically. #51741 makes the failure visible; it does not add automatic recovery, which is the separate ask tracked in #44609.
Activity
github-actions commentedon Sep 29, 2026
This issue might be a duplicate of existing issues. Please check:
finish_reason: "length"empty/zero-output response is treated as a successful turn with no visible error.lengthcompletion before assistant output, with compaction and retry proposed as recovery.lengthfinish with zero visible output while the session succeeds.lengthturns being recorded as normal completions, especially when no usable output was produced.Veld101 commentedon Sep 29, 2026
This is #50949 (already flagged as the duplicate). A fix is open in #51741.
The change: a normalized
lengthfinish with no streamed output now fails the Step with a visible error instead of settling as a success, so an empty turn stops looking like a healthy one. Partial output is unaffected - alengthfinish that streamed any content still settles normally with its visible text - and alengthfinish with tool calls still continues.Your detail that manual compaction recovers the session is consistent with the same code path: nothing marks the empty turn as failed, so there is no reason to surface an error or recover automatically. #51741 makes the failure visible; it does not add automatic recovery, which is the separate ask tracked in #44609.