SDK session.prompt() returns empty responses with custom OpenAI-compatible provider

[eliya-mazoz]

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

1. ✅ OpenCode CLI recognizes provider:

   $ opencode models custom-llm
   # Shows: custom-llm/gpt-4o, custom-llm/gpt-4o-mini

2. ✅ Config loads in SDK:

   const config = await client.config.get();
   // Returns full config with custom-llm provider details

3. ✅ Server starts successfully:

   • No errors in server logs
   • Server URL available (e.g., http://127.0.0.1:65235)

4. ✅ Session creates successfully:

   • Returns valid session ID (e.g., ses_34fed36ccffeO0TI9rPks1UiMw)

5. ❌ Prompt returns empty:

   • response.data is always {}
   • response.data.parts is 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

1. Are custom OpenAI-compatible providers fully supported in embedded server mode?
2. Is there additional configuration required for custom providers?
3. Is this a known limitation?
4. 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!

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Custom OpenAI-compatible provider returns no text content #5210: Custom OpenAI-compatible provider returns no text content — same symptom of empty/blank responses when using @ai-sdk/openai-compatible with a custom baseURL, even though direct API calls succeed
• Custom OpenAI-compatible provider options not being passed to API calls #5674: Custom OpenAI-compatible provider options not being passed to API calls — related issue where provider options (including baseURL) are not forwarded, causing requests to fail silently
• Custom provider with Openai compatible API Straico (successfully connected) showing blank output and keep looping #10573: Custom provider with OpenAI-compatible API showing blank output — similar blank/empty output when using @ai-sdk/openai-compatible with a third-party endpoint

If 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.

[Delqhi]

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:

• request adapter for tools / tool_choice -> legacy functions / function_call when needed
• parser middleware for legacy function_call, text-only tool intents, JSON tool blocks, and wrapped <tool_call> payloads
• optional session repair when a custom provider ends a tool-capable turn with finish_reason=stop
• minimized tool payload / allowlist for brittle providers

That 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]

Opened a PR for this path here: #16531

The patch adds an opt-in compat layer for custom @ai-sdk/openai-compatible providers so OpenCode can recover tool intent from legacy function_call responses or structured text instead of stopping after the first assistant message.