René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"/provider/v1/messages: 403 \"Authentication failed\" for claude-sonnet-5-5 and claude-haiku-5-5 only (auth passes for other models)","articleBody":"**Describe the bug**\n\n`POST https://api.commandcode.ai/provider/v1/messages` returns HTTP 403 for two model IDs:\n\n```json\n{\"type\":\"error\",\"error\":{\"type\":\"permission_error\",\"message\":\"Authentication failed. Please check your credentials.\"}}\n```\n\nwith `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.\n\nStarted 2026-10-16 ~11:00 CST (03:00 UTC). Last success 10:59:51, first 403 11:00:30.\n\n**Evidence that this is server-side (auth is evaluated before the plan check, and passes)**\n\nSame key, same second, same User-Agent:\n\n| request | result |\n|---|---|\n| `GET /alpha/billing/credits` | 200, `monthlyCredits` 63.44 (key valid, funded) |\n| `GET /provider/v1/models` | 200, 92 models incl. `claude-sonnet-5-5` |\n| `POST /provider/v1/messages` `claude-sonnet-5` | 403 **MODEL_NOT_IN_PLAN** ← auth passed |\n| `POST /provider/v1/messages` `claude-opus-5` | 403 **MODEL_NOT_IN_PLAN** ← auth passed |\n| `POST /provider/v1/messages` `claude-sonnet-5-5` | 403 **Authentication failed** ← only these two |\n| `POST /provider/v1/messages` `claude-haiku-5-5` | 403 **Authentication failed** |\n| `POST /provider/v1/chat/completions` `claude-sonnet-5-5` | 400 \"must be called via /messages\" (auth passed) |\n| `POST /provider/v1/chat/completions` `deepseek/deepseek-v4.1-flash` | 200 (key fully works) |\n\nThe 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.\n\n**To Reproduce**\n\n```sh\nKEY='user_...'\nUA='claude-cli/2.1.300 (external, cli)'\n\n# key valid & funded -> 200\ncurl -s -H \"Authorization: Bearer $KEY\" -H \"User-Agent: $UA\" \\\n  https://api.commandcode.ai/alpha/billing/credits\n\n# another model, SAME endpoint -> 403 MODEL_NOT_IN_PLAN (auth passed)\ncurl -s -X POST https://api.commandcode.ai/provider/v1/messages \\\n  -H \"Authorization: Bearer $KEY\" -H \"User-Agent: $UA\" \\\n  -H 'content-type: application/json' -H 'anthropic-version: 2023-06-01' \\\n  -d '{\"model\":\"claude-sonnet-5\",\"max_tokens\":16,\"messages\":[{\"role\":\"user\",\"content\":\"hi\"}]}'\n\n# the problem case -> 403 Authentication failed\ncurl -s -X POST https://api.commandcode.ai/provider/v1/messages \\\n  -H \"Authorization: Bearer $KEY\" -H \"User-Agent: $UA\" \\\n  -H 'content-type: application/json' -H 'anthropic-version: 2023-06-01' \\\n  -d '{\"model\":\"claude-sonnet-5-5\",\"max_tokens\":16,\"messages\":[{\"role\":\"user\",\"content\":\"hi\"}]}'\n```\n\n**Ruled out**\n\n- 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).\n- Rate limiting: reproduced with single requests 6–8 s apart, and again after a 3-minute cooldown.\n- 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.\n- User-Agent: `claude-cli/2.1.300`, `magpie/0.1.1265`, and Python-urllib give the identical 403.\n- Auth header shape: `Authorization: Bearer`, `x-api-key`, and both together — identical 403.\n- Payload size: a 200 KB body behaves the same as a 40-byte body.\n\n**Impact**\n\nBeyond 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.\n\n**What would help**\n\n1. 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.\n2. Check why auth rejects these two model IDs specifically when other models pass on the same endpoint.\n3. 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.\n\n**Account**: liuqing200kg@gmail.com (GitHub: @lqisgod). Happy to provide raw request/response captures or test further on our account.\n","author":{"url":"https://github.com/esp32gallery","@type":"Person","name":"esp32gallery"},"datePublished":"2026-10-16T15:39:53Z","url":"https://github.com/CommandCodeAI/commandcode-status/issues/26"}