Feature request: apply "Show usage as used" to the Overview / desktop view, not just the menu

[OlegLustenko]

Summary

The Show usage as used toggle (Settings → MENU CONTENT — "Progress bars fill as you consume quota (instead of showing remaining)") only governs the menu-bar popover. The expanded Overview / desktop view shows usage as used regardless of this setting, so with the toggle set to remaining the two surfaces disagree on the same snapshot.

Observation

Same refresh ("6 min ago"), toggle set to remaining:

• Menu-bar popover (honors the setting → remaining): Session 48%, Weekly 53%, Sonnet 91%
• Overview / desktop view (always used): Session 52% used, Weekly 47% used, Sonnet 9% used

Each pair sums to 100 — same underlying data, opposite convention, because only the menu reflects "Show usage as used." Side by side it reads as a contradiction.

Request

Have the Overview / desktop view respect the same Show usage as used preference (or expose an equivalent toggle for it), so used-vs-remaining is consistent across the menu and the desktop view.

Secondary (minor)

In the Overview, the X% used / Y% in reserve / Z% in deficit lines plus the dual timestamps (Resets in… / Lasts until reset / Runs out in…) are dense, and "in reserve" / "in deficit" aren't self-explanatory — a short legend or tooltip would help. Secondary to the consistency ask above.

---

CodexBar 0.37.x.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 24, 2026, 9:22 AM ET / 13:22 UTC.

Summary
Keep open. This is a same-day UX consistency report, and the repository profile says not to auto-close personal-repo items; source and release inspection also suggest the current shared model already routes the setting into Overview and desktop provider-detail metrics, so the next step is maintainer/runtime confirmation of the exact surface.

Reproducibility: no. I did not establish a high-confidence live failing path; current source routes both Overview rows and Preferences provider detail metrics through the same settings-backed model.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
Manual confirmation is needed because current source and the v0.37.2 tag already show the setting flowing into Overview rows and provider details, while the reporter observed the opposite in 0.37.x.

Review details

Best possible solution:

Verify the reporter’s exact Overview/desktop surface against a fresh v0.37.2-or-newer bundle; if it matches the shared model, close as implemented, otherwise fix only the uncovered surface and add a focused regression test.

Do we have a high-confidence way to reproduce the issue?

No. I did not establish a high-confidence live failing path; current source routes both Overview rows and Preferences provider detail metrics through the same settings-backed model.

Is this the best way to solve the issue?

Unclear. If the reported surface is the existing Overview/provider detail path, the current shared model is already the narrow maintainable solution; if another desktop surface is involved, that specific surface should be fixed with a focused regression test.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• No live macOS UI validation was run in this read-only sweep, so the reporter may be seeing an uninspected desktop/Overview surface or a stale bundle despite the source path appearing consistent.
• The issue was reported against 0.37.x after v0.37.2, while v0.37.2 source already contains the expected preference plumbing; maintainer confirmation is needed before closing.

Codex review notes: model internal, reasoning high; reviewed against ada3660e9d61.

Label changes

Label changes:

• add P3: This is a low-risk UI consistency/ergonomics issue with limited blast radius.
• add impact:other: The issue is about contradictory quota presentation across user-visible CodexBar surfaces, which is maintainer-visible but outside the specific owned impact classes.
• add issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.

Label justifications:

• P3: This is a low-risk UI consistency/ergonomics issue with limited blast radius.
• impact:other: The issue is about contradictory quota presentation across user-visible CodexBar surfaces, which is maintainer-visible but outside the specific owned impact classes.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was read fully before review; its guidance favored read-only/state-model inspection and avoiding live validation that could prompt for credentials. (AGENTS.md:1, ada3660e9d61)
• Setting definition: The Display settings toggle binds directly to settings.usageBarsShowUsed. (Sources/CodexBar/PreferencesDisplayPane.swift:78, ada3660e9d61)
• Overview uses shared menu-card models: Overview rows are built from menuCardModel(for:) and rendered with OverviewMenuCardRowView, so they should inherit the same settings-backed metric model as provider cards. (Sources/CodexBar/StatusItemController+Menu.swift:542, ada3660e9d61)
• Menu-card model receives the preference: StatusItemController passes self.settings.usageBarsShowUsed into UsageMenuCardView.Model.Input for menu card models. (Sources/CodexBar/StatusItemController+MenuCardModel.swift:108, ada3660e9d61)
• Desktop provider detail receives the preference: Preferences provider detail model construction also passes self.settings.usageBarsShowUsed into the shared UsageMenuCardView model input. (Sources/CodexBar/PreferencesProvidersPane.swift:745, ada3660e9d61)
• Metric percent calculation honors the preference: Metric construction chooses .used vs .left styling from input.usageBarsShowUsed and chooses primary/weekly usedPercent or remainingPercent from that same flag. (Sources/CodexBar/MenuCardView.swift:1179, ada3660e9d61)

Likely related people:

• Peter Steinberger: The relevant overview row construction, shared model plumbing, and v0.37.2 baseline source are attributed to the f380287 release baseline in available blame/history. (role: feature-history owner; confidence: high; commits: f380287041b8; files: Sources/CodexBar/StatusItemController+Menu.swift, Sources/CodexBar/StatusItemController+MenuCardModel.swift, Sources/CodexBar/MenuCardView.swift)
• Zihao Qi: The current main head commit recently touched StatusItemController menu presentation and refresh styling, adjacent to the Overview/menu surface under review. (role: recent adjacent contributor; confidence: medium; commits: ada3660e9d61; files: Sources/CodexBar/StatusItemController+Menu.swift, Sources/CodexBar/StatusItemController+MenuPresentation.swift, Sources/CodexBar/StatusItemController+PersistentRefreshMenuItem.swift)
• BAKEZQ: Recent provider settings/detail work touched PreferencesProvidersPane, which constructs the desktop provider detail model using the same usageBarsShowUsed preference. (role: recent adjacent contributor; confidence: low; commits: 2435c93453fe; files: Sources/CodexBar/PreferencesProvidersPane.swift, Sources/CodexBar/PreferencesProviderSettingsRows.swift)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[FrancoLan]

Related surface: the macOS WidgetKit desktop widgets (Usage / History) have the same disconnect, in the opposite direction - they always show percent remaining regardless of "Show usage as used". The widget snapshot only carries remainingPercent/percentLeft and CodexBarWidgetViews renders it directly, with no reference to usageBarsShowUsed; the Burn Down config intent doesn't expose a used/remaining choice either. Would be great to have this preference plumbed through to the widgets too (or a per-widget toggle), so menu / overview / widgets all agree. CodexBar 0.37.2, macOS