Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Kimi Code Provider 强制覆盖用户配置，导致 OpenAI 兼容端点工具调用失败 [2 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#72156•Fetched 2026-04-27 05:34:02
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
doctorhexb163doctorhexb163
Participants
clawsweeper[bot]clawsweeper[bot]doctorhexb163doctorhexb163
Timeline (top)
cross-referenced ×2labeled ×2closed ×1commented ×1

Kimi Code provider (kimi-coding) hardcodes api: "anthropic-messages" in the built-in provider configuration. When users change baseUrl to Kimi's OpenAI-compatible endpoint (/coding/v1), the api field cannot be overridden, causing a protocol mismatch. As a result, tool calls fail with "tool not found" because the OpenAI endpoint receives anthropic-formatted tool call requests.

Error Message

Tool call failure with OpenAI endpoint: Error: "tool not found" Root cause: OpenClaw sends anthropic-format tool calls to OpenAI-compatible endpoint Speed comparison: Anthropic /coding/: ~3-5s per response OpenAI /coding/v1: ~1-2s per response (but tools broken)

Root Cause

Kimi Code provider (kimi-coding) hardcodes api: "anthropic-messages" in the built-in provider configuration. When users change baseUrl to Kimi's OpenAI-compatible endpoint (/coding/v1), the api field cannot be overridden, causing a protocol mismatch. As a result, tool calls fail with "tool not found" because the OpenAI endpoint receives anthropic-formatted tool call requests.

Fix Action

Fix / Workaround

Impact: Users cannot use Kimi's faster OpenAI-compatible endpoint with OpenClaw Severity: Medium-High — forces users to accept slower Anthropic protocol with known recursion issues Workaround: None available — user configuration cannot override built-in provider behavior

PR fix notes

PR #72185: fix(kimi): allow user to override api field in provider config [AI-assisted]

Description (problem / solution / changelog)

🤖 AI-assisted (built with Claude Code via Hermes orchestration). Test level: fully tested. Prompt summary available on request.

Summary

  • Problem: The Kimi Code provider hardcodes api: "anthropic-messages" and ignores the user's explicit api config, causing tool call protocol mismatches when users switch to OpenAI-compatible endpoints.
  • Why it matters: Users cannot use Kimi's OpenAI-compatible endpoint (/coding/v1) because the api field is silently overridden.
  • What changed: Forward explicitApi from user provider config alongside baseUrl and headers in extensions/kimi/src/index.ts.
  • What did NOT change (scope boundary): No changes to the built-in provider defaults, other provider catalogs, or any shared infrastructure.

Change Type (select all)

  • Bug fix

Scope (select all touched areas)

  • Extensions / Plugins

Linked Issue/PR

  • Closes #72156
  • This PR fixes a bug or regression

Root Cause

  • Root cause: In extensions/kimi/src/index.ts, builtInProvider is spread first, then only baseUrl and headers are explicitly overridden from user config. The api field from explicitProvider is never forwarded.
  • Missing detection / guardrail: No test verified that user-provided api config is respected.
  • Contributing context (if known): The pattern was copied from providers that only need baseUrl/headers overrides; api was overlooked.

Regression Test Plan

  • Coverage level that should have caught this:
    • Unit test
  • Target test or file: extensions/kimi/src/index.test.ts
  • Scenario the test should lock in: When user config includes api: "openai-completions", the resolved provider must use that value instead of the hardcoded "anthropic-messages".
  • Why this is the smallest reliable guardrail: Unit test on the catalog run function directly exercises the config merge logic.
  • Existing test that already covers this (if any): N/A
  • If no new test is added, why not: N/A — 3 new tests added.

User-visible / Behavior Changes

Users can now override the api field in their Kimi provider config (e.g., setting api: "openai-completions" for the /coding/v1 endpoint).

Diagram (if applicable)

N/A

Security Impact (required)

  • New permissions/capabilities? No
  • This fix only forwards an existing user config field that was previously silently ignored. No new attack surface or permission escalation.

Changed files

  • extensions/kimi-coding/index.test.ts (modified, +55/-0)
  • extensions/kimi-coding/index.ts (modified, +5/-0)

PR #72190: fix(kimi): allow user to override api field in provider config [AI-assisted]

Description (problem / solution / changelog)

🤖 AI-assisted (built with Claude Code via Hermes orchestration). Test level: fully tested. Prompt summary available on request.

Summary

  • Problem: The Kimi Code provider hardcodes api: "anthropic-messages" and ignores the user's explicit api config, causing tool call protocol mismatches when users switch to OpenAI-compatible endpoints.
  • Why it matters: Users cannot use Kimi's OpenAI-compatible endpoint (/coding/v1) because the api field is silently overridden.
  • What changed: Forward explicitApi from user provider config alongside baseUrl and headers in extensions/kimi/src/index.ts.
  • What did NOT change (scope boundary): No changes to the built-in provider defaults, other provider catalogs, or any shared infrastructure.

Change Type (select all)

  • Bug fix

Scope (select all touched areas)

  • Extensions / Plugins

Linked Issue/PR

  • Closes #72156
  • This PR fixes a bug or regression

Root Cause

  • Root cause: In extensions/kimi/src/index.ts, builtInProvider is spread first, then only baseUrl and headers are explicitly overridden from user config. The api field from explicitProvider is never forwarded.
  • Missing detection / guardrail: No test verified that user-provided api config is respected.
  • Contributing context (if known): The pattern was copied from providers that only need baseUrl/headers overrides; api was overlooked.

Regression Test Plan

  • Coverage level that should have caught this:
    • Unit test
  • Target test or file: extensions/kimi/src/index.test.ts
  • Scenario the test should lock in: When user config includes api: "openai-completions", the resolved provider must use that value instead of the hardcoded "anthropic-messages".
  • Why this is the smallest reliable guardrail: Unit test on the catalog run function directly exercises the config merge logic.
  • Existing test that already covers this (if any): N/A
  • If no new test is added, why not: N/A — 3 new tests added.

User-visible / Behavior Changes

Users can now override the api field in their Kimi provider config (e.g., setting api: "openai-completions" for the /coding/v1 endpoint).

Diagram (if applicable)

N/A

Security Impact (required)

  • New permissions/capabilities? No
  • This fix only forwards an existing user config field that was previously silently ignored. No new attack surface or permission escalation.

Changed files

  • extensions/kimi-coding/index.test.ts (modified, +83/-0)
  • extensions/kimi-coding/index.ts (modified, +5/-0)

Code Example

Tool call failure with OpenAI endpoint:
  Error: "tool not found"
  Root cause: OpenClaw sends anthropic-format tool calls to OpenAI-compatible endpoint
Speed comparison:
  Anthropic /coding/: ~3-5s per response
  OpenAI /coding/v1: ~1-2s per response (but tools broken)
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Kimi Code provider (kimi-coding) hardcodes api: "anthropic-messages" in the built-in provider configuration. When users change baseUrl to Kimi's OpenAI-compatible endpoint (/coding/v1), the api field cannot be overridden, causing a protocol mismatch. As a result, tool calls fail with "tool not found" because the OpenAI endpoint receives anthropic-formatted tool call requests.

Steps to reproduce

  1. Configure Kimi Code provider with default Anthropic endpoint:

{ "models": { "providers": { "kimi-coding": { "apiKey": "sk-xxx", "baseUrl": "https://api.kimi.com/coding/" } } } } → Works but slow, has tool call recursion issues

  1. Change to OpenAI-compatible endpoint:

{ "models": { "providers": { "kimi-coding": { "apiKey": "sk-xxx", "baseUrl": "https://api.kimi.com/coding/v1" } } } } → Conversation is fast, but tool calls fail 3. Try adding api override (does NOT work): { "kimi-coding": { "apiKey": "sk-xxx", "baseUrl": "https://api.kimi.com/coding/v1", "api": "openai-completions" } } → Still uses anthropic-messages internally

Expected behavior

When baseUrl is set to an OpenAI-compatible endpoint (/coding/v1), OpenClaw should either:

  • Automatically switch to openai-completions protocol, OR

  • Allow users to override the api field in provider config

Actual behavior

  • api field is hardcoded to anthropic-messages in buildKimiCodingProvider()

  • wrapKimiProviderStream forces Kimi-specific tag-based tool call parsing

  • User configuration for api is ignored

  • OpenAI endpoint receives anthropic-format tool calls → returns "tool not found"

OpenClaw version

2026.4.14

Operating system

Windows 11 + WSL2 (Ubuntu)

Install method

No response

Model

kimi-coding/kimi-for-coding (also tested with kimi-coding/k2p5)

Provider / routing chain

Working config: openclaw -> kimi-coding -> api.kimi.com/coding/ (anthropic-messages) Broken config: openclaw -> kimi-coding -> api.kimi.com/coding/v1 (forced anthropic-messages, should be openai-completions) API Key: Kimi Code API subscription key

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Tool call failure with OpenAI endpoint:
  Error: "tool not found"
  Root cause: OpenClaw sends anthropic-format tool calls to OpenAI-compatible endpoint
Speed comparison:
  Anthropic /coding/: ~3-5s per response
  OpenAI /coding/v1: ~1-2s per response (but tools broken)

Impact and severity

Impact: Users cannot use Kimi's faster OpenAI-compatible endpoint with OpenClaw Severity: Medium-High — forces users to accept slower Anthropic protocol with known recursion issues Workaround: None available — user configuration cannot override built-in provider behavior

Additional information

Root Cause In extensions/kimi-coding/index.js: catalog: { run: async (ctx) => { const builtInProvider = buildKimiCodingProvider(); // ← hardcoded api: "anthropic-messages" return { provider: { ...builtInProvider, ...explicitBaseUrl ? { baseUrl: explicitBaseUrl } : {}, // api field is NOT overridable! }}; } }, wrapStreamFn: wrapKimiProviderStream // ← forces Kimi tag-based tool parsing Proposed Solutions Option 1 (Recommended): Auto-detect protocol from baseUrl: /coding/ → anthropic-messages /coding/v1 → openai-completions Option 2: Allow api override in user config: const explicitApi = normalizeOptionalString(explicitProvider?.api); return { provider: { ...builtInProvider, ...explicitBaseUrl ? { baseUrl: explicitBaseUrl } : {}, ...explicitApi ? { api: explicitApi } : {}, // ← allow override }}; Option 3: Add new kimi-openai provider alias using standard OpenAI protocol.

extent analysis

TL;DR

The most likely fix is to modify the buildKimiCodingProvider function to allow the api field to be overridden in the user configuration or to auto-detect the protocol from the baseUrl.

Guidance

  • Identify the buildKimiCodingProvider function in extensions/kimi-coding/index.js and modify it to allow the api field to be overridden.
  • Consider implementing Option 1: auto-detect the protocol from the baseUrl to switch between anthropic-messages and openai-completions.
  • Alternatively, implement Option 2: allow the api field to be overridden in the user configuration by adding the explicitApi variable.
  • Verify the fix by testing the Kimi Code provider with the OpenAI-compatible endpoint and checking if tool calls are successful.

Example

const explicitApi = normalizeOptionalString(explicitProvider?.api);
return { provider: {
  ...builtInProvider,
  ...explicitBaseUrl ? { baseUrl: explicitBaseUrl } : {},
  ...explicitApi ? { api: explicitApi } : {},  // allow override
}};

Notes

The current implementation of buildKimiCodingProvider hardcodes the api field to anthropic-messages, which causes the issue. Modifying this function to allow overrides or auto-detection of the protocol should resolve the problem.

Recommendation

Apply workaround by modifying the buildKimiCodingProvider function to allow the api field to be overridden, as this is a more straightforward solution that can be implemented immediately.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

When baseUrl is set to an OpenAI-compatible endpoint (/coding/v1), OpenClaw should either:

  • Automatically switch to openai-completions protocol, OR

  • Allow users to override the api field in provider config

#api#mixed precision#training loop#device allocation#model download

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: Kimi Code Provider 强制覆盖用户配置，导致 OpenAI 兼容端点工具调用失败 [2 pull requests, 1 comments, 2 participants]