Repository navigation
[FEATURE]: Support DeepSeek's Anthropic-compatible endpoint for the official DeepSeek provider (V4.1 Flash) #55684
Description
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
Feature hasn't been suggested before
A related request (#40261, deepseek-v4 models on anthropic/responses endpoints) was closed as not planned. This one is narrower and based on what has changed since: DeepSeek V4.1 Flash is now a model people actively use for coding agents, and other harnesses have shipped this integration in the meantime.
Describe the enhancement
DeepSeek officially provides an Anthropic-compatible endpoint (https://api.deepseek.com/anthropic) next to its OpenAI-compatible one, and documents it specifically for agentic coding tools (their official Claude Code integration guide uses it, with model mapping claude-opus* → v4-pro, claude-sonnet*/haiku* → v4-flash). In opencode, the built-in DeepSeek provider only talks to the OpenAI-compatible endpoint. Please add first-class support for using DeepSeek models — especially DeepSeek V4.1 Flash — through the Anthropic-compatible endpoint.
Why it matters
- Tool calling on DeepSeek's OpenAI-compatible route keeps breaking in agent loops (frequent tool-calling failures reported by users, e.g. [FEATURE]: Strongly recommend supporting Anthropic and OpenAI API endpoints for the opencode Go model #30244), while the same models behave correctly through the Anthropic endpoint.
- Command Code already supports DeepSeek V4.1 Flash via the Anthropic (Messages) endpoint, and Claude Code works with it today. In opencode, users currently have to hand-roll a custom provider config to get the same setup.
- The Anthropic route is DeepSeek's own recommended path for coding agents, including thinking/reasoning support.
Notes for implementation
Known quirks of the upstream endpoint: anthropic-version/anthropic-beta headers are ignored; thinking budget_tokens is ignored (effort only); unsupported model names are silently mapped to v4-flash. Handling reasoning-block pass-back in multi-turn conversations is the main thing to get right.
Activity
opencode-agent commentedon Oct 15, 2026
Thanks for the detailed request! To restate it: you'd like the built-in DeepSeek provider to be able to talk to DeepSeek's official Anthropic-compatible endpoint (
https://api.deepseek.com/anthropic), especially for DeepSeek V4.1 Flash, with thinking blocks handled correctly across turns, instead of only the OpenAI-compatible Chat Completions route.I checked the current v2 code. The built-in
deepseekprovider only has a Chat Completions route (https://api.deepseek.com/v1). v2 already has an Anthropic Messages implementation, which is why the custom provider config you mentioned works for now. Maintainers will consider this request.Related issues:
neriousy commentedon Oct 21, 2026
Thanks for the detailed request. We're not planning to switch the built-in DeepSeek provider to the Anthropic-compatible endpoint right now, but you can use that route today with a small custom provider:
{ "$schema": "https://opencode.ai/config.json", "providers": { "deepseek-anthropic": { "name": "DeepSeek (Anthropic API)", "env": ["DEEPSEEK_API_KEY"], "package": "@opencode/ai/providers/anthropic-compatible", "settings": { "baseURL": "https://api.deepseek.com/anthropic/v1" }, "models": { "deepseek-v4-flash": { "name": "DeepSeek V4 Flash" } } } } }See https://opencode.ai/v2/docs/providers#custom and https://opencode.ai/v2/docs/providers#packages. If tool calls keep failing on the built-in provider's Chat Completions route, please open a bug with a reproduction so we can fix it there. Closing as not planned.