Optionally Hide Codex Spark Usage

[intellectronica]

The Codex 5.3 Spark metrics take a lot of screen real estate. I never use this model, so I'd love to be able to hide these metrics so I can fit more on my screen. This is especially important on the preview screen, since there's a lot more to scroll through.

Implementation suggestion: on the codex provider configuration page, add a checkbox - “Show Codex Spark Usage”: default checked, if unchecked, don't display the codex spark metrics, only the main session/weekly limits.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 9, 2026, 5:11 PM ET / 21:11 UTC.

Summary
Keep open under this repository's conservative cleanup profile: current main and the shipped app already have a default-on Display setting that hides Codex Spark extra metrics while preserving the main Codex session and weekly lanes, but maintainer confirmation is needed before treating the provider-specific checkbox request as fully closed.

Reproducibility: not applicable. this is a feature/discoverability request, not a bug in an established contract. Source and tests do confirm the current behavior that disabling optional extra usage hides Codex Spark while leaving primary and secondary metrics visible.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #1195
Summary: The merged Spark support PR already added the optional-extra display gating that solves the central request; the remaining provider-page checkbox question is a product/discoverability choice.

Members:

• canonical: Show Codex Spark usage #1195 - Merged PR added Codex Spark extra windows and made them obey the optional extra usage setting.
• same_root_cause: [Feature] Show Codex Spark usage #1177 - Closed feature request tracked adding Codex Spark usage, and the maintainer resolution explicitly noted the optional extra usage setting behavior.
• adjacent_distinct: Codex multi-account menu can misclassify Spark quota windows as refreshed primary/weekly limits #1987 - Open issue concerns incorrect multi-account primary/weekly values when Spark windows are present, not optional hiding of Spark display rows.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

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
Maintainer review should decide whether to close this as covered by the existing shipped Display setting or keep it open for a provider-local discoverability change.

Maintainer decision needed

• Question: Is the existing Display -> Show credits + extra usage toggle sufficient for this issue, or should Codex also expose a provider-page Spark-specific visibility control?
• Rationale: Current main already solves the central screen-real-estate problem, but the exact requested provider-scoped checkbox would add new settings surface and VISION.md says new features need sign-off.
• Likely owner: steipete — steipete merged the Spark support PR and is the best available owner for deciding whether the existing setting is sufficient or whether to add more settings surface.
• Options:
  • Close with existing setting (recommended): Treat the shipped Display toggle as the supported solution and point the reporter to it.
  • Add a provider-local alias: Keep this open to add a Codex provider-page control that mirrors the existing optional-extra visibility behavior.
  • Design a narrower Spark-only setting: Keep this open for a separate Codex Spark preference, accepting additional per-provider settings complexity.

Review details

Best possible solution:

Use the existing Display setting as the supported answer unless maintainers want a provider-local alias; any new UI should reuse the same presentation filter and avoid changing usage fetching or stored quota data.

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

Not applicable: this is a feature/discoverability request, not a bug in an established contract. Source and tests do confirm the current behavior that disabling optional extra usage hides Codex Spark while leaving primary and secondary metrics visible.

Is this the best way to solve the issue?

Yes for the central user problem: the existing Display toggle is the narrowest shipped solution because it filters presentation without changing quota fetching. A new provider-specific checkbox should only be added if maintainers want that extra discoverability or granularity.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The remaining nuance is discoverability and granularity: the shipped control is a global Display setting, while the issue asks for a Codex provider-page checkbox.

Codex review notes: model internal, reasoning high; reviewed against bc9e006cdd8d; fix evidence: release v0.31.0, commit afe4e802239f.

Label changes

Label changes:

• add P3: This is a low-risk ergonomics and discoverability request around usage display density.
• add impact:ux-friction: The issue reports avoidable scrolling and screen-space pressure, not a blocked setup or incorrect quota calculation.
• add issue-rating: 🌊 off-meta tidepool: 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.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: This is a low-risk ergonomics and discoverability request around usage display density.
• impact:ux-friction: The issue reports avoidable scrolling and screen-space pressure, not a blocked setup or incorrect quota calculation.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was read fully; its guidance favors small provider/settings changes, focused tests, and avoiding live account probes for this kind of review. (AGENTS.md:1, bc9e006cdd8d)
• Existing Display setting: Current main renders a Display pane toggle bound to showOptionalCreditsAndExtraUsage, the existing user-facing control for optional credits and extra usage. (Sources/CodexBar/PreferencesDisplayPane.swift:83, bc9e006cdd8d)
• Default is checked: Current main defaults showOptionalCreditsAndExtraUsage to true when the user has not stored a preference, matching the requested default-on behavior. (Sources/CodexBar/SettingsStore.swift:438, bc9e006cdd8d)
• Codex Spark filtering behavior: Current main treats Codex additional limits such as Spark as optional extra usage and returns no Codex extra rate-window metrics when showOptionalCreditsAndExtraUsage is false. (Sources/CodexBar/MenuCardView+ModelHelpers.swift:526, bc9e006cdd8d)
• Focused regression coverage: MenuCardModelCodexProjectionTests asserts that disabling showOptionalCreditsAndExtraUsage removes codex-spark and codex-spark-weekly while keeping primary and secondary Codex metrics present. (Tests/CodexBarTests/MenuCardModelCodexProjectionTests.swift:762, bc9e006cdd8d)
• Implementation provenance: PR metadata for Show Codex Spark usage #1195 says the merged Spark work maps Spark to named extra windows and respects the optional extra usage setting; merge commit afe4e80 introduced the behavior. (Sources/CodexBar/MenuCardView+ModelHelpers.swift:526, afe4e802239f)

Likely related people:

• LeoLin990405: PR metadata for the merged Spark usage work shows LeoLin990405 authored the commits that added Codex additional-rate-limit mapping, optional-extra gating, and regression tests. (role: introduced Spark support; confidence: high; commits: d9eceaa309a6, 37bfefb4422f, 4f9c902c2a71; files: Sources/CodexBarCore/Providers/Codex/CodexAdditionalRateLimitMapper.swift, Sources/CodexBar/MenuCardView+ModelHelpers.swift, Tests/CodexBarTests/CodexAdditionalRateLimitsTests.swift)
• steipete: steipete merged the Spark PR, posted the prior issue resolution noting that Spark obeys the optional extra usage setting, and authored the current latest release commit containing the behavior. (role: merger and recent area contributor; confidence: high; commits: afe4e802239f, a83a83fa4131; files: Sources/CodexBar/MenuCardView+ModelHelpers.swift, Sources/CodexBar/PreferencesDisplayPane.swift, Tests/CodexBarTests/MenuCardModelCodexProjectionTests.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.