Allow more than 3 providers in the Overview tab (compact density mode)

[elijahchan2019]

Is your feature request related to a problem?

CodexBar's value prop is keeping many AI coding providers visible at once (57+ supported), but in practice the popover's Overview tab only fits 3 providers on screen. For someone tracking several providers in parallel — in my case z.ai, Claude, Codex, and more I'd like to add — that means scrolling instead of a single-glance overview, which is exactly the moment a menu bar app is supposed to serve.

This isn't only about tile height. docs/ui.md documents that the Overview tab intentionally "renders up to 3 provider rows" and the Display → "Overview tab providers" setting is capped at 3. So the limit is part intentional cap, part density: even with the cap raised, today's tile layout wouldn't fit many more.

Current behavior (v0.42.0)

Each provider renders as a tall tile, and a multi-window provider makes it acute. z.ai renders three windows (Tokens / MCP / 5-hour), each with its own bar + percentage + reset line, plus a 24h usage bar chart and a "most used model" line — one z.ai tile consumes roughly a third of the popover on its own. Conversely, a provider with only a status line (Claude "Refreshing…") still reserves a full tile whose content-to-padding ratio is ~20–30%. Net result: 3 providers fill the viewport. (Screenshot attached.)

Why it matters

The target user — a developer running multiple AI tools — is precisely the one who wants to see all active providers' remaining quota at a glance, not three at a time. The current density works against the product's own pitch.

Proposed

Two independent levers (either helps; the density mode is the real fix):

1. Compact / dense display mode — an opt-in toggle under Settings → Display, alongside the existing "Overview tab providers", "Menu bar metric", and icon/label/bar/reset-time controls. Default unchanged so existing users are unaffected. In compact mode:

   • Collapse each provider to ~1–2 rows: icon + name + primary-window bar + percentage + reset on a single dense line.
   • Multi-window providers (Tokens/MCP/5-hour, session/weekly) show the primary window by default; secondary windows reveal on hover/click or via a small expander.
   • Hide the 24h usage chart and peak/model-count extras in the compact list (keep them in the per-provider detail card).
   • Reduce inter-tile and section padding.

   There's already a proven reference layout in the codebase: the CLI's codexbar cards --brief renderer (CLICardsBriefRenderer.swift) — "a compact table layout showing Provider, Usage (with sparkline bar), and Reset". Reusing that same density philosophy in the GUI popover would keep the two surfaces consistent.

2. Lift or make the Overview cap configurable — let "Overview tab providers" go beyond 3 (e.g. up to 6–8), ideally scaling with the density mode. Cheap on its own, but only pays off once tiles are denser.

Alternatives considered

• Merge Icons → Overview (existing): this is the Overview tab the cap applies to; it doesn't address density, and 3 is the ceiling.
• Fewer enabled providers: defeats the purpose of a multi-provider monitor.
• Resize the popover taller: macOS menu popovers constrain height, so not a reliable lever.

Environment

• CodexBar: 0.42.0 (build 102)
• macOS: 27.0
• Enabled providers in screenshot: z.ai (multi-window), Claude, Codex
• Merge Icons mode: on (Overview tab visible)

Suggested labels: enhancement, area:ui-ux, needs-design (priority: medium for heavy multi-provider users)

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 12, 2026, 10:42 PM ET / July 13, 2026, 02:42 UTC.

Summary
Current main and the latest release still intentionally limit Overview to three providers, while the requested compact mode and higher cap are new UX and configuration choices that fit CodexBar’s purpose but require product sign-off.

Reproducibility: yes. at the source and contract level: current docs/ui.md explicitly states that Overview renders and allows selection of only up to three providers. A live UI reproduction was not needed to establish that intentional limit.

Next step
A maintainer should first choose the supported compact-mode contract, provider cap, and secondary-window disclosure behavior; implementation should not guess these product decisions.

Maintainer decision needed

• Question: Should CodexBar support an opt-in compact Overview mode with more than three selected providers, and if so what cap and secondary-window disclosure behavior should be the supported contract?
• Rationale: The request adds persistent settings and changes which provider data is visible at a glance; source inspection confirms the current limit but cannot choose the intended density, cap, or disclosure UX.
• Likely owner: steipete — The repository vision assigns new-feature direction to sign-off, and the repository owner is the clearest available decision owner.
• Options:
  • Compact mode plus higher cap (recommended): Add an opt-in dense row style, keep the current layout as default, and allow roughly six to eight providers with accessible expansion for additional quota windows.
  • Raise cap only: Increase the existing selector limit while retaining full provider rows, accepting additional scrolling and variable popover height.
  • Keep three-provider design: Retain the current bounded Overview and direct users to provider tabs for additional detail.

Review details

Best possible solution:

Add an opt-in, provider-driven compact Overview presentation that preserves the existing default, exposes secondary windows through an accessible disclosure control, and raises the selection cap only when the compact layout has bounded-height UI proof.

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

Yes at the source and contract level: current docs/ui.md explicitly states that Overview renders and allows selection of only up to three providers. A live UI reproduction was not needed to establish that intentional limit.

Is this the best way to solve the issue?

Unclear pending product sign-off: preserving the current default and adding opt-in density is safer than globally shrinking rows, but the exact cap and interaction for hidden quota windows need a deliberate UX decision.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A compact row that defaults to one quota window could make secondary or tertiary limits too easy to miss unless expansion and accessibility behavior are designed explicitly.
• Raising the provider cap without a compact rendering path could make the menu taller and less usable on constrained displays.

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

Label changes

Label changes:

• add P3: This is a non-blocking, opt-in UI ergonomics feature for heavy multi-provider users rather than a regression or broken workflow.
• add impact:ux-friction: Users with more than three active providers can continue by scrolling or switching tabs, but the current cap prevents the requested single-glance workflow.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: 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 non-blocking, opt-in UI ergonomics feature for heavy multi-provider users rather than a regression or broken workflow.
• impact:ux-friction: Users with more than three active providers can continue by scrolling or switching tabs, but the current cap prevents the requested single-glance workflow.

Evidence reviewed

What I checked:

• Current documented limit: Current main documents that the merged Overview renders up to three provider rows, so the central request remains unimplemented. (docs/ui.md:249, c852c135e10c)
• Settings limit remains current: The current preferences documentation describes the Overview provider selector as limited to three. (docs/ui.md:280, c852c135e10c)
• Feature provenance: The merged Overview feature came from Add merged-menu overview tab with configurable providers #416; merge commit 856cbca includes the centralized cap work from 911abe6. (856cbcad82f6)
• Product direction: VISION.md identifies CodexBar as the control surface for provider limits and permits small UI/UX improvements, but explicitly requires sign-off for new features and meaningful maintenance complexity. (VISION.md:237, c852c135e10c)
• Release check: The latest release is v0.42.1, and current main still documents the three-provider cap; there is no evidence that compact density or a higher cap has shipped or landed on main. (docs/ui.md:249, c852c135e10c)
• Related issue is distinct: Feature request: aggregate token usage and cost across all providers #2065 requests cross-provider token and cost aggregation; it shares the Overview surface but does not cover provider-row density or the three-provider limit.

Likely related people:

• ratulsarna: Introduced the merged Overview tab, persisted provider selection, row navigation, and centralized provider cap through the merged feature history. (role: feature introducer and recent Overview contributor; confidence: high; commits: 856cbcad82f6, 911abe6a9355, 6efa7c8; files: Sources/CodexBar/MenuContent.swift, Sources/CodexBar/PreferencesMenuPane.swift, Tests/CodexBarTests/StatusMenuTests.swift)
• steipete: Authored the repository vision requiring sign-off for new features and is the best available owner for deciding whether compact Overview density should become a supported product mode. (role: repository owner and product-direction author; confidence: high; commits: d8b6892; files: VISION.md)

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.