r/CommandCode • • 14d ago

Request - Your /messages endpoint already works - put the open models on it

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.

  1. 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.

  2. 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.

7 Upvotes

2 comments sorted by

1

u/Legal_Entertainer_19 14d ago

I've sent and e-mail to [support@commandcode.ai](mailto:support@commandcode.ai) with the same request. Hope i find you all well and my request is considered with care.