Opencode with GLM 4.5 String issue #1275

Open
opened 2026-02-16 17:30:15 -05:00 by yindo · 18 comments
Owner

Originally created by @Abdiazizahmedali on GitHub (Aug 12, 2025).

Originally assigned to: @thdxr on GitHub.

opencode stops working in the middle and gives this error ; AI_InvalidResponseDataError: Expected 'id' to be a string.

Originally created by @Abdiazizahmedali on GitHub (Aug 12, 2025). Originally assigned to: @thdxr on GitHub. opencode stops working in the middle and gives this error ; AI_InvalidResponseDataError: Expected 'id' to be a string.
yindo added the model-problem label 2026-02-16 17:30:15 -05:00
Author
Owner

@legout commented on GitHub (Aug 13, 2025):

Same error here

@legout commented on GitHub (Aug 13, 2025): Same error here
Author
Owner

@beyondpixeldesign commented on GitHub (Aug 13, 2025):

I receive the same error message when using the Chutes provider with the GLM 4.5 Air Model. Using the Qwen3 Model via Chutes does work, so it seems to be tied to the GLM models

@beyondpixeldesign commented on GitHub (Aug 13, 2025): I receive the same error message when using the Chutes provider with the GLM 4.5 Air Model. Using the Qwen3 Model via Chutes does work, so it seems to be tied to the GLM models
Author
Owner

@Abdiazizahmedali commented on GitHub (Aug 13, 2025):

Yes exactly i also receive that error via chutes api . Its the GLM models response format i guess. @thdxr Kindly assist to accommodate GLM models better .

@Abdiazizahmedali commented on GitHub (Aug 13, 2025): Yes exactly i also receive that error via chutes api . Its the GLM models response format i guess. @thdxr Kindly assist to accommodate GLM models better .
Author
Owner

@Yesseuki commented on GitHub (Aug 13, 2025):

Seeing the same with openrouter and standard GLM 4.5 model.

@Yesseuki commented on GitHub (Aug 13, 2025): Seeing the same with openrouter and standard GLM 4.5 model.
Author
Owner

@theoriginalaiexplorer commented on GitHub (Aug 15, 2025):

Image

From My experience if you try to jailbreak it asking something it has been asked to not to do. I see this issue.

@theoriginalaiexplorer commented on GitHub (Aug 15, 2025): <img width="1174" height="117" alt="Image" src="https://github.com/user-attachments/assets/a27bf3a5-9078-4059-a6f8-6c80c1172d00" /> From My experience if you try to jailbreak it asking something it has been asked to not to do. I see this issue.
Author
Owner

@cgycorey commented on GitHub (Aug 17, 2025):

I can reproduce this error on v0.5.5 version of Opencode. What I found is that if you use Chutes AI as a provider and choose GLM 4.5 FP8 model, every time when the model create the todo list by calling this tool it shows the above error. Occasionally, when this model called the read file tool it also showed the above. I tried the same model with same provider on Kilo code to check if it is provider's issue but seems it worked fine on that.

@cgycorey commented on GitHub (Aug 17, 2025): I can reproduce this error on v0.5.5 version of Opencode. What I found is that if you use Chutes AI as a provider and choose GLM 4.5 FP8 model, every time when the model create the todo list by calling this tool it shows the above error. Occasionally, when this model called the read file tool it also showed the above. I tried the same model with same provider on Kilo code to check if it is provider's issue but seems it worked fine on that.
Author
Owner

@stickyburn commented on GitHub (Aug 27, 2025):

Facing the same for days now. I think it might be on the model?

@stickyburn commented on GitHub (Aug 27, 2025): Facing the same for days now. I think it might be on the model?
Author
Owner

@aaronnewsome commented on GitHub (Sep 2, 2025):

I'll subscribe to this issue too, as running unsloth's GLM-4.5-Air-UD-Q4_K_XL, served by llama.cpp, using opencode has been a challenge and I'm out of ideas. My opencode.json contains:

"models": {
        "GLM-4.5-Air-UD-Q4_K_XL": {
            "name": "GLM Air 4.5 Q4",
            "tool_call": true,
            "reasoning": true,            
            "options": { "num_ctx": 131072 }
        }
}

I've done some experimentation with removing some of the options or mixing which options to use, but I haven't yet found a magic combination. The read tools seem to be working but trying to use any tools that write files just fails with errors.

The same model served from the same server works 100% in Cline/VSCode, but I'm really looking for a good terminal based coder that works with GLM 4.5, since it's the best model I can run on my local setup. I did try gpt-oss:20b/ollama and it worked with opencode. I assume 120b would also work. I do have qwen3-coder:30b-a3b, which also works nicely with Cline, it's just not as strong as GLM 4.5 air.

Hopefully someone can point me to a working config for opencode, or recommend another capable terminal coder that will work with GLM-4.5, I'm not particularly tied to opencoder since I've never been able to get it to work correctly.

Thank you all, in advance, for your help.

@aaronnewsome commented on GitHub (Sep 2, 2025): I'll subscribe to this issue too, as running unsloth's GLM-4.5-Air-UD-Q4_K_XL, served by llama.cpp, using opencode has been a challenge and I'm out of ideas. My opencode.json contains: ``` "models": { "GLM-4.5-Air-UD-Q4_K_XL": { "name": "GLM Air 4.5 Q4", "tool_call": true, "reasoning": true, "options": { "num_ctx": 131072 } } } ``` I've done some experimentation with removing some of the options or mixing which options to use, but I haven't yet found a magic combination. The read tools seem to be working but trying to use any tools that write files just fails with errors. The same model served from the same server works 100% in Cline/VSCode, but I'm really looking for a good terminal based coder that works with GLM 4.5, since it's the best model I can run on my local setup. I did try gpt-oss:20b/ollama and it worked with opencode. I assume 120b would also work. I do have qwen3-coder:30b-a3b, which also works nicely with Cline, it's just not as strong as GLM 4.5 air. Hopefully someone can point me to a working config for opencode, or recommend another capable terminal coder that will work with GLM-4.5, I'm not particularly tied to opencoder since I've never been able to get it to work correctly. Thank you all, in advance, for your help.
Author
Owner

@uphg commented on GitHub (Sep 10, 2025):

This issue still exists

@uphg commented on GitHub (Sep 10, 2025): This issue still exists
Author
Owner

@aaronnewsome commented on GitHub (Sep 10, 2025):

I was able to get opencode talking to my GLM-4.5-AIR, served by llama.cpp with this chat template

https://huggingface.co/unsloth/GLM-4.5-Air-GGUF/discussions/1

I was even get it to call some tools, write some files but it's about is flaky as they come. Still looking for some guidance from anyone has this setup working. I'm tied to opencode, but I'd be willing to give any competent terminal coder a try. For now, I'll just be happy that Cline seems to work pretty well.

@aaronnewsome commented on GitHub (Sep 10, 2025): I was able to get opencode talking to my GLM-4.5-AIR, served by llama.cpp with this chat template https://huggingface.co/unsloth/GLM-4.5-Air-GGUF/discussions/1 I was even get it to call some tools, write some files but it's about is flaky as they come. Still looking for some guidance from anyone has this setup working. I'm tied to opencode, but I'd be willing to give any competent terminal coder a try. For now, I'll just be happy that Cline seems to work pretty well.
Author
Owner

@jdiaz5513 commented on GitHub (Sep 17, 2025):

This happens when the model hallucinates the tool name and the chat template (on the inference server, like at z.ai) fails to parse it.

See: https://github.com/sst/opencode/issues/2557#issuecomment-3304756831

I wonder if there can be a special case to handle this error message and treat it like a failed tool call (it was going to fail anyway), prompting the LLM to try again.

@jdiaz5513 commented on GitHub (Sep 17, 2025): This happens when the model hallucinates the tool name and the chat template (on the _inference server_, like at z.ai) fails to parse it. See: https://github.com/sst/opencode/issues/2557#issuecomment-3304756831 I wonder if there can be a special case to handle this error message and treat it like a failed tool call (it was going to fail anyway), prompting the LLM to try again.
Author
Owner

@jdiaz5513 commented on GitHub (Sep 18, 2025):

@aaronnewsome you probably want to watch this thread; I've run this branch of llama.cpp locally and tool calling is much better (flawless?) there.

Any inference providers using llama.cpp in production will also benefit from this patch; hard to say if that's going to affect z.ai as well. They may be using vLLM.

@jdiaz5513 commented on GitHub (Sep 18, 2025): @aaronnewsome you probably want to watch [this thread](https://github.com/ggml-org/llama.cpp/pull/15904); I've run this branch of llama.cpp locally and tool calling is much better (flawless?) there. Any inference providers using llama.cpp in production will also benefit from this patch; hard to say if that's going to affect z.ai as well. They may be using vLLM.
Author
Owner

@aaronnewsome commented on GitHub (Sep 19, 2025):

Thanks for the tip @jdiaz5513 , I pulled the latest b6517, applied the pr 15904 and built it. I'm running llama.cpp with the chat template in the PR and opencode is working much, much better. It was working somewhat with the chat template in comments on the GLM-4.5-Air huggingface page, tool calls would succeed but then the chat would just stop instead of continuing to the next step. Super annoying to keep typing "proceed" or "continue" after each and every tool call. Talk about a productivity killer. I'm not seeing the issue any longer with PR 15904. Hopefully the PR gets merged soon, so it's in the main. Again, thank you for the tip.

@aaronnewsome commented on GitHub (Sep 19, 2025): Thanks for the tip @jdiaz5513 , I pulled the latest b6517, applied the pr 15904 and built it. I'm running llama.cpp with the chat template in the PR and opencode is working much, much better. It was working somewhat with the chat template in comments on the GLM-4.5-Air huggingface page, tool calls would succeed but then the chat would just stop instead of continuing to the next step. Super annoying to keep typing "proceed" or "continue" after each and every tool call. Talk about a productivity killer. I'm not seeing the issue any longer with PR 15904. Hopefully the PR gets merged soon, so it's in the main. Again, thank you for the tip.
Author
Owner

@rversteegen commented on GitHub (Nov 1, 2025):

I just had this AI_InvalidResponseDataError: Expected 'id' to be a string error repeatedly from Big Pickle (GLM 4.6) when it tried to edit, and finally I realised I had it in Plan mode...

@rversteegen commented on GitHub (Nov 1, 2025): I just had this `AI_InvalidResponseDataError: Expected 'id' to be a string` error repeatedly from Big Pickle (GLM 4.6) when it tried to edit, and finally I realised I had it in Plan mode...
Author
Owner

@vinicius507 commented on GitHub (Nov 12, 2025):

Same here, except I'm using Bifrost v1.3.24 as a self-hosted LLM gateway with anthropic/claude-sonnet-4-5 model.

Before, I had an issue where OpenCode treats an optional parameter as required on the response. Might be related but it requires further investigation.

@vinicius507 commented on GitHub (Nov 12, 2025): Same here, except I'm using [Bifrost](https://github.com/maximhq/bifrost) v1.3.24 as a self-hosted LLM gateway with `anthropic/claude-sonnet-4-5` model. Before, I had an issue where [OpenCode treats an optional parameter as required on the response](https://github.com/maximhq/bifrost/issues/810). Might be related but it requires further investigation.
Author
Owner

@Ununnilium commented on GitHub (Jan 5, 2026):

I have the error with GLM-4.7 and vLLM. Gemini CLI says that this is a bug in the inference engine (in my case vLLM). According to the OpenAI API specification, an id in the first chunk of a tool call is mandatory. AI SDK is very strict and enforces this: https://github.com/vercel/ai/blob/c041f749c58cd6669a0abadccc7530e8949bf532/packages/openai-compatible/src/chat/openai-compatible-chat-language-model.ts#L464

@Ununnilium commented on GitHub (Jan 5, 2026): I have the error with GLM-4.7 and vLLM. Gemini CLI says that this is a bug in the inference engine (in my case vLLM). According to the OpenAI API specification, an id in the first chunk of a tool call is mandatory. AI SDK is very strict and enforces this: https://github.com/vercel/ai/blob/c041f749c58cd6669a0abadccc7530e8949bf532/packages/openai-compatible/src/chat/openai-compatible-chat-language-model.ts#L464
Author
Owner

@stromseng commented on GitHub (Jan 16, 2026):

See my short writeup at https://github.com/BerriAI/litellm/issues/13124#issuecomment-3759810148 , using GLM 4.7 hosted via litellm and encountering a similar issue.

@stromseng commented on GitHub (Jan 16, 2026): See my short writeup at https://github.com/BerriAI/litellm/issues/13124#issuecomment-3759810148 , using GLM 4.7 hosted via litellm and encountering a similar issue.
Author
Owner

@Ununnilium commented on GitHub (Jan 18, 2026):

For me, it just works now with GLM-4.7 after updating to the latest vLLM nightly. I think there was a bug in vLLM which was fixed. It also works through LiteLLM.

For other people having the same problem, you can use mitmproxy to see the exact tool calls in the HTTP responses . First, start mitmweb (part of mitmproxy). Then, before starting opencode, set the following variables:

export no_proxy=localhost,127.0.0.1
export https_proxy=http://127.0.0.1:8080
export http_proxy=http://127.0.0.1:8080
export https_proxy=http://127.0.0.1:8080
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_TLS_REJECT_UNAUTHORIZED=0

Now, try one time the problematic API of the LLM and one time a proper working version (e.g. GLM-4.7 OpenCode Zen) with a simple prompt. You can then compare the HTTP response to the same prompt e.g. with Gemini. With this information, you can the easier report the problem e.g. to the inference engine or the API provider.

@Ununnilium commented on GitHub (Jan 18, 2026): For me, it just works now with GLM-4.7 after updating to the latest vLLM nightly. I think there was a bug in vLLM which was fixed. It also works through LiteLLM. For other people having the same problem, you can use [mitmproxy](https://www.mitmproxy.org/) to see the exact tool calls in the HTTP responses . First, start mitmweb (part of mitmproxy). Then, before starting opencode, set the following variables: ```bash export no_proxy=localhost,127.0.0.1 export https_proxy=http://127.0.0.1:8080 export http_proxy=http://127.0.0.1:8080 export https_proxy=http://127.0.0.1:8080 export HTTPS_PROXY=http://127.0.0.1:8080 export NODE_TLS_REJECT_UNAUTHORIZED=0 ``` Now, try one time the problematic API of the LLM and one time a proper working version (e.g. GLM-4.7 OpenCode Zen) with a simple prompt. You can then compare the HTTP response to the same prompt e.g. with Gemini. With this information, you can the easier report the problem e.g. to the inference engine or the API provider.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#1275