Show menu pace token during early weekly window - #2853
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. |
|
Codex review: needs maintainer review before merge. Reviewed August 14, 2026, 3:50 AM ET / 07:50 UTC. ClawSweeper reviewWhat this changesThis PR makes the weekly menu-bar pace token appear after 1% of its resolved quota window has elapsed while retaining the 3% threshold for session, automatic, and Runs out tokens. Merge readinessThe patch is technically sound and proof-positive, but it intentionally changes existing weekly custom layouts from a dash to a signed pace estimate during the 1–3% elapsed-window band. Keep it open for an authorized maintainer to accept that display-policy change. Priority: P2 Review scores
Verification
How this fits togetherCodexBar turns provider quota snapshots into menu-bar layout tokens. The weekly pace token derives a signed estimate from the resolved quota window, while the status-item scheduler wakes the renderer when time-based eligibility changes. flowchart LR
A[Provider quota snapshot] --> B[Resolved quota window]
B --> C[Pace estimate]
B --> D[Elapsed eligibility]
C --> E[Weekly pace token]
D --> E
E --> F[Status-item redraw]
F --> G[Menu bar layout]
Decision needed
Why: This is a deliberate compatibility-visible default change. The supplied acceptance wording is from a CONTRIBUTOR, and the reviewed repository history and notes do not establish an authorized maintainer decision. Before merge
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Record authorized acceptance of the weekly-only 1% display policy, then merge the focused implementation once required checks complete. Do we have a high-confidence way to reproduce the issue? Not applicable as a bug reproduction: this PR adds a deliberate display-policy exception, and its focused fixtures cover the intended early-window behavior. Is this the best way to solve the issue? Yes technically, conditional on policy approval: the implementation confines the fallback to Weekly pace, preserves other floors, resolves calendar windows correctly, and schedules the eligibility redraw. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against a449749fddac. LabelsLabel justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (9 earlier review cycles; latest 8 shown)
|
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.
Gate early Codex pace on elapsed progress
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.
Keep the early floor scoped to the weekly pace token
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 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.
Use the resolved window for the elapsed floor
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.
Schedule a redraw when weekly pace crosses 1%
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 re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
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 |
# Conflicts: # Tests/CodexBarTests/ProviderArchitectureGatekeeperTests.swift
Summary
Note