exceeded retry limit, last status: 429 Too Many Requests - cc-switch Codex/GLM
Quick fix
glm 预设 URL 错了会导致 429：删除旧 glm 供应商，用 cc-switch 右上角「+」新建官方预设，确认是 Coding Plan 链接并核对账号。
Symptom
Section titled “Symptom”exceeded retry limit, last status: 429 Too Many Requests此问题在智谱 GLM Coding Plan 接入 Codex 时最常见。根据社区反馈，早期 cc-switch 的 glm 预设指向的是普通 API 接口而非 Coding Plan 链接，导致一使用就触发限流；同时，Codex 客户端的固定间隔重试策略在收到 429 后会形成重试风暴（retry storm），放大请求量。此外，GLM Coding Plan 在 14:00-18:00 高峰时段按 3 倍速率扣减配额，低档位套餐更容易被打满。另一种独立场景（issue #6022）是 cc-switch 的自动故障转移开关 `auto_failover_enabled` 被手动热切换意外重置为 0，导致主用 provider 遭遇 429 时无法自动切换到备选节点。
在 cc-switch 中删除现有的 glm 供应商，点击右上角「+」新建官方预设（不要复制旧配置），确保 URL 是智谱 Coding Plan 链接。
确认当前登录的智谱账号与申请 API Key 的账号一致，如不一致请切换账号后重试。
如 Codex 仍报 429，检查其重试配置，将固定间隔重试改为指数退避（exponential backoff）并增加随机抖动（jitter）。
避开 14:00-18:00（UTC+8）高峰时段使用，或降低并发数，防止配额被 3 倍速扣减。
若配置了多 provider 自动故障转移但 429 时不切换，手动执行 SQL 检查并重置开关：UPDATE proxy_config SET auto_failover_enabled=1 WHERE app_type='claude'（注意：手动热切换 provider 会再次将其重置为 0）。
数据库路径（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”本页汇总自 3 个真实 issue
- 为什么一用 Codex 就报 429，新建供应商就好了？
- 旧版 cc-switch 的 glm 预设 URL 指向普通 API 而非 Coding Plan，删除后使用右上角「+」新建官方预设即可解决。
- 429 错误是配置错了吗？
- 不一定。根据 issue #4120 的解决记录，账号登错（API Key 与登录账号不匹配）会导致 429；同时 GLM Coding Plan 在 14:00-18:00 高峰时段按 3 倍速扣减配额，低档位套餐容易触发限流。
- 为什么智谱/minimax 会在 1 分钟内调用上百次，额度瞬间烧完？
- 这是客户端重试风暴（retry storm）导致的。当请求失败或收到 429 时，如果客户端以固定间隔（而非指数退避）高频重试，会在短时间内发送大量重复请求。临时缓解措施包括设置 provider 并发上限为 1-2，或在代理层限制单分钟最大请求数。
- 开启了自动故障转移，为什么 429 时不会自动切换到下一个 provider？
- 根据 issue #6022，cc-switch 存在 bug：手动热切换 provider（或某些情况下点击 UI 开关）会将数据库中的 `auto_failover_enabled` 重置为 0，导致自动故障转移失效。可通过 SQL 手动将其改回 1，但手动切换后会再次被重置。
这是一个非官方社区 wiki，与 cc-switch 作者及项目本身无隶属关系。内容整理自项目公开的 GitHub issues。本站不分发任何软件。