Skip to content
CC Switch WikiUnofficial Community Wiki

HTTP 400 / Error 400 - cc-switch

Quick fix

Upgrade cc-switch first and verify API format and auth fields per provider; if HTTP 400 persists, fix the request using the exact upstream field. Copilot fix…

Symptom

Section titled “Symptom”
Error output
CC Switch local proxy failed while handling Codex endpoint /responses. Provider: codextest; model: gpt-5.4; upstream_status: HTTP 400; cause: Invalid 'input[6].name': empty string. Expected a string with minimum length 1, but got an empty string instead.

Cause

Section titled “Cause”

These issues do not share one identical HTTP 400 message, but they share a pattern: after the cc-switch local proxy or format-conversion layer forwards the request upstream, the upstream rejects the body as invalid and returns HTTP 400. #4578 is Codex `/responses` rejected because `input[6].name` is an empty string; #1921 is NVIDIA Qwen requiring, under `openai_chat` format, that the system role message be at the start of the messages array, otherwise it reports “System message must be at the beginning”; #1749 is explained as input length 174,551 exceeding the model's 128,000 limit, so the adapter computed a negative `max_tokens` and sent it upstream; #1858 attributes GitHub Copilot Error 400 to incompatible request format or authentication headers.

The fix status is contradictory: in #1858 the maintainer said v3.13.0 closed the Copilot Error 400 sub-item #1777, but users still reported it on v3.12.3 and after “updating to the latest version”; another user reported that Copilot with `AUTH_TOKEN` asks for login, while `API_KEY` shows error400. So this page cannot present one step as a confirmed final fix for every HTTP 400.

Fix

Section titled “Fix”

  1. First record the full `upstream_status` and `cause` in the error: empty `input[6].name`, system message position, negative `max_tokens`, and Copilot Error 400 are different variants and must not share one patch.

  2. Upgrade to the latest cc-switch; if you use GitHub Copilot, verify at least a version after v3.13.0, because the maintainer said it fixed Copilot Auth and Error 400 related sub-items, while keeping in mind that users still reported it as unfixed.

  3. Check API format and authentication fields against the provider: NVIDIA OpenAI-compatible endpoints need `openai_chat`, and Qwen 3.5 strictly requires the system message at the beginning of messages; if Copilot `AUTH_TOKEN` triggers `/login` and `API_KEY` triggers 400, report that mapping together with the version number instead of changing blindly.

  4. If the error looks like `max_token must at least 1, not -46551`, first compress history and code context so the input is below the model window limit; the mechanism in #1749 is that the model limit minus input length becomes negative.

  5. If the error is Codex `/responses` with `Invalid 'input[6].name': empty string`, the current issue gives no confirmed fix; save the cc-switch version, Provider, model, full `cause`, and whether proxy/rectifier is enabled, then add a reproduction to the original issue.

Affected Versions

Section titled “Affected Versions”
Toolcc-switch 本地代理/格式转换（报告中涉及 Claude Code、Codex、OpenCode）
Version报告版本包含 3.12.3 与 3.16.3；维护者称 Copilot 的 Error 400 在 v3.13.0 修复，但有用户反馈更新后仍存在
PlatformsWindows

Source Issues

Section titled “Source Issues”

This page is distilled from 4 real issues

FAQ

Section titled “FAQ”
Has the Copilot GPT 400 issue been resolved?
In the v3.13.0 status update for #1858, the maintainer said #1777 was closed, but later users replied that it looked unresolved, and someone reported the issue still existed after updating to the latest version, so it cannot be treated as consistently confirmed fixed.
Is it still unresolved in 3.14?
The thread gives no clear conclusion for 3.14; only the v3.13.0 status table says most Copilot sub-items were closed, while users continued reporting Error 400, so use your local full `cause` and version number as the basis.
For Copilot authentication, should I choose `AUTH_TOKEN` or `API_KEY`?
A user reported: choosing `AUTH_TOKEN` asks for login, while choosing `API_KEY` shows error400; this means both fields can fail in different environments, and the Issues do not give a universally confirmed choice.
Why is Codex not supported?
This cluster only proves there was a report that Codex on cc-switch 3.16.3 / Windows had `/responses` rejected by upstream with HTTP 400; the Issues do not conclude whether cc-switch fully supports Codex.
Why does NVIDIA Qwen report “System message must be at the beginning”?
#1921 says NVIDIA Qwen 3.5 strictly requires the system role message to be the first element of the messages array; this HTTP 400 appears when using `openai_chat` format with the NVIDIA OpenAI-compatible endpoint.
Section titled “Related problems”
Login required: Claude Code login prompt after takeover with Codex OAuthUser-tested: after Claude takeover, keep ANTHROPIC_AUTH_TOKEN (even empty) in ~/.claude/settings.json env before starting Claude Code to avoid login prompts.1 issues mergedError from provider (Console Go): Upstream request failedCheck whether the model mapping was applied. If the target model is unavailable or the request body contains an unsupported tool_choice or image… (cc-switch)5 issues mergedAPI Error: 400 model_not_supportedRestart CC Switch to repair the proxy routing, or confirm whether the model ID requested became invalid after a Copilot policy change.2 issues merged

This is an unofficial community wiki with no affiliation to the cc-switch authors or the project itself. Its content is compiled from the project's public GitHub issues. This site distributes no software.