GLM 4.7 on Zai coding plan puts tool calls inside the thinking/reasoning tag.

Description

This happens to me about 15 times a day, and it forces me to start a new session because the session with that call in the thinking tag keeps happening and more errors and failures to call the right tools starts to happen.

Restarting in a new session it will go an hour or so before doing it again and needing a restart.

OpenCode version

1.0.223

Steps to reproduce

Choose Zai coding plan and give it your API Key.
Use GLM 4.7 for awhile.
It usually happens after context goes above 100k.

Screenshot and/or share link

Operating System

macOS 26.1

Terminal

Kitty

p.s. OpenCode is awesome.

This issue might be a duplicate of existing issues. Please check:

Error "reasoning part reasoning-0 not found" from tool calls using GLM 4.5 Air #6486: Error "reasoning part reasoning-0 not found" from tool calls using GLM 4.5 Air

Both issues involve GLM models having problems with reasoning/thinking tags and tool calls, though with different error messages. Checking #6486 may provide additional context for understanding and fixing the issue.

Feel free to ignore if this doesn't address your specific case.

This is actually handy. I was wondering when we would see such thing. Basically during the reasoning phase, the model could use a tool call to enrich its reasoning.

This is actually handy. I was wondering when we would see such thing. Basically during the reasoning phase, the model could use a tool call to enrich its reasoning.

Definitely. I am not saying it's a horrible thing that it's calling a tool while reasoning, but isn't the best that the tool call doesn't actually happen and the session gets into a weird state for me.

how consistent is this?

@rekram1-node

@rekram1-node haha, Interleaved thinking
We support interleaved thinking by default (supported since GLM-4.5), allowing GLM to think between tool calls and after receiving tool results. This enables more complex, step-by-step reasoning: interpreting each tool output before deciding what to do next, chaining multiple tool calls with reasoning steps, and making finer-grained decisions based on intermediate results. https://docs.z.ai/guides/capabilities/thinking-mode

@msmirnyagin

@msmirnyagin we do send reasoning content back under the reasoning_content field, hmmm

Ill look

Only thing I see that may be an issue is “clear_thinking”: false but for the coding plan it says enabled by default hm

@greggh

@greggh anyway u could share a session this happened?

opencode export > session.json

Are you using any plugins that could be interferring?

I also encountered the same issue. It doesn't happen all the time, and I'm not sure what triggers it.

I have also encountered this situation, especially when the context is long (>128k). I guess this is because glm4.7 was further trained based on glm4.5, and glm4.5 only supports a 128k context. This also explains why glm4.7’s accuracy declines beyond 100k, starts speaking nonsense, and mixes Chinese and English.

This is purely speculation without any evidence. Basically, when the context reaches around 100k, I manually execute /compact to avoid this issue.

Did anyone checked if this also happens in any other agentic coding Environment besides opencode? I guess this is not a opencode only problem. I think this is an problem within the model itself. Fastes workaround is to set the Context lenght to 128000 instead of 200000

This is also happening on other models in OpenCode, like Kimi K2.

I'm getting the same thing, e.g.

Thinking: bash<arg_key>command</arg_key><arg_value>./split-mbox-emails.py 1-to-split/*.mbox 2>&1 | head -10</arg_value><arg_key>description</arg_key><arg_value>Test split script on glob pattern</arg_value></tool_call>

@rekram1-node

session.json

@rekram1-node my issue session exported data.

I did some research. I think it is because glm, or models with this issue, have special tags in their think outputs. And these models tend to keep an untouched context ( both system, tools, skills, mcps + history + user ) not only to reach a high cache hit rate but also do a better logical deduction. Therefore, context prune operation jumps in the middle of strong logical deduction chain will cause serious issue. That is way this problem happens primarily in the main agent.

I am using o-my-o, appending the following prompt, seems working.

"sisyphus": {
"model": "zhipuai-coding-plan/glm-5",
"tasks": { "enabled": true },
"prompt_append": "Do not prune/compress context too often. prune/compress only after a stage work, or everything, is done"
}

I did some research. I think it is because glm, or models with this issue, have special tags in their think outputs. And these models tend to keep an untouched context ( both system, tools, skills, mcps + history + user ) not only to reach a high cache hit rate but also do a better logical deduction. Therefore, context prune operation jumps in the middle of strong logical deduction chain will cause serious issue. That is way this problem happens primarily in the main agent.

I am using o-my-o, appending the following prompt, seems working.

"sisyphus": { "model": "zhipuai-coding-plan/glm-5", "tasks": { "enabled": true }, "prompt_append": "Do not prune/compress context too often. prune/compress only after a stage work, or everything, is done" }

Does opencode prune frequently? Does it only happen when user input /compact or the context is too long? I met these problems after the context's length reaches 100K+.

@SupetZYK

@SupetZYK there is an option in config compaction.prune which will frequently prune the tool output, defaults to true. but I dont know if it is related to this problem.

@heimoshuiyu

@SupetZYK there is an option in config compaction.prune which will frequently prune the tool output, defaults to true. but I dont know if it is related to this problem.

@heimoshuiyu Thanks for replying. I read the GLM's thinking mode [https://docs.z.ai/guides/capabilities/thinking-mode] . It seems that GLM does not exec the tool inside thinking. It only exec the tool outside the thinking. So prune tool outputs does not change the thinking content.

I did some research. I think it is because glm, or models with this issue, have special tags in their think outputs. And these models tend to keep an untouched context ( both system, tools, skills, mcps + history + user ) not only to reach a high cache hit rate but also do a better logical deduction. Therefore, context prune operation jumps in the middle of strong logical deduction chain will cause serious issue. That is way this problem happens primarily in the main agent.
I am using o-my-o, appending the following prompt, seems working.
"sisyphus": { "model": "zhipuai-coding-plan/glm-5", "tasks": { "enabled": true }, "prompt_append": "Do not prune/compress context too often. prune/compress only after a stage work, or everything, is done" }

Does opencode prune frequently? Does it only happen when user input /compact or the context is too long? I met these problems after the context's length reaches 100K+.

prune tools, no matter opencode's built-in or oh-my-opencode's built-in, or dynamic-context-prune project, they prune the context according to percentage of usage. To be more general, prune timing or scale is basically not linked to the logical deduction chain nowadays. reading glm's think docs, or anthrophic's caching logic, they all requires the recent context being stable, the user->thinking->tool->thinking->... logical chain being intact, because this whole block is used as sort of the input. You are right about prune tool outputs not changing the thinking content, but any summarize/prune/compress in the middle of a continue logic chain does drop details. And my guess is that this changes the mapping to model's internal logical block. (sort like hash changing). anyway , after I adding this prune constrain, glm-5 never breaks. you can just add this line to the static injection file, it should be a global constrain

@ziqingage

I did some research. I think it is because glm, or models with this issue, have special tags in their think outputs. And these models tend to keep an untouched context ( both system, tools, skills, mcps + history + user ) not only to reach a high cache hit rate but also do a better logical deduction. Therefore, context prune operation jumps in the middle of strong logical deduction chain will cause serious issue. That is way this problem happens primarily in the main agent.
I am using o-my-o, appending the following prompt, seems working.
"sisyphus": { "model": "zhipuai-coding-plan/glm-5", "tasks": { "enabled": true }, "prompt_append": "Do not prune/compress context too often. prune/compress only after a stage work, or everything, is done" }

Does opencode prune frequently? Does it only happen when user input /compact or the context is too long? I met these problems after the context's length reaches 100K+.

prune tools, no matter opencode's built-in or oh-my-opencode's built-in, or dynamic-context-prune project, they prune the context according to percentage of usage. To be more general, prune timing or scale is basically not linked to the logical deduction chain nowadays. reading glm's think docs, or anthrophic's caching logic, they all requires the recent context being stable, the user->thinking->tool->thinking->... logical chain being intact, because this whole block is used as sort of the input. You are right about prune tool outputs not changing the thinking content, but any summarize/prune/compress in the middle of a continue logic chain does drop details. And my guess is that this changes the mapping to model's internal logical block. (sort like hash changing). anyway , after I adding this prune constrain, glm-5 never breaks. you can just add this line to the static injection file, it should be a global constrain

@ziqingage Thanks for your detailed explanation. I will try the suggestion. I still have some questions about the prune mechanism. The prompt "Do not prune/compress context too often. prune/compress only after a stage work, or everything, is done" is fed to the LLM, while the pruning process is automatically executed by the program, eg, context limit reach. So how does this prompt work?

I did some research. I think it is because glm, or models with this issue, have special tags in their think outputs. And these models tend to keep an untouched context ( both system, tools, skills, mcps + history + user ) not only to reach a high cache hit rate but also do a better logical deduction. Therefore, context prune operation jumps in the middle of strong logical deduction chain will cause serious issue. That is way this problem happens primarily in the main agent.
I am using o-my-o, appending the following prompt, seems working.
"sisyphus": { "model": "zhipuai-coding-plan/glm-5", "tasks": { "enabled": true }, "prompt_append": "Do not prune/compress context too often. prune/compress only after a stage work, or everything, is done" }

Does opencode prune frequently? Does it only happen when user input /compact or the context is too long? I met these problems after the context's length reaches 100K+.

prune tools, no matter opencode's built-in or oh-my-opencode's built-in, or dynamic-context-prune project, they prune the context according to percentage of usage. To be more general, prune timing or scale is basically not linked to the logical deduction chain nowadays. reading glm's think docs, or anthrophic's caching logic, they all requires the recent context being stable, the user->thinking->tool->thinking->... logical chain being intact, because this whole block is used as sort of the input. You are right about prune tool outputs not changing the thinking content, but any summarize/prune/compress in the middle of a continue logic chain does drop details. And my guess is that this changes the mapping to model's internal logical block. (sort like hash changing). anyway , after I adding this prune constrain, glm-5 never breaks. you can just add this line to the static injection file, it should be a global constrain

@ziqingage Thanks for your detailed explanation. I will try the suggestion. I still have some questions about the prune mechanism. The prompt "Do not prune/compress context too often. prune/compress only after a stage work, or everything, is done" is fed to the LLM, while the pruning process is automatically executed by the program, eg, context limit reach. So how does this prompt work?

to me, prune decisions (timing, scale, method), should be logic based, this means the pruning should not be executed deterministically, by some hardrule like usage. The usage only serves as constrain, not initiator. ultimately, the AI should be responsible for making this decision. In this sense, LLM side knows the context limit, you don't need to worry about that. GLM might not be very smart on this part at this stage, so we need this constrain explicitly from our side.
local program like xxxcode, is merely a task pool, think each task as a c++ function, and context as its stack. you do not blow up your stack by writing a huge function. so, if you are worried about your context limit, maybe you should split your tasks into smaller part.

I'm running into the same issue of tool calls inside thinking blocks with qwen3.5-35b-a3b (Qwen3 30B A3B 2507 according to OpenCode), but for me, the context size does not matter. It can happen with 10k tokens, it can happen with 80k tokens.

Might also be related to quantization. This has happened less since I selected providers more carefully.

To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Navigation Menu

Repository navigation

GLM 4.7 on Zai coding plan puts tool calls inside the thinking/reasoning tag. #6708

Description

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

16 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

GLM 4.7 on Zai coding plan puts tool calls inside the thinking/reasoning tag. #6708

Description

Description

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Activity

github-actions commented on Jan 2, 2026

arsham commented on Jan 2, 2026

greggh commented on Jan 2, 2026

rekram1-node commented on Jan 2, 2026

msmirnyagin commented on Jan 3, 2026

rekram1-node commented on Jan 3, 2026

rekram1-node commented on Jan 3, 2026

FurryWolfX commented on Jan 3, 2026

heimoshuiyu commented on Jan 3, 2026

16 remaining items

greggh commented on Jan 28, 2026

bdwelle commented on Feb 6, 2026

meritozh commented on Feb 28, 2026

ziqingage commented on Mar 7, 2026

SupetZYK commented on Mar 8, 2026

heimoshuiyu commented on Mar 8, 2026

SupetZYK commented on Mar 8, 2026

ziqingage commented on Mar 8, 2026

SupetZYK commented on Mar 8, 2026

ziqingage commented on Mar 8, 2026

WasserEsser commented on Mar 22, 2026

ClemaX commented on Mar 23, 2026

github-actions commented on Jul 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions