Repository navigation
Open
Labels
Description
Summary
Model-level compatibility.supportsStore set in opencode.jsonc is silently ignored: the openai-compatible chat protocol keeps injecting "store": false into every request body, which strict gateways reject. A sibling key in the same block (maxTokensField) is honored, so the file is parsed — only some compatibility keys take effect.
Environment
- opencode version: 2.0.21
- OS: Linux 7.0.0-34-generic (linux x64)
- Terminal: WarpTerminal, TERM=xterm-256color, COLORTERM=truecolor
- Shell: /bin/zsh
- Install/channel: latest
- Active plugins:
opencode-models-discovery@latest,superpowers@git+https://github.com/obra/superpowers.git, localrtk.ts
Reproduction
- Configure an
openai-compatibleprovider pointing at a backend that rejects unknown body fields (e.g. a LiteLLM proxy routing Claude models to a Bedrock/azure_aibackend), with one model:"models": { "claude-sonnet-5-5": { "modelID": "claude-sonnet-5-5", "compatibility": { "supportsStore": false, "maxTokensField": "max_tokens" } } }
- Send any prompt with that model (or capture the outgoing request body with a local probe endpoint).
- Observe the request uses
max_tokens(override honored) but still contains"store": false.
Expected Behavior
With compatibility.supportsStore: false, the store key should be omitted from the request body entirely.
Actual Behavior
"store": false is always sent unless the provider id/baseURL matches the built-in nonstandard-provider list. The gateway responds with litellm.UnsupportedParamsError: azure_ai does not support parameters: ['store'], making the model unusable. Requests without store succeed (verified directly against the gateway).
Additional Context
- Inspecting the v2.0.21 binary, the config-file compatibility schema accepts
reasoningField,requireReasoning,maxTokensField,requireFinishReason,requireAssistantAfterTool,supportsPromptCacheKey— but notsupportsStore(norsupportsStrictMode, etc.), while the runtimeLanguageModelCompatibilityschema includes them. So the key is dropped at config load, never reachingdetectSupportsStore's?? request.model.compatibility?.supportsStorefallback. - Consistent across repeated runs; no
failed to load plugin/ config errors logged for the entry (it is silently skipped, matching the existingconfiguration normalization diagnostic ... action="skipped malformed recognized value"pattern for unknown keys). - Workaround attempted: an
http.requestsession-hook plugin strippingstore(works in isolation against a probe endpoint) — blocked by a separate reload bug filed alongside this one.
Activity
github-actions commentedon Oct 2, 2026
This issue appears to follow the bug-report template and includes substantive description, reproduction steps, and environment details.
This issue may be related to existing reports about unsupported OpenAI-compatible request fields and compatibility controls. Please check:
prompt_cache_keywhile thesetCacheKeyopt-out is ignored.prompt_cache_keysent by the OpenAI-compatible runtime.mperreir commentedon Oct 5, 2026
Hello,
Until this bug is fixed, here is a workaround using the plugin idea you proposed (it works correctly on my side).
strip-store.ts
fix(schema): keep openai-compatible compatibility flags from config
fix(schema): keep openai-compatible compatibility flags from config
fihaaade commentedon Oct 24, 2026
This should be fixed on
devby #57239: Chat Completions now only sendsstoreto OpenAI and Azure by default, so strict gateways such as LiteLLM no longer get"store": false. I think this can be closed once a release includes it.opencodejr commentedon Oct 28, 2026
Thanks for the detailed report. I reproduced this, and part of it is already fixed on
dev.I pointed two
openai-compatibleproviders at a local endpoint that records request bodies. Both used your model config (compatibility: { supportsStore: false, maxTokensField: "max_tokens" }). One baseURL looks like a LiteLLM gateway; the other contains.openai.azure.com, so OpenCode's built-in detection treats it as Azure OpenAI."store": false, whilemax_tokensis used. This matches what you described.dev(891a020): the gateway-style provider no longer getsstore. Since v2.1.0,storeis only sent by default to OpenAI and Azure endpoints (fix(ai): only send store on chat completions for OpenAI and Azure #57239), so upgrading should fix the LiteLLMUnsupportedParamsErrorfor you. The setting itself is still ignored, though: the Azure-looking provider still gets"store": falsedespitesupportsStore: false. The config schema has nosupportsStorefield, so the key is dropped when the config loads, as you found.The script below reproduces it. Related:
storebehavioursupportsStoreto the config schemaReproduction script (repro.sh)
Run it:
bash repro.sh