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
Custom OpenAI-compatible provider returns no text content #5210
When using a custom provider with @ai-sdk/openai-compatible, API calls complete successfully but no text content is displayed. The API returns valid responses (verified via curl), but opencode shows empty responses with 0 tokens.
The @ai-sdk/openai-compatible package may not be emitting text-start events before text-delta events. In processor.ts, text-delta handling requires currentText to be set (which happens in text-start):
case"text-delta":
if(currentText){// <-- undefined without text-startcurrentText.text+=value.text
...
}break
Without a text-start event, all text-delta events are silently ignored.
Both issues use the @ai-sdk/openai-compatible provider and report content not being displayed despite successful API calls. The symptoms and likely root cause (missing text-start events before text-delta events) suggest these could be related issues.
Feel free to ignore if your case is specific to the Dedalus Labs provider.
Activity
github-actions commentedon Dec 7, 2025
This issue might be a duplicate of existing issues. Please check:
Both issues use the @ai-sdk/openai-compatible provider and report content not being displayed despite successful API calls. The symptoms and likely root cause (missing
text-startevents beforetext-deltaevents) suggest these could be related issues.Feel free to ignore if your case is specific to the Dedalus Labs provider.
rekram1-node commentedon Dec 8, 2025
Hm every other provider i've seen emits them correctly, it seems like it'd be a bug on the provider side rather than the sdk no?
cgilly2fast commentedon Dec 8, 2025
I am not 100% sure thats the issue, I was trying help with beginning deductions
fix: use custom OpenAI-compatible provider to resolve empty responses
Delqhi commentedon Mar 7, 2026
This looks very close to the same custom-provider compatibility gap we hit.
We got a working fix in a fork by adding an opt-in compatibility layer for OpenAI-compatible providers:
function_callnormalization<tool_call>payloadstools/tool_choice->functions/function_callon endpoints that only partially implement the OpenAI schemafinish_reason=stopThat turned a previously blank / one-shot custom-provider session into a usable multi-turn tool flow on our side.
Related issues: #234, #15756, #10573.
If useful, I can package the compatibility layer as an explicit custom-provider config path instead of changing default native-provider behavior.
jogoossens commentedon Mar 8, 2026
have it too on our side