MS Foundry + Kimi Code 2.7 - 400 Unrecognized request argument supplied: prompt_cache_key

[mkrzywda]

What version of Kimi Code is running?

0.32.0

Which open platform/subscription were you using?

.

Which model were you using?

kimi-k2.7-code

What platform is your computer?

Linux 5.15.167.4-microsoft-standard-WSL2 x86_64 x86_64

What issue are you seeing?

Kimi Code CLI sends prompt_cache_key in a request to an OpenAI-compatible endpoint, and the endpoint rejects it with HTTP 400: Unrecognized request argument supplied: prompt_cache_key.

Config (redacted)

default_model = "azure/kimi-k2.7-code"

[providers.azure-foundry]
type = "openai"
base_url = "https://<redacted>/openai/v1"
api_key = "<redacted>"

[providers.azure-foundry.custom_headers]
api-key = "<redacted>"

[models."azure/kimi-k2.7-code"]
provider = "azure-foundry"
model = "Kimi-K2.7-Code"
max_context_size = 262144
capabilities = [ "thinking", "tool_use", "image_in" ]
reasoning_key = "reasoning_content"

[thinking]
enabled = false



### What steps can reproduce the bug?

### Steps to reproduce

1. Configure provider/model as above.
2. Start a session (simple prompt like test).
3. First LLM turn fails.

### What is the expected behavior?

_No response_

### Additional information

_No response_

[map-c]

I looked into this against current main and can confirm the root cause — and it is the same one behind #2166.

Root cause: the CLI attaches a session-affinity cache key to every OpenAI-family request unconditionally:

• v1 engine (packages/agent-core/src/session/provider-manager.ts): the openai and openai_responses branches always set generationKwargs: { prompt_cache_key: <session key> }. The Anthropic branch's equivalent (metadata.user_id) is gated on the key being defined, but there is no equivalent opt-out on the OpenAI side.
• v2 engine (packages/agent-core-v2/src/kosong/provider/bases/openai/): openai-legacy.ts and openai-responses.ts encode options.cacheKey as prompt_cache_key by default unless a provider hook overrides it.

Strict OpenAI-compatible gateways (Azure AI Foundry here, NVIDIA NIM in #2166) reject unknown request fields with a 400, so the first LLM turn always fails and there is currently no config knob to turn the field off.

Proposed fix — two options, happy to implement either (both engines + tests):

1. Per-provider opt-out in config.toml, e.g.

   [providers.azure-foundry]
   type = "openai"
   prompt_cache_key = false   # do not send the field

   Explicit, discoverable, works for any strict gateway, and keeps today's default behavior for everyone else. The v1 change is a one-line gate in provider-manager.ts; v2 threads the flag down to the two OpenAI bases so cacheKey is not encoded.

2. Only send prompt_cache_key for providers known to support it (first-party Kimi endpoints, maybe platform.openai.com), and never for arbitrary type = "openai" providers. Safer default for strict gateways, but silently loses cache affinity for custom providers that do support it (e.g. some OpenAI proxies), and the allowlist needs maintenance.

I'd lean toward option 1 (explicit opt-out, no behavior change by default). Do the maintainers have a preference — or a different shape in mind (e.g. reusing model capabilities instead of a provider key)? Once confirmed I'll open the PR.