Summary
A simple weather request works in the Pi coding-agent setup with Ollama/Qwen, but fails in OpenClaw TUI local embedded mode with the same model family.
The observed difference appears to be the tool path exposed to the model.
In the Pi coding agent, there is no dedicated weather skill or weather tool involved. Qwen can still handle the request because it has access to a usable execution capability and can call a public weather API directly with curl.
In OpenClaw local embedded mode, the model appears to be steered through compact tool search. It searches for a callable weather tool, does not find one, and then reports that weather access is unavailable instead of using shell/curl.
Environment
- OpenClaw TUI
- Mode: local embedded
- Agent:
main
- Session:
local
- Model:
ollama/qwen3.5:9b
- Request tested:
quel temps fait il à Paris maintenant?
Observed behavior
The first request timed out.
On retry, the assistant responded that it would check the weather in Paris, then searched for weather-related tools:
Tool Search: weather paris
Tool Search: weather
Tool Search: temps
Tool Describe: weather
No callable weather tool was found.
The assistant then concluded that no weather tool was available in the session and replied that it could not provide the current weather.
Comparison with Pi coding agent
In the Pi coding-agent setup, this does not rely on a weather skill.
The model can answer the same kind of request by using the available execution/shell capability and calling a public weather API with curl.
So the observed difference is:
- Pi coding agent: Qwen uses shell/curl successfully.
- OpenClaw local embedded: Qwen searches for a
weather tool and stops when none is found.
Additional observation
In another OpenClaw test, the model attempted to fall back to an execution tool, but used the argument shape cmd.
The OpenClaw Pi execution tool appears to expect command instead.
So even when the model tries a reasonable execution fallback, the call can fail because the exposed tool schema differs from what the model/coding-agent pattern expects.
What makes this confusing
From the user's perspective, the local model can use tools and the Pi coding-agent setup can answer this class of request.
But in the OpenClaw local embedded session, the model cannot discover or successfully use the execution path for the same task.
The failure mode presents as "no weather access available," even though the underlying issue appears to be that the local embedded tool path does not route the model from the live-data request to shell/curl execution.
Minimal reproduction
- Start OpenClaw TUI in local embedded mode.
- Use agent
main, session local.
- Use model
ollama/qwen3.5:9b.
- Ask:
quel temps fait il à Paris maintenant?
- Observe that the assistant searches for a weather tool, fails to find one, and reports that weather access is unavailable.
Expected behavior
If the local embedded session has an execution capability available, the model should be able to use it for simple live-data requests in the same way it does in the Pi coding-agent context.
At minimum, the failure should make clear whether execution is unavailable, hidden behind tool discovery, or failing because of a schema mismatch.
Actual behavior
The OpenClaw local embedded session does not successfully route the model from the weather request to an executable shell/curl path, and the assistant reports that no weather capability is available.
Summary
A simple weather request works in the Pi coding-agent setup with Ollama/Qwen, but fails in OpenClaw TUI local embedded mode with the same model family.
The observed difference appears to be the tool path exposed to the model.
In the Pi coding agent, there is no dedicated weather skill or weather tool involved. Qwen can still handle the request because it has access to a usable execution capability and can call a public weather API directly with
curl.In OpenClaw local embedded mode, the model appears to be steered through compact tool search. It searches for a callable
weathertool, does not find one, and then reports that weather access is unavailable instead of using shell/curl.Environment
mainlocalollama/qwen3.5:9bObserved behavior
The first request timed out.
On retry, the assistant responded that it would check the weather in Paris, then searched for weather-related tools:
No callable weather tool was found.
The assistant then concluded that no weather tool was available in the session and replied that it could not provide the current weather.
Comparison with Pi coding agent
In the Pi coding-agent setup, this does not rely on a weather skill.
The model can answer the same kind of request by using the available execution/shell capability and calling a public weather API with
curl.So the observed difference is:
weathertool and stops when none is found.Additional observation
In another OpenClaw test, the model attempted to fall back to an execution tool, but used the argument shape
cmd.The OpenClaw Pi execution tool appears to expect
commandinstead.So even when the model tries a reasonable execution fallback, the call can fail because the exposed tool schema differs from what the model/coding-agent pattern expects.
What makes this confusing
From the user's perspective, the local model can use tools and the Pi coding-agent setup can answer this class of request.
But in the OpenClaw local embedded session, the model cannot discover or successfully use the execution path for the same task.
The failure mode presents as "no weather access available," even though the underlying issue appears to be that the local embedded tool path does not route the model from the live-data request to shell/curl execution.
Minimal reproduction
main, sessionlocal.ollama/qwen3.5:9b.Expected behavior
If the local embedded session has an execution capability available, the model should be able to use it for simple live-data requests in the same way it does in the Pi coding-agent context.
At minimum, the failure should make clear whether execution is unavailable, hidden behind tool discovery, or failing because of a schema mismatch.
Actual behavior
The OpenClaw local embedded session does not successfully route the model from the weather request to an executable shell/curl path, and the assistant reports that no weather capability is available.