Skip to content

Feature request: opt-in auto-redemption of expiring Codex banked resets #152

Open

Description

@davidjirovec

Summary

Could onWatch add an opt-in, disabled-by-default setting to automatically redeem expiring Codex banked resets?

The goal is to avoid losing a banked reset simply because the user did not notice its expiry or was away when it needed to be redeemed.

Proposed behavior

  • Add an Auto-redeem expiring banked resets setting for each Codex account/profile, separate from the existing quota-starter setting.
  • Monitor available banked resets and their expiry times, and redeem the earliest-expiring eligible reset one hour before expiry by default. A configurable lead time would be useful.
  • Show the available reset count, next expiry, and last automatic redemption in the dashboard, where that information is available.
  • Explain when enabling the setting that redemption consumes a banked reset and can reset the current usage window. Ordinary quota monitoring should remain read-only unless the user explicitly enables this feature.

Reliability and notifications

  • Recheck eligibility and current account state immediately before redemption.
  • Prevent duplicate consumption across polling cycles, concurrent workers, and restarts. Use API idempotency where supported, and reconcile an uncertain result before attempting another redemption so a timeout cannot consume additional resets.
  • Retry transient failures with bounded backoff while the reset is still eligible, respect rate limits, and surface authentication failures that require user action.
  • Offer notifications through the configured channels for successful redemption and actionable failures, with enough detail to identify the account and expiry without exposing credentials.
  • If an account or API does not expose reset expiry/redemption, show that the feature is unavailable rather than guessing or silently failing.

Related issue

I checked open and closed issues for Codex, reset, banked, and redeem. #76 (Auto quota starter?) is related, but starts ordinary quota windows; this request is specifically about redeeming an existing banked reset before it expires.

Activity

  1. added a commit that references this issue on Oct 22, 2026
  2. prakersh commented on Oct 22, 2026

    @prakersh
    Contributor

    Thanks for the thorough write-up. We looked closely at how banked resets work before deciding how far to take this.

    Phase 1 is in #153, now merged into main, and it is read-only:

    • Each Codex account with a banked reset shows a small "1 reset" chip on the dashboard and on its menubar card. The count is the same number the Codex CLI shows, and the tooltip shows when the next one expires.
    • onWatch sends one notification 24 hours before a reset expires, through your configured channels.
    • onWatch never redeems a reset. A test fails if any code path calls the redeem endpoint.

    We're holding off on auto-redeem for now. Redeeming is irreversible and goes through an undocumented endpoint, and we can't confirm what a redeem request does when there is nothing to reset without spending a real reset to find out. If we build it later, it will follow what you described: off by default and per account, with idempotency keys, one attempt in flight at a time, bounded retries, and reconciliation after a timeout.

    Feedback on the chip and the alert timing is welcome now that it ships in v2.14.14.

  3. davidjirovec commented on Oct 22, 2026

    @davidjirovec
    Author

    Thanks—upgraded to v2.14.14. Banked-reset data is loading, and the ntfy expiry notification arrived successfully. My existing webhook configuration needed the new reset_credit_expiry event enabled after upgrading; mentioning that in the upgrade notes would help.

  4. prakersh commented on Oct 23, 2026

    @prakersh
    Contributor

    Good catch, thanks for confirming the chip and alert work.

    You are right. reset_credit_expiry is new, and existing webhook configs have no value stored for it, so it shows as off. Tick it once in Settings.

    Docs fixed in #159.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions