Repository navigation
SDK session.prompt() returns empty responses with custom OpenAI-compatible provider #15756
Description
Summary
When using a custom OpenAI-compatible provider with the OpenCode SDK, session.prompt() returns empty responses ({ data: {}, request: {}, response: {} }), even though direct API calls to the same endpoint work perfectly.
Environment
- OpenCode SDK versions tested:
1.0.0,1.2.15,0.0.0-beta-202603021851 - Node.js: v23.3.0
- Platform: macOS (darwin)
- Custom provider: OpenAI-compatible endpoint at
llmlite_url
Configuration
opencode.json:
{
"model": "custom-llm/gpt-4o",
"provider": {
"custom-llm": {
"npm": "@ai-sdk/openai-compatible",
"name": "Custom OpenAI Provider",
"options": {
"baseURL": "llmlite_url",
"apiKey": "sk-***"
},
"models": {
"gpt-4o": {
"name": "GPT-4o",
"limit": { "context": 128000, "output": 16384 }
},
"gpt-4o-mini": {
"name": "GPT-4o Mini",
"limit": { "context": 128000, "output": 16384 }
}
}
}
}
}~/.local/share/opencode/auth.json:
{
"custom-llm": {
"type": "api",
"key": "sk-***"
}
}Test Results
✅ Direct API Call - WORKS
const response = await fetch('llmlite_url', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': 'Bearer sk-***'
},
body: JSON.stringify({
model: 'gpt-4o',
messages: [{ role: 'user', content: 'Say "Direct API call works!"' }]
})
});
// Returns: { choices: [{ message: { content: "Direct API call works!" } }] }❌ OpenCode SDK - EMPTY RESPONSE
import { OpencodeClient } from '@opencode-ai/sdk';
const client = new OpencodeClient({ embeddedServer: { cwd: process.cwd() } });
await client.start();
const session = await client.createSession({ model: 'custom-llm/gpt-4o' });
const response = await session.prompt('Say "SDK works!"');
// Returns: { data: {}, request: {}, response: {} }
// Expected: { data: { parts: [...] } }Verification
-
✅ OpenCode CLI recognizes provider:
$ opencode models custom-llm # Shows: custom-llm/gpt-4o, custom-llm/gpt-4o-mini -
✅ Config loads in SDK:
const config = await client.config.get(); // Returns full config with custom-llm provider details
-
✅ Server starts successfully:
- No errors in server logs
- Server URL available (e.g.,
http://127.0.0.1:65235)
-
✅ Session creates successfully:
- Returns valid session ID (e.g.,
ses_34fed36ccffeO0TI9rPks1UiMw)
- Returns valid session ID (e.g.,
-
❌ Prompt returns empty:
response.datais always{}response.data.partsis undefined- No error messages
Tested Across Versions
Same behavior across:
- SDK v1.0.0 (first stable release)
- SDK v1.2.15 (latest stable)
- SDK v0.0.0-beta-202603021851 (latest beta)
This suggests it's a fundamental issue with custom OpenAI-compatible providers, not a version-specific regression.
Complete Test Script
import { OpencodeClient } from '@opencode-ai/sdk';
// Direct API call - WORKS
const directResponse = await fetch('llmlite_url', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': 'Bearer sk-***'
},
body: JSON.stringify({
model: 'gpt-4o',
messages: [{ role: 'user', content: 'Hello!' }]
})
});
console.log('Direct API:', await directResponse.json()); // ✅ Returns content
// SDK call - EMPTY
const client = new OpencodeClient({ embeddedServer: { cwd: process.cwd() } });
await client.start();
const session = await client.createSession({ model: 'custom-llm/gpt-4o' });
const sdkResponse = await session.prompt('Hello!');
console.log('SDK Response:', sdkResponse); // ❌ Returns { data: {}, request: {}, response: {} }Expected Behavior
When using a custom OpenAI-compatible provider, session.prompt() should return responses in the same format as when using built-in providers like GitHub Copilot.
Actual Behavior
session.prompt() returns { data: {}, request: {}, response: {} } with no content or error messages.
Questions
- Are custom OpenAI-compatible providers fully supported in embedded server mode?
- Is there additional configuration required for custom providers?
- Is this a known limitation?
- Should we use non-embedded server mode (
opencode serve) instead?
Workaround Needed
We're building a Microsoft Teams bot that needs to use a custom OpenAI-compatible LLM (not GitHub Copilot, not Azure OpenAI). We'd like to use OpenCode SDK for tool orchestration, but this blocker prevents us from proceeding.
Any guidance would be greatly appreciated!
Activity
github-actions commentedon Mar 2, 2026
This issue might be a duplicate of existing issues. Please check:
@ai-sdk/openai-compatiblewith a custom baseURL, even though direct API calls succeedbaseURL) are not forwarded, causing requests to fail silently@ai-sdk/openai-compatiblewith a third-party endpointIf your issue is the same as one of the above, please add a comment there with any additional information rather than opening a new issue.
fix: use custom OpenAI-compatible provider to resolve empty responses
Delqhi commentedon Mar 7, 2026
We ran into a very similar custom-provider failure mode. In our case the direct API worked, but OpenCode either returned effectively blank output or stopped after the first step because the provider only partially matched the OpenAI tool / stream schema.
What fixed it in our fork was an opt-in compatibility layer for custom OpenAI-compatible providers:
tools/tool_choice-> legacyfunctions/function_callwhen neededfunction_call, text-only tool intents, JSON tool blocks, and wrapped<tool_call>payloadsfinish_reason=stopThat was enough to turn a previously blank / one-shot OpenAI-compatible endpoint into a usable multi-turn tool flow on our side.
This seems related to the same family of issues discussed in #234, #5210, and #10573.
If maintainers want, I can turn the compatibility layer into a PR behind explicit custom-provider config so it does not affect the happy path for native providers.
Delqhi commentedon Mar 7, 2026
Opened a PR for this path here: #16531
The patch adds an opt-in compat layer for custom
@ai-sdk/openai-compatibleproviders so OpenCode can recover tool intent from legacyfunction_callresponses or structured text instead of stopping after the first assistant message.nguyen-trantrung commentedon Apr 19, 2026
bumping, is this critical, should be high priority. Please fix!
github-actions commentedon Jul 3, 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.