/provider/v1/messages: 403 "Authentication failed" for claude-sonnet-5-5 and claude-haiku-5-5 only (auth passes for other models)

The report identifies POST /provider/v1/messages and the affected model IDs, but it does not point to repository files, tests, or implementation entry points. Start by locating the handler and tracing its authentication and plan-check paths for these IDs. Done when valid credentials receive an appropriate response for both models and genuine credential failures remain distinguishable.

Describe the bug

POST https://api.commandcode.ai/provider/v1/messages returns HTTP 403 for two model IDs:

{"type":"error","error":{"type":"permission_error","message":"Authentication failed. Please check your credentials."}}

with model=claude-sonnet-5-5 and model=claude-haiku-5-5. The credentials are valid — auth passes for every other model on the same endpoint with the same key.

Started 2026-10-16 ~11:00 CST (03:00 UTC). Last success 10:59:51, first 403 11:00:30.

Evidence that this is server-side (auth is evaluated before the plan check, and passes)

Same key, same second, same User-Agent:

The two MODEL_NOT_IN_PLAN rows are the point: they are ordinary business errors, so auth runs before the plan check and it passed. Auth therefore passes for claude-sonnet-5 but fails for claude-sonnet-5-5, on the same endpoint, same key — that is the inconsistency.

To Reproduce

KEY='user_...'
UA='claude-cli/2.1.300 (external, cli)'

# key valid & funded -> 200
curl -s -H "Authorization: Bearer $KEY" -H "User-Agent: $UA" \
  https://api.commandcode.ai/alpha/billing/credits

# another model, SAME endpoint -> 403 MODEL_NOT_IN_PLAN (auth passed)
curl -s -X POST https://api.commandcode.ai/provider/v1/messages \
  -H "Authorization: Bearer $KEY" -H "User-Agent: $UA" \
  -H 'content-type: application/json' -H 'anthropic-version: 2023-06-01' \
  -d '{"model":"claude-sonnet-5","max_tokens":16,"messages":[{"role":"user","content":"hi"}]}'

# the problem case -> 403 Authentication failed
curl -s -X POST https://api.commandcode.ai/provider/v1/messages \
  -H "Authorization: Bearer $KEY" -H "User-Agent: $UA" \
  -H 'content-type: application/json' -H 'anthropic-version: 2023-06-01' \
  -d '{"model":"claude-sonnet-5-5","max_tokens":16,"messages":[{"role":"user","content":"hi"}]}'

Ruled out

• Bad key / out of credits: billing 200 ($63.44), deepseek 200, and business errors on the same endpoint. A genuinely exhausted key answers 400 "insufficient credits", not 403 (we have a second key on the account showing exactly that, so the two signatures are distinguishable).
• Rate limiting: reproduced with single requests 6–8 s apart, and again after a 3-minute cooldown.
• Request body / thinking shape: a 400 "Invalid input at thinking" appeared immediately before the first 403 in our logs, so we tested thinking.type=enabled with budget_tokens, thinking.type=adaptive, and a plain body with no thinking. All three now return the same 403.
• User-Agent: claude-cli/2.1.300, magpie/0.1.1265, and Python-urllib give the identical 403.
• Auth header shape: Authorization: Bearer, x-api-key, and both together — identical 403.
• Payload size: a 200 KB body behaves the same as a 40-byte body.

Impact

Beyond the two models being unusable via the Anthropic endpoint: the error text is indistinguishable from a real credential failure. Claude Code maps a 403 to "credentials rejected" and shows the login flow, so clients show /login repeatedly while the key is valid and funded, and users rotate perfectly good keys. Any client that auto-retries on 401/403 will also thrash.

What would help

1. Return 403 MODEL_NOT_IN_PLAN for these two IDs (as you already do for claude-sonnet-5 / claude-opus-5) if they are not on the current plan; reserve 403 Authentication failed for requests whose credentials truly did not validate.
2. Check why auth rejects these two model IDs specifically when other models pass on the same endpoint.
3. If this was an intentional plan change at ~03:00 UTC on 2026-10-16, a changelog line and a distinct error code would save people from debugging credentials that were never broken.

Account: [email protected] (GitHub: @lqisgod). Happy to provide raw request/response captures or test further on our account.