session: silent idle when response is truncated at output limit (finish=length, empty content) #52490

Summary

When an assistant response is truncated at the model's output-token limit (finish: "length") and no complete part can be parsed out of it, OpenCode records the assistant message with empty content and silently transitions the session to idle. The user sees a session that "just stops doing anything" — no error, no retry, no indication that anything went wrong.

Environment

• opencode version: 2.0.21 (channel: latest)
• OS: Linux 6.17.0-1032-oem (Ubuntu, x64)
• Terminal: TERM=xterm-256color, COLORTERM=truecolor
• Shell: /usr/bin/zsh
• Install/channel: latest (autoupdate enabled)
• Active plugins: opencode-mem (local path plugin)

Reproduction

1. Configure a model with a small output limit (mine was a custom OpenAI-compatible provider with "limit": { "context": 1048576, "output": 8192 } in opencode.json).
2. Give the agent a task that makes it emit one very long tool call (in my case several consecutive steps emitted 2.9k–4.4k output tokens, and the final step produced a single tool call larger than 8192 tokens).
3. Wait for the step to end.

Observed on opencode v2.0.21 against a custom @ai-sdk/openai-compatible provider.

Expected Behavior

When a step ends with finish: "length":

• the truncation should be surfaced to the user (error or warning on the step in the TUI), and/or
• the agent should automatically continue (re-issue the step), or at minimum the session should not appear healthy/idle as if the task finished.

Something like "Response truncated at the 8192-token output limit before any complete tool call was produced" would have saved me a debugging session.

Actual Behavior

The final assistant message is stored with finish: "length", zero parts, and empty content, and the session goes idle with no error anywhere in the UI:

{
  "id": "msg_0f70cb782001l5Ko8xONva8ZuL",
  "time": { "created": 1790851200944, "streamed": 1790851273455, "completed": 1790851273491 },
  "type": "assistant",
  "agent": "build",
  "model": { "id": "GLM-5.3-Flash", "providerID": "<custom-openai-compatible>", "variant": "default" },
  "content": [],
  "finish": "length",
  "rawFinish": "length",
  "tokens": { "input": 140, "output": 8192, "reasoning": 0, "cache": { "read": 40128, "write": 0 } }
}

The preceding assistant steps in the same run emitted 4393 → 3142 → 2917 output tokens, i.e. the model was already trending toward the cap; the truncated step produced no salvageable text or tool call, so the run ended silently.

Nothing appeared in the TUI; the session simply stopped. It is only diagnosable by querying /api/session/:id/message or the server log.

Additional Context

• Frequency: reproduced consistently in the sense that any single response exceeding the configured output cap with no complete part triggers it; happened once in practice during a long task.
• Workaround: resending "continue" re-runs the step; structuring prompts so no single response exceeds the output cap avoids it. A higher output limit in model config also avoids it.
• Possibly related: QuotaExceeded (provider rate limit) halts a session run via Failed to drain Session, which is at least logged; the finish=length case produces no log entry at all at server level beyond normal message storage, which made it harder to spot.
• Note: the 8192 output limit itself comes from my own model config — the bug is purely the silent idle-with-no-error handling of the truncation, not the limit.