Show menu pace token during early weekly window - #2853
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. |
clawsweeper
Bot
added
merge-risk: 🚨 compatibility
|
Codex review: needs maintainer review before merge. Reviewed August 11, 2026, 2:27 AM ET / 06:27 UTC. ClawSweeper reviewWhat this changesThe branch allows the weekly menu-bar pace token to render after 1% of its resolved quota window has elapsed while leaving session, automatic, and Runs out tokens at the existing 3% threshold. Merge readinessThe patch is technically coherent and well-proven, but it intentionally changes the documented 3% pace-display policy for existing weekly layouts; a repository maintainer should explicitly confirm that weekly-only compatibility change before merge. Priority: P2 Review scores
Verification
How this fits togetherCodexBar turns provider quota snapshots into menu-bar layout tokens. Pace calculation determines the signed weekly estimate, while the status-item scheduler wakes the menu bar when time alone makes that estimate eligible to render. flowchart LR
A[Provider quota snapshot] --> B[Resolved pace window]
B --> C[Pace estimate]
C --> D[Eligibility threshold]
D --> E[Weekly menu-bar token]
D --> F[Refresh scheduler]
F --> E
Decision needed
Why: Current documentation establishes a uniform 3% threshold, and the provided policy statement is from a CONTRIBUTOR account rather than a verified repository maintainer decision. Before merge
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Confirm the weekly-only 1% exception as the intended product policy, then merge this bounded implementation while retaining the 3% default for session, automatic, and Runs out tokens. Do we have a high-confidence way to reproduce the issue? Not applicable: this is a proposed display-policy enhancement rather than a report of broken existing behavior; the supplied fresh-bundle screenshot directly exercises the intended rendering path. Is this the best way to solve the issue? Unclear pending product confirmation: the implementation is narrowly scoped and preserves the other token thresholds, but maintainers must choose whether the documented 3% contract should have this weekly exception. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 8d113c642516. LabelsLabel justifications:
EvidenceWhat I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (7 earlier review cycles)
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6914e0b215
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| guard let resolved else { return nil } | ||
| guard resolved.expectedUsedPercent >= Self.minimumPaceExpectedPercent else { return nil } | ||
| guard resolved.expectedUsedPercent >= minimumExpectedPercent else { return nil } |
There was a problem hiding this comment.
For Codex users with historical tracking enabled and a mature dataset whose prior weeks have little usage in the first few hours, CodexHistoricalPaceEvaluator can return a learned expectedUsedPercent below 1% even after more than 1% of the weekly window has elapsed. This guard then still suppresses the menu token—for example, roughly 20 histories that remain flat for four hours produce an expectation around 0.78% at four hours—so the change does not reliably fix the early-window behavior for the provider-specific path. Gate menu-token eligibility on elapsed window progress (or otherwise preserve a linear floor), and cover the Codex historical branch rather than only .zai.
AGENTS.md reference: AGENTS.md:L5-L5
Useful? React with 👍 / 👎.
6914e0b to
6963256
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b35d9a5357
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| provider: provider, | ||
| window: $0, | ||
| now: now, | ||
| minimumExpectedPercent: windows.weekly != nil ? 1 : 3) |
There was a problem hiding this comment.
When a layout contains .runsOut and the weekly window has only reached 1–3% expected usage, this also lowers the forecast's guard and starts showing an exhaustion estimate based on just the first few hours. runsOut is a separate token from the signed weekly pace token, so it should retain the existing 3% floor; the mirrored calculation in MenuBarLayoutEditor.liveData should do the same.
Useful? React with 👍 / 👎.
clawsweeper
Bot
added
proof: 📸 screenshot
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0cd048f1e0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| let elapsedFloorMet = minimumElapsedPercent.map { minimum in | ||
| (Self.windowElapsedPercent(window: window, now: now) ?? 0) >= minimum | ||
| } ?? false |
There was a problem hiding this comment.
For providers whose semantic weekly lane is a calendar-month quota represented by a 30-day sentinel (for example, Notion's monthly lane), pace is correctly calculated from paceWindow, but this new eligibility check measures the original sentinel window. At the start of a 28-day February cycle it therefore reports two days (6.7%) already elapsed and exposes the pace token immediately instead of after 1%; a 31-day cycle delays it by roughly a day. Measure elapsed progress against the same resolved calendar window used to calculate resolved.
Useful? React with 👍 / 👎.
| weeklyPace: self.store.menuBarLayoutPaceText( | ||
| provider: provider, | ||
| window: windows.weekly, | ||
| now: now, | ||
| minimumElapsedPercent: 1), |
There was a problem hiding this comment.
When a snapshot is rendered before the new 1% boundary, this call returns nil and the status item shows a dash, but crossing the boundary changes only Date() and does not trigger Observation. In particular, with manual refresh and a custom layout containing only the weekly pace token, UsageStore.startTimer has no polling timer and scheduleMenuBarCountdownRefreshIfNeeded schedules custom-layout wakes only for reset tokens, so the new pace can remain hidden indefinitely until an unrelated update or manual refresh. Schedule an icon refresh for the eligibility boundary when this token is present.
Useful? React with 👍 / 👎.
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
clawsweeper
Bot
added
rating: 🐚 platinum hermit
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
clawsweeper
Bot
added
rating: 🦞 diamond lobster
|
Maintainer decision: accept the weekly-only 1% elapsed eligibility for existing and custom weekly pace layouts. Keep the established 3% floor for session, automatic, and Runs out tokens. |
|
@clawsweeper re-review |
1 participant
Summary
Adds the pace reserve percentage as a menu bar display token. During the early part of the weekly quota window, the pace estimate used to be hidden (no expected usage baseline yet), so the new token showed nothing even though a meaningful pace can be derived from elapsed window time.
The weekly menu-bar token now becomes eligible after one percent of the weekly window has elapsed, even when learned Codex history still predicts less than one percent expected usage. The returned pace value remains the existing learned or linear estimate; only token eligibility uses elapsed progress as an explicit fallback.
Scope
The one-percent elapsed floor applies only to the weekly token.
sessionPaceandautomaticPacekeep the existing three-percent floor (automatic can resolve to a session/primary window), andrunsOutkeeps the three-percent floor.Changes
UsageStore+HistoricalPace:weeklyPace/menuBarLayoutPaceTextgain the existing three-percent expected-use floor plus an optional elapsed-progress fallback.menu bar layout pace opens weekly early but floors session and automatic at three percent), learned Codex history below one percent, early-window seam coverage, and an env-gated render-proof test (test_renderEarlyWeeklyPaceTokenProof) that renders the real menu-bar path to a PNG.docs/ui.md: documents the weekly-only exception and preserves the three-percent behavior for session, automatic, and Runs out.Evidence
Real menu-bar rendering path from the freshly built bundle, synthetic early-week snapshot (weekly 4h into the window at 2.38% expected; session 2min into 120min at 1.67% expected):
Weekly shows
W 5% · +3%; session and automatic hide the pace token (3% floor). Runs out also remains hidden in this early band.Commands
Focused HistoricalUsagePace and MenuBarCountdownRefresh tests: 68/68 passed. ProviderArchitectureGatekeeperTests: 38/38 passed. The learned-Codex, calendar-month, and custom-layout wake regressions pass.
make check, lint, format, and diff checks are clean.Closes #2842