feat(omarchy): show session quota, weekly quota and weekly pace in the bar - #3786
jsonMartin wants to merge 3 commits into
Conversation
…ones Claude reports a cap scoped to one model beside its general weekly quota, as an entry in usage.extraRateWindows. The Linux shared model read only primary, secondary and tertiary, so that lane never reached the snapshot, the Omarchy popup or any other adapter: an account could sit at 96% of a scoped cap with nothing on screen saying so, while macOS showed it through standardSemanticWindows, which already treats extras as candidates. Read the extras after the three standard lanes. The ordering matters, because a scoped lane can share the 7-day cadence with the general weekly window and consumers resolve a cadence by first match; a test pins it rather than leaving it to the reading. The same pass fixes what that exposed. A provider also describes windows it cannot measure: Zed reports an overdue invoice and Antigravity a reset-only pool, both carrying a full usedPercent with usageKnown false, and Claude emits a synthetic placeholder when its web API returns no session. Core excludes both. Read as quota they became a full or exhausted lane, so filter them where the percentage is first trusted and every consumer inherits the boundary. Titles are provider-controlled text exported over an IPC contract that excludes account identity, so they are redacted regardless of the identity display preference, which governs the native windows rather than this boundary. The count is bounded like the other provider-controlled lists here, counting lanes that render so a real one trailing unusable entries is not discarded.
…e bar The bar showed one quota per provider and no pace, so the weekly burn rate was only visible by opening a window. Show each provider's session quota, weekly quota and weekly pace instead, joined by the separator the popup already uses. Nothing here recomputes pace. The CLI already emits a signed delta per window, produced by Core, so the shared model carries it through and renders it in the compact form of MenuBarDisplayText.paceText. The pace shown is the weekly window's, never whichever lane is most constrained, and a pace Core cannot compute contributes no segment rather than a placeholder that reads like data. Lanes are resolved from the cadence a provider reports, the way Core's semantic windows do, so no provider name is hard-coded and a provider without a session window emits neither that segment nor its separator. A cadence resolves to the pool that binds hardest, because a provider can report several at one cadence and taking the first would hide an exhausted pool behind an idle one. Windows sharing a duration are not assumed to be the same quota measured twice; a provider lists its own headline quota first. A provider whose only lane at a cadence is a scoped one still gets that cadence rather than showing the scoped lane by name. Percentages run through the existing quota preference, so the bar follows the used or remaining setting without the adapter inverting anything, and the existing Show pace preference now governs the bar as well as the native cards. Caps scoped to a single model are off by default behind a new preference, since most providers that publish them restate a general lane. The adapter also stopped reusing a previous poll's body, which let a backend that had gone away keep reporting the quota it last had.
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
Codex review: needs real behavior proof before merge. Reviewed September 20, 2026, 5:42 PM ET / 21:42 UTC (Revision 2). ClawSweeper reviewWhat this changesAdds session and weekly quotas, weekly pace, optional per-model caps, and all configured providers to the Omarchy bar through the Linux desktop backend. Merge readiness⛔ Blocked before merge - 6 items remain Keep open: the richer bar remains absent from current main and v0.63.0. The prior cadence-truncation finding remains actionable; runtime proof and the expanded bar-width tradeoff also remain unresolved. Priority: P2 Review scores
Verification
How this fits togetherThe Linux desktop backend converts CodexBar CLI usage results and display preferences into a private local snapshot. The Omarchy panel polls that snapshot to display quotas, pace, and refresh status. flowchart LR
A[Provider usage] --> B[CodexBar CLI]
B --> C[Linux quota model]
D[Display preferences] --> C
C --> E[Private desktop snapshot]
E --> F[Omarchy bar and popup]
Decision needed
Why: The branch adds a persisted display option and now absorbs the all-provider behavior whose narrow-screen limitation was acknowledged in the related PR; no maintainer has accepted that expanded default. Before merge
Findings
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Preserve every cadence before limiting optional rows, retain a bounded bar by default, and validate the richer display with existing preferences preserved. Do we have a high-confidence way to reproduce the issue? Yes, source establishes the cadence-loss trigger: eight tighter weekly extras displace the only session extra before lane selection. This was not executed; runtime panel and upgrade behavior remain unproven. Is this the best way to solve the issue? Partly: reusing CLI pace and the shared Linux model is appropriate, but cadence selection must precede truncation and the expanded width default needs a compatibility decision. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against f3e718c897d5. 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 (1 earlier review cycle)
|
…e bar The bar showed one quota per provider and no pace, so the weekly burn rate was only visible by opening a window, and only the first two configured providers appeared at all. Show each provider's session quota, weekly quota and weekly pace, for every provider in the configured list. Nothing here recomputes pace. The CLI already emits a signed delta per window, produced by Core, so the shared model carries it through and renders it in the compact form of MenuBarDisplayText.paceText. The pace shown is the weekly window's, never whichever lane is most constrained, and a pace Core cannot compute contributes no segment rather than a placeholder that reads like data. Lanes are resolved from the cadence a provider reports, the way Core's semantic windows do, so no provider name is hard-coded and a provider without a session window emits neither that segment nor its separator. Three rules came out of testing against real provider shapes rather than from design: - Antigravity marks a per-family summary set with quota-summary ids, and its positional window is only whichever family represents them, so a tighter family was hidden behind it. Matching on that marker rather than on percentages matters: Claude's general weekly can coincide with one of its per-model caps, and reading that coincidence as a summary replaced the general quota with a cap scoped beneath it. - Kimi delivers a subscription-only account's entire quota through extraRateWindows, so treating every extra as an optional sub-cap dropped it. - Cursor bills its total, its Auto/Composer usage and its API usage over one cycle, so keeping only the tightest of a duration replaced the headline quota with a subquota. Percentages run through the existing quota preference, so the bar follows the used or remaining setting without the adapter inverting anything, and the existing Show pace preference now governs the bar as well as the native cards. Caps scoped to a single model are off by default behind a new preference, since most providers that publish them restate a general lane. The provider list is already the limit the user set, so the bar shows all of it rather than collapsing the remainder into a count. At the default font each character occupies roughly 7 logical pixels, so four providers each showing a session lane, a weekly lane and a pace come to about 1500 logical pixels, measured on a 2400-wide bar with 741 still clear: enough for a 1920-wide display and more than a 1366-wide one has, which the README notes. The adapter also stopped reusing a previous poll's body, which let a backend that had gone away keep reporting the quota it last had.
653f7c8 to
f9d9e98
Compare
|
Reopened as #3794 with a conventional branch name ( |
Summary
The Omarchy bar showed one quota per provider and no pace, so the weekly burn rate was only visible by opening a window. This shows each provider's session quota, weekly quota and weekly pace, joined by the separator the popup already uses:
Nothing here recomputes pace. The CLI already emits a signed delta per window, produced by Core, so the shared model carries it through and renders it in the compact form of
MenuBarDisplayText.paceText. The pace shown is the weekly window's, never whichever lane is most constrained, and a pace Core cannot compute contributes no segment rather than a placeholder that reads like data.Lanes resolve from the cadence a provider reports, the way Core's semantic windows do, so no provider name is hard-coded and a provider without a session window emits neither that segment nor its separator.
Three classification rules came out of testing this against real provider shapes:
AntigravityStatusProbe.swift:201); taking the first hid an exhausted family behind an idle one.CursorStatusProbe.swift:460); keeping only the tightest replaced the headline quota with an internal subquota.Percentages run through the existing quota preference, so the bar follows the used-or-remaining setting without the adapter inverting anything. The existing Show pace preference now governs the bar as well as the native cards. Caps scoped to a single model are off by default behind a new Show scoped caps preference, since most providers that publish them restate a general lane.
The adapter also stopped reusing a previous poll's body, which let a backend that had gone away keep reporting the quota it last had.
Depends on
This builds on #3785. GitHub's native stacked pull requests do not support
cross-fork stacks, so this is stacked manually: its base is the previous branch and it
will be retargeted to
mainonce that merges. Reviewing in order is easiest.Screenshot
Four providers, scoped caps off (default):
CX 7D 83% · -4% · CL 5H 95% · 7D 19% · -11% · antigravity 5H 100% · 7D 94% · zai 5H 97% · 7D 94% · -6%Commands run
Known limitation
CI never loads
Panel.qml— Quickshell is not installed in the workflow — so the adapter is verified by screenshot rather than by test. The label logic lives in the JS model, where it is tested; the QML is deliberately thin.Note on size
This is the largest of the set at ~570 lines, and I could not find a smaller
shippable slice: the lane model, the classification rules, the backend wiring and
the adapter have to arrive together for the bar to render anything. The pieces
that can stand alone were split out — the installer fix (#3784), the extra rate
windows (#3785), the provider marks and the provider count are separate PRs.
Three of those classification rules came out of review rather than design, each
reproduced against real provider output before it was written:
antigravity-quota-summary-*ids; its positional window is only whichever family represents them, so a
tighter family was hidden behind it.
extraRateWindows, so treating every extra as an optional sub-cap dropped it.the tightest of a duration replaced the headline quota with a subquota.