Gemini CLI 429 RESOURCE_EXHAUSTED 怎么解决？

1. 先读完整错误：429 不等于余额用完

先记录错误类型、模型代号、客户端版本、认证方式和发生时间。只保留“429”两个数字，会丢掉最有用的分流信息。

2. Gemini CLI 一直 Thinking，可能不是还在推理

Gemini CLI 的公开 issue 记录过一种情况：后台压缩、工具任务或子任务使用的模型返回 retryable 429 后，fallback 链没有找到实际失败的模型，重试计数从 10 又回到 1。用户看到的只是一直旋转的 Thinking...。

Attempt 1 failed: 429 RESOURCE_EXHAUSTED
...
Attempt 10 failed: 429 RESOURCE_EXHAUSTED
Attempt 1 failed: 429 RESOURCE_EXHAUSTED
...

如果同一模型、同一错误和同一组计数持续重复，继续挂机不是有效重试。先中止当前会话，执行 /about 记录版本，再升级到当前稳定版本。若更新后仍可复现，固定一个可用模型发送短请求，排除 Auto/fallback 链。

3. Gemini CLI 429 六步排查

1. 查看错误正文：区分普通 RESOURCE_EXHAUSTED 与模型容量提示。
2. 检查控制台：核对余额、密钥额度、并发和请求记录。
3. 固定模型：暂时不要使用 Auto，选择一个当前可用的文字模型做短请求。
4. 降低负载：停止并行会话、子任务和批处理，只保留一个请求。
5. 检查版本：通过 /about 记录 CLI 版本，更新后重复同一最小请求。
6. 更换路径：同模型持续容量不足时切换同类模型；全部失败再检查密钥和中转账户。

模型代号和密钥分组以模型广场及创建密钥页面为准，不要从旧教程复制已下线的预览模型。

4. 正确重试：指数退避、抖动和明确上限

Google 官方故障排查建议只对 429、408 和 5xx 等暂时性错误重试，并为重试设置上限。400、403 通常属于参数或权限错误，重复请求只会制造更多失败。

MAX_RETRIES = 4
BASE_DELAY_SECONDS = 1

for attempt in range(MAX_RETRIES):
    response = request()
    if response.ok:
        return response
    if response.status not in [408, 429, 500, 502, 503, 504]:
        raise response.error
    sleep((2 ** attempt) * BASE_DELAY_SECONDS + RANDOM_JITTER)

raise "retry limit reached"

中转应用还应保存请求 ID并避免自动重复执行写入、发送或扣费任务。有限重试失败后，明确返回“等待、切换模型或停止”，比无限转圈更可靠。

5. 使用 Gemini API 中转站时如何定位限流层

island AI Coding 的 Gemini CLI 配置入口见Gemini CLI API 教程。排查期间不要公开 API Key、Cookie 或包含业务内容的完整请求体。

6. 修复后用同一请求验证

1. 保存修复前的错误正文和 CLI 版本。
2. 用固定模型发送一句短提示，记录首字时间和状态码。
3. 逐步恢复上下文、工具和并发，不要一次全部开启。
4. 连续测试数次，确认没有重复 Attempt 计数或静默转圈。
5. 记录实际解决动作，便于版本升级后回归检查。

7. 常见问题