[Bug]: OpenCode Go + Kimi K2.6/K2.5 returns 'Provider returned error' on CLI 1.14.20

[byungsker]

Description

OpenCode Go provider works perfectly for all models except Kimi K2.6 and K2.5, which consistently return "Provider returned error". Other models (GLM-5, Qwen3.5 Plus, MiniMax M2.5/M2.7) under the same OpenCode Go subscription work fine.

Environment

• OpenCode Version: 1.14.20
• OS: macOS
• Provider: OpenCode Go (paid subscription, $10/month)
• Affected Models: kimi-k2.6, kimi-k2.5
• Working Models: glm-5, glm-5.1, qwen3.5-plus, minimax-m2.5, minimax-m2.7

Steps to Reproduce

1. Run opencode and connect to OpenCode Go via /connect
2. Select kimi-k2.6 from /models
3. Send any message (e.g., "hi")
4. Observe: "Provider returned error" appears immediately

Evidence

• Same API key works with Kimi on other clients: The exact same OpenCode Go API key works perfectly with Kimi K2.6 on:
  • OpenClaw gateway (same machine, different session)
  • OpenCode Zen provider (same machine, different provider selection)
• This rules out API key invalidity or server-side Kimi outage.

Troubleshooting Already Attempted

• Cleared ~/.local/share/opencode and re-authenticated
• Cleared ~/.cache/opencode to force provider package re-download
• Reinstalled opencode-ai globally via npm
• Changed network (WiFi → mobile hotspot) to rule out IP-based blocking
• Verified same API key works with other OpenCode Go models
• Verified same API key works with Kimi on OpenCode Zen

Expected Behavior

Kimi K2.6/K2.5 should work through OpenCode Go provider, just like GLM-5 and Qwen3.5 Plus do.

Actual Behavior

Only Kimi models fail with a generic "Provider returned error" message. No detailed error code or HTTP status is exposed in the UI.

Additional Context

This appears similar to previously reported issues:

• [Bug]: Missing API Key error with OpenCode Go provider (Kimi K2.5) while same API key works with OpenCode Zen #17541 (Missing API Key error with OpenCode Go + Kimi K2.5)
• Kimi k2.5 shows "The API Key appears to be invalid or may have expired" with a working API key #14892 (API Key invalid error with Kimi K2.5)
• [Bug] "Provider returned error" consistently occurs with Kimi K2.5 via OpenCode Go on Windows #16685 (Provider returned error with Kimi K2.5 via OpenCode Go)

However, in this case the API key is definitively valid (works on Zen and other models), and the error persists across cache clears, reinstalls, and network changes.

[github-actions]

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

• [Bug] "Provider returned error" consistently occurs with Kimi K2.5 via OpenCode Go on Windows #16685: "Provider returned error" consistently occurs with Kimi K2.5 via OpenCode Go (same error, same provider)
• "Provider returned error" hides actual Kimi/Moonshot API errors | Opencode GO | kimi k2.6 #23665: "Provider returned error" hides actual Kimi/Moonshot API errors via OpenCode GO with kimi k2.6 (same error, same model)
• 我订阅了opencode的go套餐但是我在使用kimi-2.6的时候出现了如下的错误 #23646: OpenCode Go subscription + kimi-2.6 error (same scenario)
• Kimi k2.5 shows "The API Key appears to be invalid or may have expired" with a working API key #14892: Kimi k2.5 shows API Key error with a working API key (similar symptom - provider error despite valid key)
• Opencode Go Kimi and Minimax doesn't work #17626: OpenCode Go Kimi and Minimax doesn't work (same provider/model combination failing)

[byungsker]

I've already tried all workarounds mentioned in #16685 and #23665 (cache clear, reinstall, network change). The issue persists. My case includes K2.6 as well, and I've confirmed the API key works via Zen and OpenClaw. Please keep this open.

[byungsker]

Update: Even with , the error is completely opaque:

No HTTP status code, no response body, no provider-specific error details are exposed. This matches the exact behavior described in #23665 where the provider package swallows the actual Kimi/Moonshot API error.

[byungsker]

Update: Even with --log-level DEBUG, the error is completely opaque. No HTTP status code, no response body, no provider-specific error details are exposed. This matches the exact behavior described in #23665 where the provider package swallows the actual Kimi/Moonshot API error.

[nathandavismem]

I struggled to find a way to fix this issue without changing / custom build the opencode source code. I discovered that the problem seems came from the tool call, specifically related to registered MCPs. In my case, the "stitch" MCP was causing the error, once I removed it, everything ran smoothly without that persistent error. I suggest trying to remove any custom MCPs or configurations if you're seeing something similar.

[PedroCabral04]

I struggled to find a way to fix this issue without changing / custom build the opencode source code. I discovered that the problem seems came from the tool call, specifically related to registered MCPs. In my case, the "stitch" MCP was causing the error, once I removed it, everything ran smoothly without that persistent error. I suggest trying to remove any custom MCPs or configurations if you're seeing something similar.

this worked for me, thanks!

[byungsker]

I struggled to find a way to fix this issue without changing / custom build the opencode source code. I discovered that the problem seems came from the tool call, specifically related to registered MCPs. In my case, the "stitch" MCP was causing the error, once I removed it, everything ran smoothly without that persistent error. I suggest trying to remove any custom MCPs or configurations if you're seeing something similar.

Oh, I followed your instructions, and now Kimi is working perfectly! Thank you @nathandavismem ! 👍🏻
In my specific case, Kimi started working as soon as I disabled my custom MCP, figma-console.

However, while this serves as a temporary workaround, I'm not sure if the root cause of the problem has actually been resolved. Shouldn't Kimi—which I access via an OpenCode Go subscription—function without issues regardless of which MCP I happen to be using?

[chandankumar123456]

I struggled to find a way to fix this issue without changing / custom build the opencode source code. I discovered that the problem seems came from the tool call, specifically related to registered MCPs. In my case, the "stitch" MCP was causing the error, once I removed it, everything ran smoothly without that persistent error. I suggest trying to remove any custom MCPs or configurations if you're seeing something similar.

It worked for me, but i have remove complete mcp from the config

[nathandavismem]

However, while this serves as a temporary workaround, I'm not sure if the root cause of the problem has actually been resolved. Shouldn't Kimi—which I access via an OpenCode Go subscription—function without issues regardless of which MCP I happen to be using?

Yeah, it's probably an issue with the provider tools handler. I've seen similar reports, but the root causes were different. Either way, Kimi providers should work fine with any MCP or plugins.

[nathandavismem]

I struggled to find a way to fix this issue without changing / custom build the opencode source code. I discovered that the problem seems came from the tool call, specifically related to registered MCPs. In my case, the "stitch" MCP was causing the error, once I removed it, everything ran smoothly without that persistent error. I suggest trying to remove any custom MCPs or configurations if you're seeing something similar.

It worked for me, but i have remove complete mcp from the config

Have you tried removing partial MCPs?

[mokafolio]

I am getting the same error without any MCPs installed and there does not seem to be a way to resolve it in this case. I am in a deep session that seems borked with not way for me to continue as far as I can tell.

[Andrez421]

Me costó encontrar una solución a este problema sin modificar ni compilar a medida el código fuente de OpenCode. Descubrí que el problema parecía provenir de la llamada a la herramienta, específicamente de los MCP registrados. En mi caso, el MCP "stitch" era el causante del error; una vez que lo eliminé, todo funcionó correctamente sin ese error persistente. Sugiero intentar eliminar cualquier MCP o configuración personalizada si experimentas algo similar.

It worked for me, thank you very much