Repository navigation
feat(frontdoor): tell Claude Code which limit a provider's spent quota is - #627
Merged
Merged
Conversation
…a is An http provider that refuses a request with a 429 for a spent five-hour or weekly plan window names the window only in the error text, so Claude Code read it as a throttle and retried. The pass-through now holds back a 429's small body, and when the upstream sent none of the real API's unified rate-limit headers and the error is a quota the usage log classifies as exhausted, with a message naming the window, it adds the binding window, its status, utilisation and reset, retry-after and x-should-retry: false, leaving the body as it was. The reset is the response's own retry-after, which carries no zone; a response with none is read from the message's reset time on the backend's UTC+8 clock. The usage store records the translated headers, so the provider's window shows its real reset. The headers the Antigravity route adds for a spent window are built by the same function. Refs #448
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
This security review couldn’t start because the paying account has exhausted its Codex allowance and has insufficient available credits. The payer can check their balance and add credits in the Codex usage dashboard, then try again. If you do not manage the paying account, contact this repository's admins. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A z.ai five-hour limit reaches Claude Code as "Server is temporarily limiting requests (not your usage limit)", although it is the account's own limit: the 429 names the window only in its error text, so the client reads a throttle and retries (#448).
The pass-through now holds back a 429's small body and, when the upstream sent none of the real API's unified rate-limit headers and the error is a quota the usage log already classifies as exhausted, with a message naming a five-hour or weekly limit, adds the binding window, its status, utilisation and reset,
retry-afterandx-should-retry: false. The body is passed on untouched, and a refusal that names no window, gives no reset or is a short rate limit is left as it came. The reset is the response's ownretry-after; only a response with none is read from the message's reset time, which is wall time on the backend's UTC+8 clock. Because the usage store records the translated headers, the provider's five-hour window gets its real reset instead of a day-old one.The headers the Antigravity route adds for a spent window are now built by the same function.
Refs #448