[Bug] OpenRouter `z-ai/glm-4.5-air:free` fails in local tool loop runner with `Tool choice must be auto`

[woefy]

What happened / 发生了什么

In AstrBot local agent runner (tool loop runner), tool calling fails when using the OpenRouter model z-ai/glm-4.5-air:free.

The request returns:

openai.BadRequestError: 400 Tool choice must be auto

From local logs and code investigation, AstrBot local runner explicitly passes:

tool_choice="required"

in some tool-calling stages, while this OpenRouter model path appears to require:

tool_choice=auto

As a result, the downstream request is rejected.

---

Reproduce / 如何复现

Current real-world scenario:

• AstrBot local agent runner
• chat provider through OpenRouter
• model: z-ai/glm-4.5-air:free
• a conversation that triggers tool calling (in my case, an image-generation related request)

The failure happens in the tool-calling stage.
It does not look like a prompt understanding issue, and it does not look like the image tool itself is failing.

---

Logs / 报错日志

Core error:

openai.BadRequestError: Error code: 400 - ... Tool choice must be auto

Related logs also show:

• openrouter/z-ai/glm-4.5-air:free
• provider_name: Z.AI

The direct issue here appears to be an incompatible tool_choice value during tool calling.

---

Code investigation / 代码排查结果

I found explicit tool_choice="required" calls in AstrBot local runner:

• astrbot/core/agent/runners/tool_loop_agent_runner.py:1002
• astrbot/core/agent/runners/tool_loop_agent_runner.py:1035

The provider abstraction also allows:

• auto
• required

Relevant file:

• astrbot/core/provider/provider.py

And the OpenAI-compatible source forwards this value into the request payload:

• astrbot/core/provider/sources/openai_source.py

So the current path appears to be:

1. local tool loop runner forces tool calling with tool_choice="required"
2. openai_source forwards it downstream
3. downstream path is OpenRouter -> z-ai/glm-4.5-air:free
4. that path rejects this and expects auto
5. request fails with 400 Tool choice must be auto

---

Expected behavior / 期望行为

For models like OpenRouter z-ai/glm-4.5-air:free that do not accept tool_choice="required", AstrBot should ideally do one of the following:

1. downgrade to tool_choice="auto" in runner logic
2. handle compatibility in the OpenAI/OpenRouter provider adapter
3. detect incompatible models earlier and avoid sending an unsupported request

---

Additional notes / 补充说明

• This issue happens when using OpenRouter with z-ai/glm-4.5-air:free.
• I have not tested whether a direct native Zhipu/Z.AI provider call behaves the same way, so this report is only about the OpenRouter path.
• Since glm-4.5-air is already a relatively older model, maintainers can evaluate whether this specific compatibility issue is worth fixing. Even if no fix is planned, documenting this limitation would still be helpful.
• This issue text was organized with the help of an OpenClaw agent, then reviewed and confirmed by the user before posting.

[dosubot]

Hi @woefy! I'm Dosu and I’m helping the AstrBot team.

你的分析非常准确。tool_choice="required" 是在 _resolve_tool_exec() 方法中的两阶段重试机制里使用的——当初次查询没有返回 tool call 时，runner 会用 tool_choice="required" 强制重试 [1]。OpenRouter 代理到 z-ai/glm-4.5-air:free 时，该后端不支持 required，因此直接返回 400 错误。

相关上下文：

• PR #7101 引入了 tool_choice 参数，但目前 provider 适配层（OpenAI / Anthropic / Gemini）没有针对 OpenRouter 做兼容处理 [2]。
• PR #7164 新增了 tool_capability_strategy 配置，可以处理完全不支持 tool call 的模型，但不能解决"支持 tool call 但不支持 required"这种场景。

可能的修复方向：

1. 在 _resolve_tool_exec() 的重试逻辑中，如果 tool_choice="required" 调用失败（捕获 400 错误），自动降级为 tool_choice="auto" 重试。
2. 在 openai_source.py 层面，对已知不支持 required 的 provider/model 做映射或 fallback。
3. 暴露一个配置项让用户指定某些模型只允许 auto。

作为临时 workaround，如果你能修改本地代码，可以将 tool_loop_agent_runner.py 中两处 tool_choice="required" 改为 tool_choice="auto"，但这会影响所有模型的重试行为。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[Astral-Yang]

确实，我使用AxonHub的中转站也有遇到这个问题，Axon的请求头复写可以解决这个问题就是，openrouter的话应该要做兼容处理了