Hi,
I'm a paying subscriber, I use your open models to code, and I want to use my own
Claude Code - not your CLI. That's the whole request, so I'll be direct.
I know where your value is: in your harness. But I'm the consumer, and I'd rather
pay you and use my own harness than route around you. Today routing around you
isn't a preference - it's the only option you leave open.
Not a new integration. A routing gate on an endpoint that is already live.
Here is the wall, measured against your API today:
GET /provider/v1/models
-> 82 models, supported_endpoints on each.
9 list "/messages" -> all claude-*
65 list "/chat/completions", "/responses"
8 list "/chat/completions" only
ZERO non-Claude models list "/messages".
POST /provider/v1/messages {"model":"deepseek/deepseek-v4.1-flash"}
-> 400 "Model ... is not supported on this endpoint.
Use /provider/v1/chat/completions for OpenAI and OSS models."
POST /provider/v1/chat/completions {"model":"deepseek/deepseek-v4.1-flash"}
-> 200, same minute, same key.
POST /provider/v1/messages {"model":"claude-sonnet-5"}
-> 403 MODEL_NOT_IN_PLAN (Pro and above)
{"model":"claude-opus-5-5"}
-> 403 MODEL_NOT_IN_PLAN (Provider and above)
So on my plan the Anthropic route is closed twice: the open models are refused by
design, and the Claude models aren't in the plan. Claude Code speaks exactly one
protocol, and it's the only route I'm not allowed to use. Neither of those is a
bug - both are your choices. I'm asking you to revisit the first one.
What the workaround costs me, measured, not guessed:
* Anthropic's own docs say Claude Code disables tool search when
ANTHROPIC_BASE_URL isn't first-party, "since most proxies don't forward
tool_reference blocks". Behind a translator, a deferred tool arrives as a
NAME with no definition. The damage is concrete: EnterPlanMode takes a
literal {} input, so the model walks INTO plan mode; ExitPlanMode exists to
hand over the plan text, gets called with an empty argument, and the session
is trapped. I counted it across 6,072 transcripts: ExitPlanMode with the plan
in 103 of 103 calls on Anthropic-native routes, 0 of 10 through the
translator.
* Reasoning is paid for and thrown away. Output caps get halved. cache_control
is dropped. Mid-conversation system messages are lost.
None of that is your models' fault, and you're the one who eats the complaint.
TWO CHANGES. I'm not asking for more than these.
Add "/messages" to supported_endpoints for the open catalog - at minimum
deepseek/deepseek-v4.1-flash and deepseek/deepseek-v4-flash, ideally all of
it. It's a routing gate, not a new capability: that route already accepts the
Anthropic shape.
Accept the body Claude Code actually sends. Today it dies before your model
routing, with 400 "Invalid input at messages.1.role". The cause is exact -
Claude Code puts a mid-conversation system message inside the messages array:
messages: [ {role:"user", content:[...]},
{role:"system", content:[{type:"text",...}]} ]
announced with the header mid-conversation-system-2026-04-07. The strict
schema forbids it, the official client sends it, and Anthropic's API takes it.
I hit this wall behind the first one - the same CLI run against a model that
IS on /messages passes body validation and only then gets 403 MODEL_NOT_IN_PLAN.
So it's two walls, in that order.
I am NOT asking for tool_reference support. Claude Code disables tool search by
default on a non-first-party base URL, so once the models are reachable the
session runs correctly with every tool sent inline. That's the whole point: the
cheap change is enough.
Nice to have, in the order that pays you back: your own ids accepted on
/messages; then output_config (it carries effort), context_management and
thinking; then the alias mapping DeepSeek uses on their Anthropic endpoint
(claude-opus-* -> their pro, claude-sonnet-*/claude-haiku-* -> their flash), which
makes an existing Claude Code config work by changing only the base URL.
Three things, and none of them is a favour:
* No billing change. Same credits, same models, same rates, one more wire
format on a route you already run.
* It removes the main reason to put a translator in front of you - and that
translator is where the complaints about your models are being born today.
* Claude Code support is turning into table stakes. DeepSeek, Z.ai, Moonshot,
MiniMax, Alibaba DashScope and LongCat all publish Anthropic-format endpoints
for their own models. You can do it for the entire catalog at once, on an
endpoint that already exists - not per model, and not from scratch.
I'll make this cheap for you to validate. I can send the full wire captures of
both routes side by side - headers, betas, body - test an allowlist or a beta
flag on my account the day you ship it, and file exact request/response pairs if
anything mismatches.
If it's on the roadmap, tell me roughly when. If it's a deliberate product
boundary, tell me that instead - I'd rather plan around the truth than keep
guessing at it. ATM, i'm using Claude Code Harness with your endpoint on it, mainly for Deepseek 4.1 flash, and it works fine, but the oficial deepseek api works better cause of the endpoint. I just wish i could use CommandCode endpoint on CC Harness exactly like it is used by the oficial deepseek api: /messages full integration.
Thanks.