Repository navigation
Bug or feature: in case of Gemini 429 error, wait and auto-retry last task #6923
Description
Before you start
- I searched existing issues and this is not a duplicate. 我已搜索过现有 issue。
What happened? 发生了什么？
Steps to reproduce 复现步骤
- Codewhale 0.10.1
- Mac OS X
- Google Gemini
If I reach a limit and Google reports 429 TMP/RPM error, just wait and automatically retry the last task until it is done (or wait and retry again)
Codewhale version 版本
0.10.1
Where did it happen? 在哪里出现？
TUI (terminal interface)
Operating system 操作系统
macOS
How did you get Codewhale? 获取方式
Homebrew
Provider and model 提供商和模型
google/gemini-3.5-flash-lite (free tier model)
Terminal and shell 终端
zsh
codewhale doctor (optional)
its ok
Logs, screenshots, anything else (optional)
No response
Activity
Hmbown commentedon Oct 9, 2026
ah I see - so is it just sending requests too quickly for that plan? is that what you think? will investigate!
fix(tui): honor a provider's retry delay when a 429 carries no Retry-…
Statter commentedon Oct 9, 2026
Yes, there is a TPM/RPM limit. Actually I don't know, whether Gemini reports the remaining limit or not during execution of the current turn (so to properly plan a next one)
But anyway (reports it or not) it seems wise, getting to know that model responded last time with 429, to have a delay in execution instead of just plain 429 unmanaged error with a current turn stopped midway to a goal completion
So preferable (as I see) to have an option (maybe it can be configurable in terms it is on/off, max_retries before finally falls to 429) not to restart a turn manually (actually teminal can in theory miss all previous turn setup, as in this situation you can only execute /retry and it will by default start an execution of the whole request from scratch [which can effectively loop the situation: as the last time a minute limit is exeeded, the current retry attempt also consume the same amount of requests/tokens and will lead to the same situation])
Instead of such a behavior, it seems to me a bit better to give a manageble opportunity just to restart a current turn with all its content and context with regards to retry-delay just like it starts in a normal way (and limit 429 has never been reached)
docs: 0.10.2 changelog for the readiness fixes; registry row names /d…
docs(release): correct four 0.10.2 notes found while triaging recent …
Hmbown commentedon Oct 13, 2026
@Statter, thank you for distinguishing a TPM/RPM wait from restarting the whole task. 9dd6b4b352, included in the 0.10.2 candidate, reads retry delays from response bodies when a 429 is classified as a rate limit. Your Gemini free-tier case is still not fully fixed: a response saying “exceeded your current quota” with billing guidance is currently classified as exhausted quota before that retry path. The candidate notes now state this limitation explicitly. This issue remains open; the current candidate should not be taken as confirmation that Gemini automatically resumes after that response.
fix(client): distinguish bounded rate limits from exhausted quota
docs(release): align Windows contracts and remaining candidate limits
Hmbown commentedon Oct 13, 2026
@Statter, thank you for including the quota-worded Gemini failure and its retry guidance; that detail showed why the earlier body-delay repair still missed your case. 2b3decc006 is now pushed in the 0.10.2 candidate: a 429 with an accepted body delay of at most 120 seconds can take the retry path, while explicit account/credit/subscription exhaustion and header-only hints remain terminal.
The actual local CLI passed seven synthetic loopback cases: the structured short delay retried the identical request after 258 ms and recovered; all six durable/unsupported cases made one request and failed without output. Existing focused Rust checks passed 170/170, and npm/web/Clippy pass. This is local macOS transport evidence, not a live Gemini or Windows receipt. Final-head CI is running; 0.10.2 has not shipped and this issue stays open for your actual route’s retest.
Hmbown commentedon Oct 20, 2026
🤖 This reply is from Claude Opus 5.5, an AI agent working on behalf of the Codewhale maintainers. It is posted through @Hmbown's account, but Hunter did not write it.
@Statter, thank you for spelling out what you wanted: when Gemini answers with a TPM/RPM 429, wait and continue the interrupted request instead of ending the turn and making you restart the whole task with
/retry. That is whatmainnow does, so I'm closing this as fixed on main; ships in 0.10.2 (not released yet). v0.10.1 does not have it.What carries it:
Retry-Afterheader. Gemini sends it in the body asretryDelay.[retry]settings (enabled,max_retries, see docs/CONFIGURATION.md), which covers the on/off and max-retries option you suggested.Limits, also listed in the 0.10.2 changelog: a 429 without a body delay of 120 s or less still ends the turn, and an explicit account, billing or subscription exhaustion stays terminal whatever the hint says. This was checked with focused tests and a local stand-in server on macOS, not against live Gemini. If 0.10.2 doesn't fix it for you on the free tier, please reopen with the 429 response body (without your key).
— Written by Claude Opus 5.5 (AI agent) on behalf of the maintainers.