Activity

1. opencode-agent commented on Oct 13, 2026

   

   opencode-agentBot

   on Oct 13, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report. I tried this on v2.0.27 with your provider config, pointed at a local mock openai-compatible server instead of Z.AI. With a normal stream that ends in finish_reason: "stop", opencode run "Reply with exactly: OK" printed OK and exited cleanly. So run handles a well-formed stream, and nothing in the request it sent looked specific to run mode.

   That suggests the problem depends on what Z.AI's coding endpoint actually returns to these requests. I can't check that here because it needs a real Z.AI account, so this needs a maintainer who has one.

   If you can, these would help narrow it down:

   • Does opencode run still fail when no other OpenCode session is active on the same API key? That would tell a concurrency limit apart from something about the request itself.
   • Does it fail when run directly from cmd.exe/PowerShell instead of through OpenCode's shell tool, without the shared background service?

   Related, though it looks like a different trigger: #50146 (the same stream ended without finish_reason error, intermittent on GLM streams via OpenCode Go).
2. Israel-Kli commented on Oct 14, 2026

   

   Israel-Kli

   on Oct 14, 2026

   More actions

   I can reproduce the same missing finish_reason failure with Snowflake Cortex's OpenAI-compatible endpoint, specifically for Claude models.

   Environment:

   • opencode v2.0.29
   • provider: built-in snowflake-cortex, @ai-sdk/openai-compatible
   • endpoint: https://<account>.snowflakecomputing.com/api/v2/cortex/v1/chat/completions
   • models tested: claude-sonnet-4-6, claude-opus-5, openai-gpt-5.2

   Session DB evidence from opencode after a successful visible answer from claude-sonnet-4-6:

   "finish":"error",
   "error":{
     "type":"provider.invalid-output",
     "message":"OpenAI Chat stream ended without finish_reason",
     "status":200
   }

   That makes opencode inject the synthetic continuation prompt:

   The previous response was interrupted. Continue from where you left off without repeating completed content.
   

   The direct SSE response explains it. Cortex's Claude stream emits content, then an empty role chunk, then usage, then [DONE]. No chunk contains choices[0].finish_reason:

   data: {"choices":[{"delta":{"content":"...","role":"assistant"},"index":0}],...}
   data: {"choices":[{"delta":{"role":"assistant"},"index":0}],...}
   data: {"choices":[],"usage":{"completion_tokens":25,...},...}
   data: [DONE]
   

   By comparison, the same Cortex OpenAI-compatible endpoint with openai-gpt-5.2 does include the terminal finish chunk:

   data: {"choices":[{"delta":{},"finish_reason":"stop","index":0,...}],...}
   data: {"choices":[],"usage":{"completion_tokens":5,...},...}
   data: [DONE]
   

   Cortex's Anthropic-style endpoint for the same Claude model does provide an explicit stop signal:

   event: message_delta
   data: {"type":"message_delta","delta":{"stop_reason":"end_turn","stop_sequence":null,...},"usage":{...}}
   
   event: message_stop
   

   So this is another OpenAI-compatible provider/model combination where a completed stream can end cleanly with [DONE] but without finish_reason. opencode currently treats it as a failed turn and retries, even though the answer was already delivered.