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
[FEATURE]: Serve DeepSeek models on OpenCode Go's Anthropic Messages endpoint (DeepSeek V4.1 Flash in Claude Code) #55714
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
#30244 asked for Anthropic endpoints for OpenCode Go models back in June and was closed without being implemented. This is the concrete, narrowed version of that request: one model family (DeepSeek) on Go's existing Messages endpoint. (My #55684 is a different request — the built-in DeepSeek provider with a user's own DeepSeek API key, not the Go service.)
Describe the enhancement
OpenCode Go's endpoint table assigns each model a single protocol. The Anthropic Messages endpoint (https://opencode.ai/inference/go/v1/messages) currently serves the MiniMax, Qwen and Claude Haiku models. DeepSeek V4.1 Flash (deepseek-v4.1-flash) and V4 Pro are assigned to Chat Completions only, and a Messages request for them returns 422 "Endpoint is unavailable". Please serve the DeepSeek models on Go's Messages endpoint as well, so Go subscribers can use them from Anthropic-protocol clients — above all Claude Code, which Go's own documentation lists as a validated client.
Why it matters
Claude Code only speaks the Anthropic Messages protocol. Today, a Go subscriber cannot spend their DeepSeek quota in Claude Code natively at all. The only workaround is a third-party local proxy (e.g. oc-go-cc) that translates Messages → Chat Completions and back — an extra moving part that struggles with exactly the hard cases: tool calls and thinking/reasoning content.
A direct competitor already ships this. Command Code supports DeepSeek V4.1 Flash through the Anthropic (Messages) endpoint today. Go and Command Code are competing for the same subscribers, and every Go user who wants DeepSeek inside Claude Code currently has a concrete reason to look elsewhere. This is quickly becoming table stakes.
The upstream makes it straightforward: DeepSeek itself operates an Anthropic-compatible endpoint and documents Claude Code integration against it, so serving DeepSeek over Messages is a proven path — for Go it is mostly routing, not translation.
The Chat Completions route for Go's DeepSeek models has open reliability reports (e.g. deepseek v4.1 flash bug tools calling #51077, tool-calling failures), which a native Messages route would sidestep for Claude Code users.
Notes for implementation
Same models, same metering — this only adds a protocol surface; Go quotas and limits stay unchanged. Per the docs, Claude Code is already recognized by Go via its native session header. The main correctness point is passing thinking blocks back correctly across turns, matching the semantics of DeepSeek's own Anthropic endpoint.
Thanks for the clear and well-scoped request! In short: you'd like OpenCode Go to serve its DeepSeek models (deepseek-v4.1-flash, V4 Pro) on the Anthropic Messages endpoint (/inference/go/v1/messages) as well as Chat Completions. That way Go subscribers could use them natively in Claude Code instead of going through a proxy that translates between the two protocols.
This is a change to the Go service rather than the OpenCode app, and maintainers will consider it. I can't promise anything about whether or when it happens.
Hey @lindun-arch — good news: you actually don't need a third-party translation proxy! DeepSeek V4.1 Flash is already live and natively served on OpenCode Go's Anthropic Messages endpoint.
The 422 you saw occurs because the path in your report (/inference/go/v1/messages) is missing the protocol segment. The active endpoint is:
(Note: Go requires a session header, but Go natively recognizes Claude Code's session header so no custom wrapper is needed).
The only current quirk is that omitting thinking on this route defaults to dynamic reasoning enabled, which slows down fast background/classifier checks — tracking that fix in #56678. But for primary coding, it works natively today!
You were right that the path in my original report was missing the /anthropic/ segment. Really appreciate you pointing this out — this was exactly what I was hoping for when I filed this issue.
Hi @i-am-oliver — following up on your config, which worked great at first (thank you again). Starting today I'm hitting API Error: 400 {"model":"deepseek-v4.1-flash"} more and more frequently in Claude Code, even though nothing changed on my end (ANTHROPIC_BASE_URL=https://opencode.ai/inference/go/anthropic, ANTHROPIC_DEFAULT_SONNET_MODEL=deepseek-v4.1-flash). Do you have any idea what causes this, and is there a good way to work around or fix it?
Activity
opencode-agent commentedon Oct 15, 2026
Thanks for the clear and well-scoped request! In short: you'd like OpenCode Go to serve its DeepSeek models (
deepseek-v4.1-flash, V4 Pro) on the Anthropic Messages endpoint (/inference/go/v1/messages) as well as Chat Completions. That way Go subscribers could use them natively in Claude Code instead of going through a proxy that translates between the two protocols.This is a change to the Go service rather than the OpenCode app, and maintainers will consider it. I can't promise anything about whether or when it happens.
Related issues, for context:
/v1/messages"Endpoint is unavailable" reports for specific models and request shapes.i-am-oliver commentedon Oct 18, 2026
Hey @lindun-arch — good news: you actually don't need a third-party translation proxy! DeepSeek V4.1 Flash is already live and natively served on OpenCode Go's Anthropic Messages endpoint.
The 422 you saw occurs because the path in your report (
/inference/go/v1/messages) is missing the protocol segment. The active endpoint is:You can point Claude Code directly to it without any proxy by setting:
ANTHROPIC_BASE_URL:https://opencode.ai/inference/go/anthropicANTHROPIC_AUTH_TOKEN: your OpenCode Go key (oc_sk_...)ANTHROPIC_DEFAULT_SONNET_MODEL:deepseek-v4.1-flash(Note: Go requires a session header, but Go natively recognizes Claude Code's session header so no custom wrapper is needed).
The only current quirk is that omitting
thinkingon this route defaults to dynamic reasoning enabled, which slows down fast background/classifier checks — tracking that fix in #56678. But for primary coding, it works natively today!lindun-arch commentedon Oct 19, 2026
@i-am-oliver Thank you so much — confirmed working! I just tested it end-to-end in Claude Code with the exact setup you shared (ANTHROPIC_BASE_URL=https://opencode.ai/inference/go/anthropic and ANTHROPIC_DEFAULT_SONNET_MODEL=deepseek-v4.1-flash), and DeepSeek V4.1 Flash responds normally — no translation proxy needed.
You were right that the path in my original report was missing the /anthropic/ segment. Really appreciate you pointing this out — this was exactly what I was hoping for when I filed this issue.
neriousy commentedon Oct 20, 2026
Thanks for confirming that DeepSeek V4.1 Flash works directly in Claude Code with ANTHROPIC_BASE_URL=https://opencode.ai/inference/go/anthropic. The original URL was missing the /anthropic/ segment, so I'm closing this as resolved.
lindun-arch commentedon Oct 21, 2026
Hi @i-am-oliver — following up on your config, which worked great at first (thank you again). Starting today I'm hitting
API Error: 400 {"model":"deepseek-v4.1-flash"}more and more frequently in Claude Code, even though nothing changed on my end (ANTHROPIC_BASE_URL=https://opencode.ai/inference/go/anthropic, ANTHROPIC_DEFAULT_SONNET_MODEL=deepseek-v4.1-flash). Do you have any idea what causes this, and is there a good way to work around or fix it?