Skip to content
CC Switch WikiUnofficial Community Wiki

exceeded retry limit, last status: 429 - Codex

Quick fix

Limit client concurrency and retry frequency, and fix the cc-switch bug where hot switching disables automatic failover, with SQL.

Symptom

Section titled “Symptom”
Error output
exceeded retry limit, last status: 429 Too Many Requests

Cause

Section titled “Cause”

Proxying requests to a provider such as Zhipu GLM or MiniMax through cc-switch, network jitter or provider rate limiting (a peak-hour multiplier deduction triggering 429) puts the client into a high-frequency retry loop — a client-side retry storm. Without exponential backoff in the retry strategy, consecutive 429 responses compound the storm, exhausting the token quota in moments and erroring out.

cc-switch also has a bug: hot-switching provider by hand from the tray menu resets auto_failover_enabled to 0 in the database. Automatic failover then does nothing, so when the primary node returns 429 the system keeps erroring rather than switching to a backup.

Fix

Section titled “Fix”

  1. Set a maximum requests per minute (max_requests = 10, for example) and a per-conversation max_tokens in a proxy in front of cc-switch, such as Nginx, to physically block the retry storm and stop the quota draining fast.

  2. Quit cc-switch completely, open the database with a SQL tool, and run an update forcing auto_failover_enabled to 1, so a 429 switches to the backup node automatically.

    -- cc-switch.db
    UPDATE proxy_config SET auto_failover_enabled=1 WHERE app_type='claude';

  3. Until this bug is fixed officially, apply config changes with a cold start (quit and restart cc-switch completely), and absolutely avoid switching provider by hand from the tray menu, which silently resets the switch to 0 again.

  4. Confirm your API key is correct and that Zhipu GLM uses the Coding Plan dedicated link (the preset is fixed in newer versions). Schedule high-concurrency work outside peak hours (avoid 14:00-18:00 UTC+8) to reduce rate limiting.

Affected Versions

Section titled “Affected Versions”
ToolClaude Code / Codex
Version3.15.0 - 3.19.1
PlatformsWindows

Source Issues

Section titled “Source Issues”

This page is distilled from 3 real issues

FAQ

Section titled “FAQ”
Why does my token quota drain in minutes?
A client-side retry storm. When the provider returns 429 or times out, a client without a proper exponential backoff strategy retries at an enormous rate (100+ per second), consuming the quota fast.
The log says enabled=true — why does a 429 still not switch automatically?
The enabled=true in the log comes only from the front-end UI toggle path. If you ever switched provider by hand from the tray menu, auto_failover_enabled was silently reset to 0 in the database, so the runtime state does nothing.
Zhipu GLM always reports 429. Is my config wrong?
Not necessarily. Zhipu GLM deducts quota at 3x during peak hours (14:00-18:00 UTC+8), which readily triggers rate limiting. Also make sure you use the Coding Plan dedicated link and check the account behind your API key is right.
Section titled “Related problems”
cc-switch DeepSeek usage statistics inaccurate / balance query failsUpgrade to v3.19.2 and rebuild Codex usage. The balance query needs a correct {{apiKey}}, or a proxy.17 issues mergedDeepSeek prefix cache hit rate drop - CC Switch fixUpgrade to cc-switch v3.16.3 to fix cache hit rate calculation errors caused by format conversion.2 issues mergedFailed to fetch models - cc-switchUpgrade cc-switch to v3.16.4+ for the 404 probe fix. On a Coding Plan, change the API address by hand and enter the model names yourself.4 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.