Skip to content

DeepSeek API key overwritten, causing a 401 - CC Switch

Quick fix

Upgrade cc-switch to v3.16.2+ and re-enter the DeepSeek API key, so it is not overwritten by another key when switching provider.

Error output
开启路由还是报错401,配置走的官方文档
English translation

Still 401 with routing on, configured per the official documentation

In cc-switch 3.16.1 - 3.16.3, switching between providers (DeepSeek, OpenRouter, Xiaomi MiMo) while toggling local routing could make the proxy config backup/restore logic overwrite the API key in the current live config with another provider's key, so authentication for the target provider fails with a 401 or "reconnect failed 5 times". Maintainers fixed the proxy backup/restore logic in v3.16.2, but some users report the config still being changed back on 3.16.2/3.16.3.

The cluster also mixes in other variants: mimo-v2.5-pro returning a 400 model-not-supported when Codex signs in with a ChatGPT account; DeepSeek failing after a successful first turn, possibly from sending an image to the DeepSeek API; DeepSeek V4 not being multimodal, so dragging an image on macOS reports it unsupported; and a Zhipu GLM "query failed" caused by the usage query defaulting to the Coding Plan — not the same problem as the key being overwritten.

  1. Upgrade cc-switch to v3.16.2 or newer. If it still reproduces on v3.16.3, roll back to v3.16.2 or watch the upstream tracking issue for the merged fix.

  2. After upgrading, open the DeepSeek provider config again and check whether the API key has become an OpenRouter, Xiaomi MiMo, or other provider key. If it was overwritten, paste the official DeepSeek API key back in and save.

  3. Avoid switching frequently between several third-party providers while toggling local routing repeatedly. After a switch, confirm the current provider API key, base_url, and routing state before starting Codex.

  4. If you still get a 401, close Codex, select DeepSeek again in cc-switch, turn routing on, and restart Codex to test.

ToolCodex
Version3.16.1 - 3.16.3
PlatformsWindowsmacOS
Why does the API key become another provider's key after switching to DeepSeek?
A config overwrite problem in the proxy backup/restore of early cc-switch versions, especially easy to trigger when switching third-party providers and toggling routing. Upgrading to v3.16.2+ should improve it, though some users still need to re-enter the key by hand.
It still gets overwritten after upgrading to v3.16.2. What now?
Users report the config still being changed back on v3.16.2/3.16.3. Roll back to v3.16.2, avoid complex switching sequences, or add/enter the DeepSeek config by hand. If it keeps reproducing, report back with your version number and reproduction steps.
Is the 400 saying The 'mimo-v2.5-pro' model is not supported when using Codex with a ChatGPT account also this key overwrite problem?
No. That is a 400 for a model Codex does not support with a ChatGPT account. Use a compatible model or login method, or see the CCMimoLink approach.
DeepSeek works for the first turn and then errors. Is the API key overwritten?
Not necessarily. Users in the issue point out that sending an image to the DeepSeek API errors. If later requests contain images or multimodal content, confirm the model supports that input.
Zhipu GLM shows "query failed" while the API works. Is that key overwriting?
Usually not. That is mostly the usage query defaulting to Coding Plan/Token Plan while the account has no such subscription. If the API itself works, turn the usage query off or customise it.

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.