exceeded retry limit, last status: 429 Too Many Requests - cc-switch Codex/GLM
Quick fix
An incorrect GLM preset URL can cause 429: delete the old GLM provider, create the official preset in cc-switch, confirm it uses a Coding Plan link, and check…
Symptom
Section titled “Symptom”exceeded retry limit, last status: 429 Too Many RequestsThis issue is most common when connecting GLM Coding Plan to Codex. Community reports indicate that early cc-switch GLM presets pointed to the standard API endpoint rather than a Coding Plan link, triggering rate limits as soon as they were used. Codex’s fixed-interval retry strategy can also create a retry storm after a 429 and increase request volume. In addition, GLM Coding Plan consumes quota at 3× the rate during peak hours from 14:00 to 18:00, making lower-tier plans easier to exhaust. A separate scenario (issue #6022) is that cc-switch’s automatic failover toggle `auto_failover_enabled` is unexpectedly reset to 0 during a manual hot switch, preventing automatic switching to a backup node when the primary provider gets a 429.
In cc-switch, delete the existing GLM provider, then click the “+” in the top-right to create the official preset (do not copy the old configuration). Make sure the URL is a Zhipu Coding Plan link.
Confirm that the currently signed-in Zhipu account matches the account used to obtain the API Key. If they differ, switch accounts and try again.
If Codex still returns 429, check its retry settings. Change fixed-interval retries to exponential backoff and add jitter.
Avoid using the service during peak hours from 14:00 to 18:00 (UTC+8), or reduce concurrency to prevent quota from being consumed at 3× the rate.
If automatic failover is configured for multiple providers but does not switch on 429, manually use SQL to check and reset the switch (`SET`): UPDATE proxy_config SET auto_failover_enabled=1 WHERE app_type='claude' (note: manually hot-switching providers will reset it to 0 again).
数据库路径（Windows 用户目录下） cc-switch.dbUPDATE proxy_config SET auto_failover_enabled=1 WHERE app_type='claude'
Affected Versions
Section titled “Affected Versions”Source Issues
Section titled “Source Issues”This page is distilled from 3 real issues
- Why does Codex return 429 as soon as I use it, but creating a new provider fixes it?
- The old cc-switch GLM preset URL pointed to the standard API rather than Coding Plan. Delete it and create the official preset using the “+” in the top-right.
- Does a 429 error mean the configuration is wrong?
- Not necessarily. The resolution for issue #4120 says that signing into the wrong account (the API Key and signed-in account do not match) can cause 429. GLM Coding Plan also consumes quota at 3× the rate during peak hours from 14:00 to 18:00, making lower-tier plans more likely to hit rate limits.
- Why do Zhipu/Minimax make hundreds of calls within a minute and burn through the quota instantly?
- This is caused by a client retry storm. If the client retries frequently at fixed intervals instead of using exponential backoff after a failed request or 429, it can send many duplicate requests in a short time. Temporary mitigations include setting the provider concurrency limit to 1–2 or limiting the maximum requests per minute at the proxy layer.
- Why doesn’t automatic failover switch to the next provider when a 429 occurs?
- According to issue #6022, cc-switch has a bug: manually hot-switching providers (or clicking the UI toggle in some cases) resets `auto_failover_enabled` in the database to 0, disabling automatic failover. You can manually change it back to 1 with SQL, but it will be reset again after a manual switch.
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.