Skip to content

[FEATURE]: Strongly recommend supporting Anthropic and OpenAI API endpoints for the opencode Go model #30244

Closed as not planned

Description

@1337Player

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

Based on my testing, when using DeepSeek V4 (which only supports the OpenAI-compatible endpoint) with Claude Code CLI, the only viable integration method is protocol translation through a proxy. However, the protocol translation layer appears to be incompatible with DeepSeek.

This results in frequent tool-calling failures and related errors. I have also tested the official DeepSeek OpenAI-compatible endpoint, and the same issue occurs. In contrast, when using the Anthropic endpoint, tool calls work normally without any problems.

Other models seem unaffected by this translation layer. For example, I tested MiniMax and did not encounter similar tool-calling issues.

My question is: has anyone observed compatibility issues between DeepSeek's OpenAI-compatible endpoint and the protocol translation layer used by Claude Code CLI? If so, what is the root cause of these frequent tool-calling failures, and are there any known workarounds or configuration changes that can improve compatibility?

Image

Activity

  1. github-actions commented on Jun 1, 2026

    @github-actions
    Contributor

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

    These issues describe the same or closely related problems with the protocol translation layer and DeepSeek/thinking-enabled models. Please review them before proceeding — if your issue is already tracked there, consider adding context or a thumbs-up rather than opening a new report.

  2. sontanon commented on Jun 7, 2026

    @sontanon

    OpenCode Go serves DeepSeek and Kimi only via /v1/chat/completions. Both providers also have Anthropic-compatible endpoints, which would fix the Claude Code tool-calling issues by eliminating the protocol translation layer entirely (see #24722, #26331)

    This is a zero-code config change. The schema at packages/console/core/src/model.ts:33 already supports formatFilter for dual-format models. Qwen 3.6 Plus already works this way (both /v1/messages and /v1/chat/completions). The anthropicHelper and body converter (provider.ts:182-185) are transparent proxies when formats match.

    What's needed is to add two provider entries and formatFilter additions in the Go model data (ZEN_MODELS* secrets):

    + "deepseek-anthropic": {api: "https://api.deepseek.com/anthropic", format: "anthropic", ...}
    + "moonshot-anthropic": {api: "https://api.moonshot.ai/anthropic", format: "anthropic", ...}
    
      "deepseek-v4-pro": [
        {formatFilter: "oa-compat", providers: [{id: "deepseek", ...}]},
    +   {formatFilter: "anthropic", providers: [{id: "deepseek-anthropic", model: "deepseek-v4-pro"}]}
      ]
      // same pattern for deepseek-v4-flash, kimi-k2.5, kimi-k2.6, etc.
  3. github-actions commented on Aug 7, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions