[Feature] free可以使用glm吗

[oaskdosakdoakd]

我把free改为了pro后可以使用glm-5.1但是无法写文件和调用mcp
明明在官方ide中是可以调用的,有办法做到吗

[alen978]

同问，5.1现在已经可以处理很多事情了。对代码要求不那么高的都可以了。这个free是很大的利好呀，为什么不能调用？

[will00768-max]

可以用，还有kimi2.5

[KLFDan0534]

+1,调用的时候提示invalid tool

[dwgx]

这事儿不是把 free 改 pro 就能稳定解决。

GLM / Kimi / SWE 这类模型能不能在 free tier 跑，取决于三件事：

1. 上游 allowlist — Windsurf 那边的 userTier 探测决定哪些模型能调，不是 dashboard 这边能拍板的
2. 模型本身的 tool 协议兼容 — 评论里出现的 invalid tool 可能是 GLM 不接受当前 tool schema 的格式（比如 strict mode、enum 长度限制），也可能是本仓库的 tool-emulation 路径有问题
3. Routing 决策 — 走 emulation 还是原生 tool_use，对不同模型策略不一样

v2.0.26 已经做过的：

• Tool preamble 三层降级（schema-compact / skinny / names-only）
• free / pro allowlist 探测有改进
• Tool emulation 路径修过几个 buffer 边角

但没有专门验证过 GLM 这条具体路径。

帮我贴：

1. 完整模型名（glm-4.6 / glm-4-flash / 还是别的）
2. 客户端调的 endpoint（/v1/messages 还是 /v1/chat/completions）
3. 请求里 tools 的数量
4. LOG_LEVEL=debug 下找 Probe[...] tools=... 这行
5. 完整错误（不只是 invalid tool，前后 5 行）

暂时不关，等信息。

[zhangzhang-bit]

上下文会丢 有知道啥情况的吗?

[oaskdosakdoakd]

我不清楚,但是我在使用glm-5.1或者其他模型的时候比如我需要调用文件,读取文件等相关操作的时候他就不会操作

gemini-2.5-flash是没问题的

[dwgx]

他在玩你呢

[oaskdosakdoakd]

但是我在windsurf ide中确实可以使用，是上游终止了写入操作?但是ide确实可以写入

[KLFDan0534]

你是在windsurf里面用嘛,还是别的agent,遇到的问题是大模型不能用正确的参数调用模型,而且/home/user/projects/workspace-skxwsx01/src/index.js这个路径也不知道是哪来的,不过claudecode可以调用工具

[oaskdosakdoakd]

我也遇到了这个情况,他会在C:\home\user\projects\workspace-devinxse这个目录创建文件
这是我尝试使用ai来修改这个项目让他可以写入文件后产生的这个情况,你是使用的哪个模型可以写入操作

[KLFDan0534]

我用的是glm5.1这个模型,并且我一直在让wd帮我修改反代项目,这里也是用的glm5.1,我现在同时操作openclaw和claudecode,但是我现在掉用工具的时候经常出错,有时候还会 陷入循环,我的openclaw就可以正常的在workspace创建我要求的文件,不过会调用无用工具

[dwgx]

@oaskdosakdoakd fixed in v2.0.31.

Root cause: GLM/Kimi models were emitting real tool calls, but not in the OpenAI JSON-XML format the parser expected. GLM used its own XML argument format and Kimi used section-token markup, so the proxy treated those outputs as plain text and returned tool_calls=[]. That also broke later context because historical tool calls were replayed in the wrong dialect.

v2.0.31 adds model-specific tool dialect selection, GLM/Kimi parser support, and dialect-aware replay for historical tool calls. Upgrade and retest file/tool operations with GLM or Kimi. If a tool still fails, attach LOG_LEVEL=debug lines around ToolParser:.

[dwgx]

@will00768-max kimi 也修了——v2.0.31 同 patch 加了 Kimi K2 的 section-token 解析（<|tool_calls_section_begin|>...），跟 GLM 一起。kimi-k2-thinking 现在能调工具，跟 gemini-2.5-flash 行为一致。

升级方法跟 GLM 一样：docker compose pull && docker compose up -d 等 GHCR build 完。

[dwgx]

@KLFDan0534 @oaskdosakdoakd 两个症状分开说：

1. "调用工具经常出错 / 陷入循环"

v2.0.31 应该一并修了。原因是上一版 GLM 调用 silently 丢失（parser 不认识 GLM 的 <arg_key>... 格式），模型以为没调成功就反复重试，看起来就是循环 / "invalid tool" / 误调无用工具。glm47 dialect parser 加上之后这条路径走通。

2. "/home/user/projects/workspace-skxwsx01/... / C:\home\user\projects\workspace-devinxse 路径泄露"

这是另一个 bug，跟 v2.0.31 GLM fix 不是同一个。

src/sanitize.js 里有 regex 挡 /home/user/projects/workspace-[a-z0-9]+（Unix 正斜杠），KLFDan 看到的 Unix 路径理论上应该被挡——可能你跑的版本太老（<v2.0.13 还没这套 sanitizer），先升 v2.0.31 再看。

oaskdosakdoakd 看到的 C:\home\user\projects\workspace-devinxse 是 Windows 反斜杠 + C:\ 前缀的混合形式，现有 regex 不匹配。这个我会在 v2.0.32 加防御性 sanitizer 覆盖：

• 反斜杠版本 (\home\user\projects\workspace-...)
• C:\ 等 drive prefix
• 反斜杠正斜杠混合 (C:\home/user/projects/...)

升级 v2.0.31 之后请你们各自再试一下：

• 工具能不能正常调（应该好了）
• 还能不能看到那个 workspace 路径？看到的话贴一下完整的提示行（LOG_LEVEL=debug 找 PathSanitizeStream 或 sanitizeText 附近的 5 行）

@KLFDan0534 你提到 "openclaw 可以正常创建文件、claudecode 经常出错" —— 这个差异有意思。如果 v2.0.31 之后 claudecode 仍然有问题，开个新 issue 详细贴出 claudecode 跑 GLM-5.1 时的完整请求/响应（带 LOG_LEVEL=debug），那是 claudecode 协议适配层的事，不在这个 issue 里追。