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
bug(go): GLM streaming can finish tool_calls without emitting the call #56227
OpenCode Go glm-5.3-flash can finish a streamed Chat Completions response with finish_reason: "tool_calls" without sending any delta.tool_calls containing the function name or arguments. The same request with stream:false returns a complete message.tool_calls array. This leaves an OpenAI-compatible client with no tool to execute.
This is intermittent. A minimal forced-tool comparison succeeded in both modes on a later attempt. Application requests that require tools have repeatedly hit the missing-call result; plain text replies work. Using complete JSON responses avoids the failure.
Plugins
None. Direct Go API requests from a custom OpenAI-compatible client.
OpenCode version
Go API at https://opencode.ai/inference/go/v1/chat/completions, observed on 2026-10-16.
Steps to reproduce
Send the payload below with a valid Go credential, an application user agent, and a stable x-opencode-session header. Compare stream:true with stream:false while leaving the other fields unchanged.
A tool-call finish should include its call ID, function name and argument string in the streamed deltas. Could you check whether the Go GLM streaming relay drops these fields? No credentials or private request content are included here.
Operating System
Linux, Bun client. This occurs at the HTTP response boundary.
Thanks for the detailed report and the payload. I couldn't reproduce this here: it happens in the hosted OpenCode Go API, and testing it needs real glm-5.3-flash requests with a Go credential, which this environment doesn't have. A maintainer with Go access will need to check it.
If it happens again, the raw SSE stream of a failing stream:true response would help a lot: all the data: lines, including the final chunk with finish_reason: "tool_calls", plus the response id and a timestamp. Please remove any credentials first.
Thanks for the report. This was seen with a custom client against the hosted Go API rather than in OpenCode, and it hasn't been reproduced: your own minimal test later worked in both modes. We can't trace hosted-API issues like this without request IDs. If it happens again, please email [email protected] with the response id of a failing stream: true request, a UTC timestamp and the raw SSE stream if you can capture it.
Activity
opencode-agent commentedon Oct 16, 2026
Thanks for the detailed report and the payload. I couldn't reproduce this here: it happens in the hosted OpenCode Go API, and testing it needs real
glm-5.3-flashrequests with a Go credential, which this environment doesn't have. A maintainer with Go access will need to check it.If it happens again, the raw SSE stream of a failing
stream:trueresponse would help a lot: all thedata:lines, including the final chunk withfinish_reason: "tool_calls", plus the responseidand a timestamp. Please remove any credentials first.Related issues:
null-filledtool_callscontinuation deltas when streaming. It's the same relay, but there the deltas are malformed rather than missing.finish_reason: "tool_calls"with an empty delta) on a different model (fledge-alpha-free), reported against v1.opencode-agent commentedon Oct 18, 2026
Thanks for the report. This was seen with a custom client against the hosted Go API rather than in OpenCode, and it hasn't been reproduced: your own minimal test later worked in both modes. We can't trace hosted-API issues like this without request IDs. If it happens again, please email [email protected] with the response
idof a failingstream: truerequest, a UTC timestamp and the raw SSE stream if you can capture it.