Skip to content

Support Codex quota reset hints - #107

Merged
sususu98 merged 3 commits into
devfrom
auth
Aug 31, 2026
Merged

Support Codex quota reset hints#107
sususu98 merged 3 commits into
devfrom
auth

Conversation

@hkfires

@hkfires hkfires commented Aug 30, 2026

Copy link
Copy Markdown
Contributor

Introduce support for Codex quota reset hints, enhancing the handling of execution cooldowns and retry logic based on provider-specific reset information. This update improves the system's responsiveness to quota limits and ensures accurate backoff behavior during quota exceedances.

@hkfires
hkfires requested a review from sususu98 August 30, 2026 12:59

@sususu98 sususu98 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for implementing support for Codex quota reset hints! The overall design, defensive parsing, and test matrix look very solid.

I'd like to suggest one refinement based on real-world production usage:

Suggestion: Clamp Codex Max Quota Horizon to 30m (Supporting Early Resets & User Upgrades)

In practice, an OpenAI Codex credential often becomes available much earlier than the pessimistic resets_at / resets_in_seconds timestamp returned in 429 errors:

  1. Dynamic Capacity & Early Resets: OpenAI frequently uses sliding windows and dynamic capacity refills. The resets_at field often reflects a pessimistic upper bound (e.g. 5 hours, 3 days), but usable capacity is frequently restored much sooner.
  2. User-Initiated Actions (Crucial): When a limit is hit, users frequently go to their OpenAI/ChatGPT dashboard to purchase extra credits, update payment methods, or upgrade subscriptions (e.g. Plus $\to$ Pro/Team). Once completed, the upstream credential is functional immediately.

The Problem:
If Home strictly locks the credential for the full 72 hours, newly topped-up or early-reset credentials will sit idle for days without manual admin intervention in Home UI.


💡 Proposed Solution: Clamp Horizon to now + 30m

  1. Introduce a provider-scoped Max Quota Horizon defaulting to 30 * time.Minute for codex (aligning with the existing quotaBackoffMax ceiling).
  2. When resets_at or resets_in_seconds exceeds the horizon, clamp the deadline to now + 30m instead of locking for multi-day periods:
    • Short hints (e.g. 5m, 10m): Respect the exact hint.
    • Long hints (e.g. 72h): Sleep for at most 30 minutes, allowing Home to automatically discover and recover when upstream resets early or when the user upgrades/adds credits. If upstream is still exhausted after 30m, the next 429 will simply clamp into another 30m cycle.

This achieves the optimal balance: precise backoff for short windows, and automatic recovery for early resets and user top-ups.

- Clamp OpenAI Codex quota reset hints exceeding 30 minutes to now + 30m (matching quotaBackoffMax) while respecting exact hints <= 30m
- Retain the 60-day maximum horizon for Antigravity and other providers
- Ensure provider horizon is derived from the authoritative auth provider in MarkResult and StateMutator
- Keep exponential backoff ladder as the minimum cooldown floor and never shorten open windows
- Update English and Chinese Management API documentation
- Add comprehensive unit and cluster test coverage for clamping, precedence, and provider mismatches
@sususu98
sususu98 merged commit 3c1d4d3 into dev Aug 31, 2026
2 checks passed
@sususu98
sususu98 deleted the auth branch August 31, 2026 02:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants