You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
providers: nvidia rejects unsupported prompt_cache_key sent by V2 (OpenAI-compatible runtime) #49240
OpenCode 2.0.3 sends the prompt_cache_key parameter to OpenAI-compatible providers by default. The NVIDIA NIM API (https://integrate.api.nvidia.com/v1) does not support it and rejects the request, so most NVIDIA models are unusable in V2.
Active plugins: TUI plugins/sidebar-mimo/tui.tsx, opencode-voice-modified/tui.js, server plugins/nvidia-filter/index.ts, plus -opencode.sidebar.context in cli.json. (None related to the provider request path.)
Reproduction
Configure the built-in nvidia provider (API key from https://integrate.api.nvidia.com/v1).
Run any of the affected models headless:
opencode run --standalone --model nvidia/meta/muse-glimmer-30b "di OK"
Observe the error.
Expected Behavior
The request should succeed (or at least not include parameters the provider does not support). The same models return HTTP 200 when called directly against the NVIDIA API without prompt_cache_key.
There is a provider predicate that already excludes NVIDIA (g = n === "nvidia" || baseURL.includes("integrate.api.nvidia.com")) for some caching behaviour, but the prompt_cache_key field is still sent.
There is no configuration to disable it:
provider.nvidia.options.cache = "none" (V1) → still sent.
providers.nvidia.models.<id>.settings.cache = "none" (V2) → still sent.
The cache option is not part of the config schema.
Workaround used temporarily (and removed): a local reverse proxy that strips prompt_cache_key (also prompt_cache_retention, safety_identifier, store) before forwarding to NVIDIA. That made all affected models work, confirming the parameter is the sole cause.
Reproducible: yes, consistently, for all affected models.
Correction to my comment above — I should have checked source before "confirming." Retracting the strong claim.
I only actually observed the Body is disturbed or locked crash, which turned out to be 100% caused by my own local plugin (a session.hook("http.request", ...) workaround written against #45113/this issue) calling request.text() without cloning first, then rebuilding a Request that still referenced the original disturbed stream. That's a bug in my local plugin code, not opencode.
I never actually saw NIM return the prompt_cache_key 400 in my logs. Checking dev HEAD just now: packages/llm/src/providers/openai-compatible.ts routes through openai-compatible-chat.ts → openai-chat.ts, and that protocol's lowerOptions() only emits store and reasoning_effort — it never attaches prompt_cache_key/promptCacheKey to the Chat Completions body at all. So on current dev, this specific root cause looks like it may already be structurally gone (via the provider-dispatch rewrite into @opencode-ai/llm), unless there's another dispatch path I'm missing for statically-configured openai-compatible providers. Worth a maintainer double-check against a fresh 2.0.x build before anyone spends time on a PR here — I couldn't reproduce the 400 itself, only my own plugin's crash.
Activity
github-actions commentedon Sep 15, 2026
This issue might be a duplicate of existing issues. Please check:
prompt_cache_keyto all OpenAI-compatible providers; no config option can suppress it. That issue includes source-level analysis of the same code paths you identified.thdhyan commentedon Sep 23, 2026
Correction to my comment above — I should have checked source before "confirming." Retracting the strong claim.
I only actually observed the
Body is disturbed or lockedcrash, which turned out to be 100% caused by my own local plugin (asession.hook("http.request", ...)workaround written against #45113/this issue) callingrequest.text()without cloning first, then rebuilding aRequestthat still referenced the original disturbed stream. That's a bug in my local plugin code, not opencode.I never actually saw NIM return the
prompt_cache_key400 in my logs. CheckingdevHEAD just now:packages/llm/src/providers/openai-compatible.tsroutes throughopenai-compatible-chat.ts→openai-chat.ts, and that protocol'slowerOptions()only emitsstoreandreasoning_effort— it never attachesprompt_cache_key/promptCacheKeyto the Chat Completions body at all. So on currentdev, this specific root cause looks like it may already be structurally gone (via the provider-dispatch rewrite into@opencode-ai/llm), unless there's another dispatch path I'm missing for statically-configuredopenai-compatibleproviders. Worth a maintainer double-check against a fresh 2.0.x build before anyone spends time on a PR here — I couldn't reproduce the 400 itself, only my own plugin's crash.rekram1-node commentedon Oct 5, 2026
#49121 (#49121)
Any version 2.0.4 or later has fix.