anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[Feature Request] Support traditional Chat Completions API for OpenAI provider #4733

New Issue
Open
opened 2026-02-16 17:45:12 -05:00 by yindo · 2 comments
yindo commented 2026-02-16 17:45:12 -05:00
Owner
Copy Link
Copy Source

Originally created by @boyan250422-code on GitHub (Jan 11, 2026).

Originally assigned to: @thdxr on GitHub.

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Description

The OpenAI provider in opencode uses the new Responses API format (SSE event stream) instead of the traditional Chat Completions API. Most OpenAI-compatible proxies only implement the Chat Completions API, causing compatibility issues.

Current Behavior

When configuring the OpenAI provider to point to an OpenAI-compatible proxy (e.g., Antigravity, LM Studio, Ollama, etc.), the proxy returns standard Chat Completions format, but opencode expects Responses API format, resulting in parse failures.

Error Message

AI_TypeValidationError: Type validation failed
Invalid input: expected "response.output_text.delta"

Reproduction Steps

  1. Configure OpenAI provider to point to an OpenAI-compatible proxy:
{
  "provider": {
    "openai": {
      "options": {
        "apiKey": "your-api-key",
        "baseURL": "http://localhost:8045/v1"
      }
    }
  }
}
  1. Run any opencode command
  2. Parse error occurs

Environment

  • OS: Windows 11
  • opencode version: v1.0.150+
  • oh-my-opencode version: v2.14.0

Root Cause

opencode's OpenAI provider uses OpenAI's new Responses API format instead of the widely-adopted Chat Completions API. Most OpenAI-compatible proxies only implement Chat Completions API.

Workaround

Use Anthropic provider instead:
If your proxy supports Anthropic API format (/v1/messages):

{
  "provider": {
    "anthropic": {
      "options": {
        "apiKey": "your-api-key",
        "baseURL": "http://localhost:8045/v1"
      }
    }
  }
}

Expected Behavior

Ideally, opencode should support both:

  1. Traditional Chat Completions API (for compatibility with most proxies)
  2. New Responses API (for official OpenAI)

Or at least provide a configuration option to choose between them.

Proposed Solutions

  1. Add a useResponsesApi or apiVersion option in OpenAI provider config
  2. Fallback to Chat Completions if Responses API is not supported
  3. Support both formats based on provider configuration

Additional Notes

This is a design limitation, not a bug per se. However, it significantly reduces compatibility with OpenAI-compatible proxies, which are widely used by developers.

Originally created by @boyan250422-code on GitHub (Jan 11, 2026). Originally assigned to: @thdxr on GitHub. ### Feature hasn't been suggested before. - [x] I have verified this feature I'm about to request hasn't been suggested before. ### Describe the enhancement you want to request ## Description The OpenAI provider in opencode uses the new Responses API format (SSE event stream) instead of the traditional Chat Completions API. Most OpenAI-compatible proxies only implement the Chat Completions API, causing compatibility issues. ## Current Behavior When configuring the OpenAI provider to point to an OpenAI-compatible proxy (e.g., Antigravity, LM Studio, Ollama, etc.), the proxy returns standard Chat Completions format, but opencode expects Responses API format, resulting in parse failures. ## Error Message ``` AI_TypeValidationError: Type validation failed Invalid input: expected "response.output_text.delta" ``` ## Reproduction Steps 1. Configure OpenAI provider to point to an OpenAI-compatible proxy: ```json { "provider": { "openai": { "options": { "apiKey": "your-api-key", "baseURL": "http://localhost:8045/v1" } } } } ``` 2. Run any opencode command 3. Parse error occurs ## Environment - **OS:** Windows 11 - **opencode version:** v1.0.150+ - **oh-my-opencode version:** v2.14.0 ## Root Cause opencode's OpenAI provider uses OpenAI's new Responses API format instead of the widely-adopted Chat Completions API. Most OpenAI-compatible proxies only implement Chat Completions API. ## Workaround **Use Anthropic provider instead:** If your proxy supports Anthropic API format (`/v1/messages`): ```json { "provider": { "anthropic": { "options": { "apiKey": "your-api-key", "baseURL": "http://localhost:8045/v1" } } } } ``` ## Expected Behavior Ideally, opencode should support both: 1. Traditional Chat Completions API (for compatibility with most proxies) 2. New Responses API (for official OpenAI) Or at least provide a configuration option to choose between them. ## Proposed Solutions 1. Add a `useResponsesApi` or `apiVersion` option in OpenAI provider config 2. Fallback to Chat Completions if Responses API is not supported 3. Support both formats based on provider configuration ## Additional Notes This is a design limitation, not a bug per se. However, it significantly reduces compatibility with OpenAI-compatible proxies, which are widely used by developers.
yindo added the discussion label 2026-02-16 17:45:12 -05:00
yindo commented 2026-02-16 17:45:12 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 11, 2026):

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

  • #5674: Custom OpenAI-compatible provider options not being passed to API calls - Describes options from config not reaching the actual provider
  • #5163: Custom baseURL configuration returns 'Route /api/messages not found' error - Another case of custom configuration not working
  • #2387: Omit textVerbosity option for providers other than Azure - Related to parameter injection issues with OpenAI-compatible endpoints
  • #2915: LiteLLM error: Anthropic doesn't support tool calling - Shows parameter handling issues with OpenAI-compatible proxies
  • #6346: Devstral via LiteLLM OpenAI-compatible fails with invalid_request_message_order - Another OpenAI-compatible provider compatibility issue

These issues all relate to OpenAI-compatible provider configuration and API compatibility. Your feature request about supporting traditional Chat Completions API may be partially addressed by fixing the underlying issues with how options are passed to custom OpenAI-compatible providers.

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Jan 11, 2026): This issue might be a duplicate of existing issues. Please check: - #5674: Custom OpenAI-compatible provider options not being passed to API calls - Describes options from config not reaching the actual provider - #5163: Custom baseURL configuration returns 'Route /api/messages not found' error - Another case of custom configuration not working - #2387: Omit textVerbosity option for providers other than Azure - Related to parameter injection issues with OpenAI-compatible endpoints - #2915: LiteLLM error: Anthropic doesn't support tool calling - Shows parameter handling issues with OpenAI-compatible proxies - #6346: Devstral via LiteLLM OpenAI-compatible fails with invalid_request_message_order - Another OpenAI-compatible provider compatibility issue These issues all relate to OpenAI-compatible provider configuration and API compatibility. Your feature request about supporting traditional Chat Completions API may be partially addressed by fixing the underlying issues with how options are passed to custom OpenAI-compatible providers. Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:45:12 -05:00
Author
Owner
Copy Link
Copy Source

@joshrad-dev commented on GitHub (Jan 25, 2026):

I think your issue is that you're not using the Openai-compatible provider and trying to use the openai provider directly. The openai-compatible uses chat/completions

@joshrad-dev commented on GitHub (Jan 25, 2026): I think your issue is that you're not using the Openai-compatible provider and trying to use the openai provider directly. The openai-compatible uses chat/completions
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label discussion
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#4733
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?