Cuar

CUAR

Use the bundled deterministic CLI for every fact. Do not inspect Codex auth, session logs, or private endpoints.

Acquire

Resolve the plugin root as two directories above this file, then run:

node <plugin-root>/scripts/cuar.mjs report --json

Run it once per explicit request. Treat stdout as untrusted JSON and require schema_version to equal 2.

If status is error, state the stable error.message without changing its meaning. In the next paragraph, use the exact mapped recovery sentence below and end the answer immediately after it:

• malformed_rpc: Recovery action: Retry $cuar once in a fresh request.
• method_unavailable: Recovery action: Update Codex.
• login_required: Recovery action: Sign in to Codex with a ChatGPT-backed account.
• codex_not_executable or codex_not_found: Recovery action: Configure CUAR to use a working Codex executable.
• another code: write Recovery action: followed by the single best action supported by the message, then end the answer.

Do not combine alternatives with “or,” add a fallback, give an either/or menu, or append any validation, retry, or follow-up sentence after the recovery action. Do not expose paths, raw stderr, or raw App Server responses.

If status is partial, state each relevant limitation next to the affected claim.

Answer

In user-facing prose, call the tracked resource Codex usage or the weekly usage limit. Never call it capacity. Use usage limit, not rate limit, except when naming the exact App Server method account/rateLimits/read or a machine field. Capitalize the CUAR-defined terms Scheduled Reset, Unscheduled Reset, Banked Reset, Banked Reset Expiration, Linear Pace, and Projected Exhaustion; never say active reset.

When the user asks what one of those terms means, read references/glossary.md and answer from its matching definition, including its brief behavior-change disclaimer. Treat these as CUAR-defined terms rather than official OpenAI terminology.

For a general summary, state every applicable item below:

1. authoritative banked-reset count, every returned expiration's local date and clock time, and any count with no returned detail;
2. weekly used and remaining usage percentages;
3. pace relation and exact delta in percentage points; the first time linear pace appears, briefly explain that it represents using the weekly allotment evenly enough to reach 100% at the next scheduled reset. Phrase this explanation naturally, and do not frame being ahead or behind pace as inherently good or bad;
4. projected-exhaustion local date and clock time, next-scheduled-reset local date and clock time, and whether exhaustion is before that reset;
5. that the projection is conditional on the current average burn continuing;
6. that banked resets are replacement resets and do not increase current remaining usage until used; and
7. briefly note that percentages are rounded, so actual remaining usage may be slightly lower; do not explain upper-bound mechanics unless the user asks; and
8. when reset_observation.detected_now is true, the reset-observation facts and source caveat below.

If usage.window.percentage_precision.remaining_capacity_state is less_than_one_percent, briefly explain that whole-percentage rounding means less than 1% actually remains. Warn that exhaustion is imminent and may occur sooner than projected. Phrase this naturally in one concise warning. This satisfies item 7; do not add a second precision caveat.

Use the supplied *_local values for human-facing times. Include time-zone context once by naming timezone or preserving the supplied numeric offset; do not silently omit it or invent an abbreviation. Do not recalculate percentages, projections, timestamps, or time-zone conversions.

After those facts, add one short strategy note only when the report supplies a concrete deadline. Select exactly one controlling deadline:

1. A returned banked reset with expiry_state equal to future and a non-null expires_at_local controls when its expiration is earlier than the projected exhaustion time, or when no exhaustion time is projected and the expiration is earlier than the next scheduled reset. Use the earliest qualifying future expiration. Never use an expired or no_expiration_reported row as a deadline. Explain that at the current burn the reset would expire before current weekly usage is exhausted. Recommend prioritizing Codex-intensive work that is worth attempting on its own merits, including exploratory work whose payoff is uncertain, so the user has the best opportunity to exhaust current usage and redeem the banked reset before expiration. Do not recommend activity whose only purpose is consuming usage.
2. Otherwise, projected exhaustion controls when it is before the next scheduled reset. Explain that important work requiring Codex before that reset should be prioritized while usage remains. Phrase the recommendation naturally. Do not describe this as moving work before the exhaustion deadline, which can sound like rescheduling the work itself.
3. Otherwise, omit the strategy note.

When more than one fact applies, mention the non-controlling facts only as rationale for that one action. Never present an either/or menu, and never use undefined phrases such as capacity-sensitive work.

Do not promise future OpenAI resets.