Repository navigation
[Bug]: "stream_options" injected into OpenAI-compatible provider causing 400 Bad Request on Databricks AI Gateway #31156
Description
Description
Description
When attempting to use open-weight models (such as Qwen 3.5, Llama 4, or Gemma 3) hosted on a Databricks AI Gateway via the @ai-sdk/openai-compatible provider in OpenCode, streaming requests fail immediately with a 400 Bad Request error.
Error Message:
Bad Request: Bad request: json: unknown field "stream_options"Root Cause
- The Databricks AI Gateway strictly validates the JSON payload schemas of incoming requests and throws a hard error if it encounters any unrecognized properties.
- OpenCode's internal networking layer / SDK wrapper automatically injects
"stream_options": {"include_usage": true}into all streaming request payloads to calculate token usage statistics. - Because the gateway does not support this OpenAI-specific parameter, all streaming attempts to Databricks-hosted models crash.
While standard OpenAI-compatible providers on modern Vercel AI SDK versions (@ai-sdk/openai-compatible2.0.48+) allow omitting or filtering this field, OpenCode's internal client wrapper enforces this parameter on all OpenAI-compatible endpoints.
Verification (Standalone Node.js works!)
If we run a raw Node.js script (bypassing OpenCode) using the exact same configuration via the latest @ai-sdk/openai-compatible package, it works perfectly.
Using the following pure Node.js script:
const { streamText } = require('ai');
const { createOpenAICompatible } = require('@ai-sdk/openai-compatible');
const provider = createOpenAICompatible({
baseURL: "https://<workspace>.azuredatabricks.net/serving-endpoints",
apiKey: "dapi_YOUR_TOKEN"
});
async function run() {
const textStream = streamText({
model: provider('databricks-qwen35-122b-a10b'),
prompt: "What is 2 + 2? Respond with only the digit '4' and nothing else.",
});
for await (const chunk of textStream.textStream) {
process.stdout.write(chunk);
}
}
run();Result:
The stream is successful and outputs the expected response. This proves that @ai-sdk/openai-compatible itself is not injecting stream_options in standard environments; it is OpenCode's internal application wrapper/middleware that intercepts requests and injects the parameter.
Proposed Solutions
- Option A (Preferred): Expose a boolean option in the configuration (e.g.,
disableStreamOptions: trueorincludeUsageInStream: false) so users can manually opt-out of injectingstream_optionsfor strict gateway APIs. - Option B: Detect if the
baseURLcontainsdatabricks.net/serving-endpointsand automatically omit thestream_optionsfield from the payload.
Plugins
none
OpenCode version
1.16.2
Steps to reproduce
- Configure an OpenAI-compatible provider pointing to a Databricks Gateway endpoint in
opencode.jsonc:"my-openai-gateway": { "npm": "@ai-sdk/openai-compatible", "api": "createOpenAICompatible", "name": "Databricks Open Models", "options": { "baseURL": "https://<workspace>.azuredatabricks.net/serving-endpoints", "apiKey": "dapi_YOUR_TOKEN" }, "models": { "databricks-qwen35-122b-a10b": { "name": "Qwen 3.5" } } }
- Run a query in the terminal:
opencode run -m my-openai-gateway/databricks-qwen35-122b-a10b "Hello" - The server rejects the request with the
stream_optionserror.
Screenshot and/or share link
No response
Operating System
Mac, Linux
Terminal
iTerm2
Activity
github-actions commentedon Jun 6, 2026
This issue might be a duplicate of an existing issue. Please check:
stream_options: Extra inputs are not permittederror from Databricks AI Gateway — thestream_options: {include_usage: true}field injected by OpenCode is rejected by Databricks. That issue was closed, so if it was not fully resolved, please add a comment there or reference it here so maintainers can reopen or track it.If you believe your issue covers a distinct scenario not addressed in #4698, please clarify the difference.
fonsito commentedon Jun 7, 2026
Hi!
Please reopen this issue. While it is true that this error starts at the same place as #4698 (
stream_options: Extra inputs are not permitted), the workaround suggested in #4698 ("includeUsage": false) does not resolve the integration for native execution.Even if we apply
"includeUsage": falseto bypass thestream_optionsvalidation, any attempt to run an agent session natively (e.g., callingopencode run) fails immediately with subsequent validation errors from the Databricks AI Gateway:1. JSON Schema Constraint Validation Error
When OpenCode registers its tools (such as
bashorread), it defines parameter schemas with"type": "integer"(or"number") and a"minimum": 0constraint (e.g., for timeouts or line limits).The Databricks AI Gateway strictly validates tool schemas and rejects them, returning:
Bad Request: Invalid JSON schema - integer types do not support minimumTo support this natively, OpenCode's schema generator should sanitize/strip out unsupported JSON schema constraints (like
minimumormaximum) from parameter schemas when registering tools for these endpoints.2. Hardcoded
max_tokensLimit RejectionOpenCode sends a default
max_tokens(often32000) in its request body. However, Databricks endpoints for open-weight models (like Llama) enforce a hard limit on output tokens, rejecting payloads that request more than8192tokens with:Bad Request: max_new_tokens 32000 cannot be greater than max_output_tokens 8192We need a native way to configure or dynamically cap
max_tokensat the model level to prevent this rejection.Conclusion
Disabling
stream_optionsis only the first step. OpenCode is currently unable to run natively against Databricks AI Gateway / strict OpenAI-compatible endpoints due to strict JSON Schema validation on tools and hard token limits. A native solution is needed in the OpenCode client to make these endpoints usable out-of-the-box.JAVA-LW commentedon Jun 9, 2026
This is a useful example of why "OpenAI-compatible" often means "mostly compatible, with provider-specific constraints." Databricks rejecting
stream_options, strict tool JSON Schema constraints, and a lower max output token cap are three different compatibility dimensions, so a single generic OpenAI payload can still fail.A native fix probably needs model/provider capability metadata: allowed request fields, tool schema dialect/constraints, max output tokens, streaming usage support, etc.
Disclosure: I work on 1flowbase, an open-source virtual model gateway. We are approaching this by making the gateway route/workflow explicit: each virtual endpoint can normalize or strip unsupported fields, cap tokens per upstream model, run fallback/verifier steps, and expose which provider/model actually served the request. This issue is a strong example of the problem we are trying to make less surprising.
github-actions commentedon Aug 9, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.