github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-06 16:11:34 -05:00
Code Issues 14.5k Packages Projects Releases 120 Wiki Activity

[GH-ISSUE #14592] Kimi K2.5 (ollama/kimi-k2.5:cloud) cannot call tools in OpenClaw while minimax/qwen work fine #71520

New Issue
Open
opened 2026-05-05 02:02:00 -05:00 by GiteaMirror · 11 comments
GiteaMirror commented 2026-05-05 02:02:00 -05:00
Owner
Copy Link

Originally created by @oggixx on GitHub (Mar 3, 2026).
Original GitHub issue: https://github.com/ollama/ollama/issues/14592

Originally assigned to: @ParthSareen on GitHub.

Describe the bug

Kimi K2.5 (ollama/kimi-k2.5:cloud) cannot call tools in OpenClaw. The model responds with text explanations but never actually invokes tools, while the same prompts work perfectly with minimax-m2.5:cloud and qwen3.5:397b-cloud.

To Reproduce

  1. Set OpenClaw model to ollama/kimi-k2.5:cloud
  2. Ask the model to use a tool (e.g., "Check the weather for Berlin" or "Search the web for OpenClaw news")
  3. The model responds with helpful text but never calls the actual tool
  4. Switch to minimax-m2.5:cloud with same prompt → tool is called immediately

Expected behavior

The model should call tools when needed, just like minimax-m2.5:cloud and qwen3.5:397b-cloud do.

Environment

  • OpenClaw version: 2026.3.2
  • Ollama version: latest
  • Model: ollama/kimi-k2.5:cloud
  • Working models: minimax-m2.5:cloud, qwen3.5:397b-cloud

Additional context

  • ✅ minimax-m2.5:cloud - works perfectly, calls tools immediately
  • ✅ qwen3.5:397b-cloud - works perfectly, calls tools immediately
  • ❌ kimi-k2.5:cloud - responds with text but never calls tools

This appears to be specific to Kimi K2.5's tool calling format/parsing in OpenClaw. The model understands the request and describes what it would do, but the actual tool call JSON is never sent.

Workaround:
Use minimax-m2.5:cloud or qwen3.5:397b-cloud for tool-intensive tasks until this is resolved.

Originally created by @oggixx on GitHub (Mar 3, 2026). Original GitHub issue: https://github.com/ollama/ollama/issues/14592 Originally assigned to: @ParthSareen on GitHub. **Describe the bug** Kimi K2.5 (`ollama/kimi-k2.5:cloud`) cannot call tools in OpenClaw. The model responds with text explanations but never actually invokes tools, while the same prompts work perfectly with minimax-m2.5:cloud and qwen3.5:397b-cloud. **To Reproduce** 1. Set OpenClaw model to `ollama/kimi-k2.5:cloud` 2. Ask the model to use a tool (e.g., "Check the weather for Berlin" or "Search the web for OpenClaw news") 3. The model responds with helpful text but never calls the actual tool 4. Switch to `minimax-m2.5:cloud` with same prompt → tool is called immediately **Expected behavior** The model should call tools when needed, just like minimax-m2.5:cloud and qwen3.5:397b-cloud do. **Environment** - OpenClaw version: 2026.3.2 - Ollama version: latest - Model: `ollama/kimi-k2.5:cloud` - Working models: `minimax-m2.5:cloud`, `qwen3.5:397b-cloud` **Additional context** - ✅ minimax-m2.5:cloud - works perfectly, calls tools immediately - ✅ qwen3.5:397b-cloud - works perfectly, calls tools immediately - ❌ kimi-k2.5:cloud - responds with text but never calls tools This appears to be specific to Kimi K2.5's tool calling format/parsing in OpenClaw. The model understands the request and describes what it would do, but the actual tool call JSON is never sent. **Workaround:** Use minimax-m2.5:cloud or qwen3.5:397b-cloud for tool-intensive tasks until this is resolved.
GiteaMirror added the cloud label 2026-05-05 02:02:00 -05:00
GiteaMirror commented 2026-05-05 02:02:05 -05:00
Author
Owner
Copy Link

@oggixx commented on GitHub (Mar 6, 2026):

Friendly bump – any updates on this? Happy to provide additional logs or test builds if helpful.

<!-- gh-comment-id:4012542505 --> @oggixx commented on GitHub (Mar 6, 2026): Friendly bump – any updates on this? Happy to provide additional logs or test builds if helpful.
GiteaMirror commented 2026-05-05 02:02:07 -05:00
Author
Owner
Copy Link

@MillerApps commented on GitHub (Mar 6, 2026):

I have the same issue, however running the /new bot command renews the session and tools work again for around 5-10 minutes.

<!-- gh-comment-id:4012559420 --> @MillerApps commented on GitHub (Mar 6, 2026): I have the same issue, however running the /new bot command renews the session and tools work again for around 5-10 minutes.
GiteaMirror commented 2026-05-05 02:02:10 -05:00
Author
Owner
Copy Link

@oggixx commented on GitHub (Mar 6, 2026):

@MillerApps Thanks so much for sharing this workaround! Good to know its not just me.

The /new command helping for 5-10 minutes does point to a session expiry issue on Kimi side. However, having to manually renew the session every few minutes isnt really practical for a production setup.

Id really appreciate some official guidance from the @ollama team on this:

  • Is this a known limitation with Kimi K2.5?
  • Are there plans to fix the tool-calling session handling?
  • Any ETA on a proper fix?

Thanks again for the workaround – at least we have something for now! 🦀

<!-- gh-comment-id:4013565941 --> @oggixx commented on GitHub (Mar 6, 2026): @MillerApps Thanks so much for sharing this workaround! Good to know its not just me. The `/new` command helping for 5-10 minutes does point to a session expiry issue on Kimi side. However, having to manually renew the session every few minutes isnt really practical for a production setup. Id really appreciate some official guidance from the @ollama team on this: - Is this a known limitation with Kimi K2.5? - Are there plans to fix the tool-calling session handling? - Any ETA on a proper fix? Thanks again for the workaround – at least we have something for now! 🦀
GiteaMirror commented 2026-05-05 02:02:12 -05:00
Author
Owner
Copy Link

@devTechi commented on GitHub (Mar 9, 2026):

I have the same issue, however running the /new bot command renews the session and tools work again for around 5-10 minutes.

Yes. That is also what I observed. Well, but not all the time they are available for up to 5 minutes. Sometimes less. In first place I never would have guessed, that it was the model itself.

<!-- gh-comment-id:4023962395 --> @devTechi commented on GitHub (Mar 9, 2026): > I have the same issue, however running the /new bot command renews the session and tools work again for around 5-10 minutes. Yes. That is also what I observed. Well, but not all the time they are available for up to 5 minutes. Sometimes less. In first place I never would have guessed, that it was the model itself.
GiteaMirror commented 2026-05-05 02:02:15 -05:00
Author
Owner
Copy Link

@oggixx commented on GitHub (Mar 9, 2026):

@devTechi Thanks for confirming! 👍

Same experience here – the tools work for a few minutes (sometimes 5, sometimes less), then stop responding. It's definitely model-side instability.

Workaround that helps me:

  • Use /new command to start fresh session when tools freeze
  • Switch to qwen3.5:397b-cloud as fallback (more stable for tool calling)
  • Keep sessions short (<5 min) for best reliability

Question: Have you noticed if it's worse with specific tools? I'm seeing it most with file operations and browser commands.

Hope the Ollama team can investigate soon – this is a great model when it works! 🦀

<!-- gh-comment-id:4024129425 --> @oggixx commented on GitHub (Mar 9, 2026): @devTechi Thanks for confirming! 👍 Same experience here – the tools work for a few minutes (sometimes 5, sometimes less), then stop responding. It's definitely model-side instability. **Workaround that helps me:** - Use `/new` command to start fresh session when tools freeze - Switch to `qwen3.5:397b-cloud` as fallback (more stable for tool calling) - Keep sessions short (<5 min) for best reliability **Question:** Have you noticed if it's worse with specific tools? I'm seeing it most with file operations and browser commands. Hope the Ollama team can investigate soon – this is a great model when it works! 🦀
GiteaMirror commented 2026-05-05 02:02:16 -05:00
Author
Owner
Copy Link

@maharoger commented on GitHub (Mar 11, 2026):

I have the same issue, just quit my subscription for ollama pro. Too bad,
Kimi K2.5 (ollama/kimi-k2.5:cloud) was working great until a month ago with openclaw.
Hope this gets resolved soon .

<!-- gh-comment-id:4040709074 --> @maharoger commented on GitHub (Mar 11, 2026): I have the same issue, just quit my subscription for ollama pro. Too bad, Kimi K2.5 (ollama/kimi-k2.5:cloud) was working great until a month ago with openclaw. Hope this gets resolved soon .
GiteaMirror commented 2026-05-05 02:02:17 -05:00
Author
Owner
Copy Link

@oggixx commented on GitHub (Mar 11, 2026):

Is there an alternative way ?

<!-- gh-comment-id:4041854849 --> @oggixx commented on GitHub (Mar 11, 2026): Is there an alternative way ?
GiteaMirror commented 2026-05-05 02:02:19 -05:00
Author
Owner
Copy Link

@maharoger commented on GitHub (Mar 11, 2026):

Workaround: Use Native Ollama API Instead of OpenAI Compatibility

Problem: Kimi-k2.5 via Ollama Cloud has unreliable tool calling when using the OpenAI compatibility layer (/v1 endpoint with api: "openai-completions").

Symptoms: Intermittent HTTP 500 errors, model timeouts, sporadic tool calling failures.

Workaround Tested:

// OpenAI compatibility (problematic)
{
  "baseUrl": "http://127.0.0.1:11434/v1",
  "api": "openai-completions"
}

// Native Ollama API (workaround)
{
  "baseUrl": "http://127.0.0.1:11434",
  "api": "ollama"
}

Note: Successfully tested with OpenClaw 2026.3.8. Results may vary — our environment may include patches that handle trailing characters after valid JSON, which could affect behavior.

Suggestion: If experiencing tool calling issues with kimi-k2.5 via Ollama Cloud, try switching to the native Ollama API ("api": "ollama") and report whether this resolves the intermittent failures.

written by openclaw on kimi-cloud hope it works for others too.

<!-- gh-comment-id:4042654228 --> @maharoger commented on GitHub (Mar 11, 2026): **Workaround:** Use Native Ollama API Instead of OpenAI Compatibility **Problem:** Kimi-k2.5 via Ollama Cloud has unreliable tool calling when using the OpenAI compatibility layer (`/v1` endpoint with `api: "openai-completions"`). **Symptoms:** Intermittent HTTP 500 errors, model timeouts, sporadic tool calling failures. **Workaround Tested:** ```json // OpenAI compatibility (problematic) { "baseUrl": "http://127.0.0.1:11434/v1", "api": "openai-completions" } // Native Ollama API (workaround) { "baseUrl": "http://127.0.0.1:11434", "api": "ollama" } ``` **Note:** Successfully tested with OpenClaw 2026.3.8. Results may vary — our environment may include patches that handle trailing characters after valid JSON, which could affect behavior. **Suggestion:** If experiencing tool calling issues with kimi-k2.5 via Ollama Cloud, try switching to the native Ollama API (`"api": "ollama"`) and report whether this resolves the intermittent failures. written by openclaw on kimi-cloud hope it works for others too.
GiteaMirror commented 2026-05-05 02:02:21 -05:00
Author
Owner
Copy Link

@AndreasMurk commented on GitHub (Mar 13, 2026):

Should be fixed now as of latest OpenClaw3.12 changelog

Image

Can indeed verify that the tool calls are working as expected again

<!-- gh-comment-id:4057885624 --> @AndreasMurk commented on GitHub (Mar 13, 2026): Should be fixed now as of latest OpenClaw3.12 changelog <img width="1136" height="275" alt="Image" src="https://github.com/user-attachments/assets/d94a83cc-3441-4748-882b-b0bf4ba9604d" /> Can indeed verify that the tool calls are working as expected again
GiteaMirror commented 2026-05-05 02:02:22 -05:00
Author
Owner
Copy Link

@devTechi commented on GitHub (Mar 18, 2026):

Yes. It seems to be fixed and working by updating the following and general updates by Ollama.

Workaround: Use Native Ollama API Instead of OpenAI Compatibility

Problem: Kimi-k2.5 via Ollama Cloud has unreliable tool calling when using the OpenAI compatibility layer (/v1 endpoint with api: "openai-completions").

Symptoms: Intermittent HTTP 500 errors, model timeouts, sporadic tool calling failures.

Workaround Tested:

// OpenAI compatibility (problematic)
{
  "baseUrl": "http://127.0.0.1:11434/v1",
  "api": "openai-completions"
}

// Native Ollama API (workaround)
{
  "baseUrl": "http://127.0.0.1:11434",
  "api": "ollama"
}

Note: Successfully tested with OpenClaw 2026.3.8. Results may vary — our environment may include patches that handle trailing characters after valid JSON, which could affect behavior.

Suggestion: If experiencing tool calling issues with kimi-k2.5 via Ollama Cloud, try switching to the native Ollama API ("api": "ollama") and report whether this resolves the intermittent failures.

written by openclaw on kimi-cloud hope it works for others too.

<!-- gh-comment-id:4082807907 --> @devTechi commented on GitHub (Mar 18, 2026): Yes. It seems to be fixed and working by updating the following and general updates by Ollama. > **Workaround:** Use Native Ollama API Instead of OpenAI Compatibility > > **Problem:** Kimi-k2.5 via Ollama Cloud has unreliable tool calling when using the OpenAI compatibility layer (`/v1` endpoint with `api: "openai-completions"`). > > **Symptoms:** Intermittent HTTP 500 errors, model timeouts, sporadic tool calling failures. > > **Workaround Tested:** > > ``` > // OpenAI compatibility (problematic) > { > "baseUrl": "http://127.0.0.1:11434/v1", > "api": "openai-completions" > } > > // Native Ollama API (workaround) > { > "baseUrl": "http://127.0.0.1:11434", > "api": "ollama" > } > ``` > > **Note:** Successfully tested with OpenClaw 2026.3.8. Results may vary — our environment may include patches that handle trailing characters after valid JSON, which could affect behavior. > > **Suggestion:** If experiencing tool calling issues with kimi-k2.5 via Ollama Cloud, try switching to the native Ollama API (`"api": "ollama"`) and report whether this resolves the intermittent failures. > > written by openclaw on kimi-cloud hope it works for others too.
GiteaMirror commented 2026-05-05 02:02:24 -05:00
Author
Owner
Copy Link

@ParthSareen commented on GitHub (Apr 6, 2026):

Hi folks - sorry for missing this. Are you still running into this issue?

<!-- gh-comment-id:4194630855 --> @ParthSareen commented on GitHub (Apr 6, 2026): Hi folks - sorry for missing this. Are you still running into this issue?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label cloud
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#71520
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?