invalid_authentication_error Test Failure HTTP 401 cc-switch
Quick fix
An unreplaced {{apiKey}} variable in the usage query script causes 401. Upgrade cc-switch to the latest version; temporarily enter the Key as a literal.
Symptom
Section titled “Symptom”测试失败: HTTP 401 Unauthorized : {"error":{"message":"Invalid Authentication","type":"invalid_authentication_error"}}Test failed: HTTP 401 Unauthorized : {"error":{"message":"Invalid Authentication","type":"invalid_authentication_error"}}
cc-switch custom usage query scripts support placeholders such as {{apiKey}} and {{baseUrl}}, but variable parsing has a defect in v3.14.1 / v3.15.0: {{apiKey}} is not replaced with the real Key, so the request is sent to the provider (such as Kimi's api.moonshot.cn) with the unreplaced placeholder, and the server returns 401 invalid_authentication_error. Users verified that the same Key works when calling the official API directly with curl, and the test passes after changing 'Bearer {{apiKey}}' to a literal, showing that the Key itself is valid and the problem is variable substitution. The test script path and actual query path also behave differently: refreshing the home page retrieves the balance, but clicking “Test Script” in the dialog returns 401.
Note that this error code has another variant (issue #7990): when using the kimi k3 256k model in Codex desktop app aggregation mode, the upstream error is (400), and error.type also shows invalid_authentication_error, but the message is actually "Your request exceeded k3-256k model token limit: 262144". Maintainer testing confirmed that when the default provider in aggregation mode is the official ChatGPT login, Desktop includes many tool schemas for app connectors, plugins, browsers, and other tools, so the request body can easily exceed 400,000 bytes. This is a separate issue from the usage query variable substitution bug; only the error type field is the same.
Upgrade cc-switch to the latest version. The maintainer confirmed that commits in v3.15.0 / v3.16.0 fixed this: usage query script variable parsing now supports common aliases such as {{apiKey}} / {{baseUrl}} and whitespace variants such as {{ apiKey }}、{{api_key}}、{{base_url}}. It also treats isValid: false as an invalid result, and POST request.body now supports JSON objects and arrays.
If you cannot upgrade yet, use a temporary workaround: in the extractor code, replace Authorization: 'Bearer {{apiKey}}' with the real API Key as a literal (you can click the eye icon next to “Supported Variables” to copy the Key, then replace {{apiKey}}). The user confirmed that the test succeeds after this change.
If your error is the token limit variant, 上游错误 (400) for kimi k3 256k in Codex desktop app aggregation mode: the maintainer recommends switching to the Codex CLI version or using another model in the desktop app. Direct mode, aggregation mode in CLI, and k3 models other than 256k are unaffected.
Affected Versions
Section titled “Affected Versions”Source Issues
Section titled “Source Issues”This page is distilled from 3 real issues
- Why does the test succeed when I replace {{apiKey}} with a hard-coded Key, but return 401 when I use the variable?
- Because older versions of the usage query script did not replace the {{apiKey}} placeholder with the real Key, so the request was sent to the provider with the literal placeholder and authentication failed. The same Key works when calling the official API directly with curl, confirming that the Key itself is valid. Variable parsing is fixed in the latest version, which supports common forms such as {{apiKey}}, {{ apiKey }}, and {{api_key}}.
- Why does the “Test Script” dialog return 401, while refreshing the home page retrieves the balance correctly?
- This was another known inconsistency in older versions: variable parsing behaved differently in the test script path and the actual query path. The issue was fixed together with variable parsing, so both paths behave consistently after upgrading; isValid === false is also treated as a failure and displays an error message.
- In aggregation mode, does kimi k3 256k reporting exceeded token limit mean I selected the 1m context option by mistake?
- No. Codex has no 1m context option, and the user context was left at its default setting. Maintainer testing confirmed that when the default provider in aggregation mode is the official ChatGPT login, Desktop includes many tool schemas for app connectors, plugins, browsers, and other tools. The request body can exceed 400,000 bytes and trigger this error. The workaround is to switch to the CLI version or use another model.
Related problems
Section titled “Related problems”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.