feat: hide untouched Antigravity model families

[urda]

Problem

Antigravity's RetrieveUserQuotaSummary reports every model family the plan
covers, not just the ones the account uses. An account that only runs Gemini
still receives a Claude/GPT group, so the menu card, the provider settings
Usage list, and the widget each carry two rows pinned at 0% used that will never
move. On a small widget, where the row limit is 2, those dead rows can crowd out
the lanes that matter.

Fix

Hide a model family once no lane in it reports known usage above zero.

Hiding is per family, never per lane, so a family in use keeps its full 5-hour
and weekly pair even when one of them happens to sit at zero. That matters every
week: a weekly lane resets to 0% while the 5-hour lane is still active, and
per-lane hiding would drop the weekly row until the next call.

When every family is untouched, nothing hides, so the card never renders empty.
An "unavailable" lane (bucket disabled, or no remainingFraction) counts as
not used.

AntigravityQuotaFamilyVisibility in CodexBarCore owns the rule so the menu
card and the widget cannot drift apart. Family grouping uses the bucket ID first
(gemini, 3p, third-party), which matches the widget's existing row
resolver, because the ID survives a display-text change. A group with neither
signal uses the rendered title without its 5-hour or weekly suffix, so an
unfamiliar family still pairs its lanes.

Provider settings opts out through a new showsAllUsageLanes flag on the card
model input, set at exactly one call site. It is the diagnostic surface and
always lists every family, the same principle the pane already applies to cost
data:

Display style only controls the main menu. Provider details always expose
available cost data in their Usage section.

The change is display-only. The snapshot, CLI output, and diagnostics still
carry every window. Menu-bar text and icon selection rank by highest used, so an
untouched family never won there anyway, and quota warnings fire on low
remaining, so an untouched family never triggered one. No new setting: no
UserDefaults key, no provider config field, no sync field, no toggle. The rule
is computed from the snapshot at render time.

Behavior

Case	Gemini	Claude/GPT
both used	shown	shown
Gemini used only	shown	hidden
Claude/GPT used only	hidden	shown
neither used	shown	shown

Surface	both used	one used	neither used
Menu card	both	the used one	both
Widget rows	both	the used one	both
Provider settings	both	both	both

Screenshots

Menu card, both usage-bar modes.

Case	Percent used	Percent left
both used
Gemini used only
Claude/GPT used only
neither used

Provider settings, same payload as the Gemini-only row above, showing all four
lanes.

Surface	Percent used	Percent left
Settings Usage section

Every image above is the real SwiftUI view rendered through ImageRenderer from
a synthetic snapshot. No account data.

Side benefit

The Antigravity widget row limit is 2 on small and 3 on medium
(AntigravityProviderDescriptor.swift). With four lanes the medium widget
truncated the last row. With the untouched family gone, both Gemini lanes fit.

Proof

• Green: swift test --filter "MenuCardAntigravityTests|UsageStoreWidgetSnapshotTests" — 27/27 tests.
• Green: swift test --filter ProviderArchitectureGatekeeperTests — 38/38 tests.
• Green: make test — 70/70 groups, 840 selections.

New cases cover hiding an untouched family, hiding a family whose only known
lane is untouched, keeping every family when all are untouched, provider
settings keeping every family, and the widget dropping untouched families.

The allowlist in ProviderArchitectureGatekeeperTests pins exact line numbers,
so inserting lines into MenuCardView+ModelHelpers.swift shifted five anchors.
Those entries move by three; anchors, provider sets, reference counts, and
fingerprints are unchanged. The new CodexBarCore file also carries a
Provider-specific by design: marker, since the scanner reads the gemini and
claude string literals in the family match as provider references.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

[urda]

@clawsweeper ready

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: da5ede2283

ℹ️ About Codex in GitHub

Codex has been enabled to automatically 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 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed August 14, 2026, 2:52 AM ET / 06:52 UTC.

ClawSweeper review

What this changes

The PR hides fully untouched Antigravity quota model families from menu cards and widgets while provider settings continue to show every reported lane.

Merge readiness

⚠️ Ready for maintainer review - 4 items remain

Keep open for maintainer review: the supplied PR evidence supports a focused display-only refinement, but this review environment could not inspect the checked-out current branch or main history; the remaining decision is whether existing users should lose zero-use Antigravity family rows in compact views after upgrade.

Priority: P2
Reviewed head: b03b4b2a033cb0938e6d309cd645c43f266acc5b
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	The supplied patch and direct visual proof are strong, with merge readiness limited by the intentional compatibility and product-policy choice.
Proof confidence	🦞 diamond lobster (5/6) ✨ media proof bonus	Sufficient (screenshot): The PR body supplies after-fix rendered SwiftUI screenshots for the changed menu, widget, and settings states; no contributor action is needed for proof.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (screenshot): The PR body supplies after-fix rendered SwiftUI screenshots for the changed menu, widget, and settings states; no contributor action is needed for proof.
Evidence reviewed	4 items	Supplied branch implementation: The supplied PR patch adds a shared Antigravity family classifier that returns untouched window IDs only when at least one other family has known usage, avoiding an empty post-reset compact view. Settings compatibility path: The supplied diff sets showsAllUsageLanes only for the provider-details card, preserving all reported Antigravity lanes in the diagnostic settings surface. After-fix visual proof: The PR body includes rendered SwiftUI screenshots for both usage-bar modes, both-family and single-family cases, all-untouched fallback, and settings retaining all lanes; the supplied context also marks proof sufficient.
Findings	None	None.
Security	None	None.

How this fits together

CodexBar converts provider quota snapshots into menu-card metrics, provider-settings usage details, and widget rows. The new Antigravity filter sits between the shared snapshot and compact display surfaces, while settings bypass it for diagnostics.

flowchart LR
    A[Antigravity quota snapshot] --> B[Family classifier]
    B --> C{Any family used?}
    C -->|Yes| D[Hide untouched families]
    C -->|No| E[Keep all families]
    D --> F[Menu card and widget]
    E --> F
    A --> G[Provider settings]
    G --> H[Show every lane]

Loading

Decision needed

Question	Recommendation
Should compact menu and widget views intentionally hide available Antigravity model families with no known usage, while settings remains the only complete lane list?	Adopt curated compact views: Accept the display-only change because provider settings still exposes all quota lanes and the compact surfaces prioritize active families.

Why: This is a user-facing presentation-policy change rather than repair of an established broken contract; source evidence does not determine whether always-visible zero-use diagnostic rows are a desired compatibility guarantee.

Before merge

• Resolve merge risk (P1) - Merging changes the established compact presentation for existing Antigravity users: zero-use but available model-family rows disappear from menu and widget views with no preference to restore them.
• Resolve merge risk (P1) - The checkout sandbox prevented independent verification of the current head against main, so this review cannot establish whether later changes altered the supplied patch or its compatibility behavior.
• Complete next step (P2) - A maintainer must choose whether the compact-display compatibility tradeoff is intentional before merge.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Patch composition	9 files affected; production +66/-2, docs +6, tests +415/-5	The change is small in runtime code but adds broad focused coverage around menu, widget, and provider-settings behavior.

Merge-risk options

Maintainer options:

1. Accept the compact-display policy (recommended)
   Land the shared filter if maintainers explicitly accept that existing compact views will no longer show untouched but available Antigravity families after upgrade.
2. Retain the existing presentation
   Pause this PR if always-visible quota-family diagnostics in compact surfaces are part of the intended user experience.

Technical review

Best possible solution:

If maintainers want curated compact Antigravity displays, retain this shared display-only filter, keep provider settings as the complete diagnostic surface, and document the intentional upgrade behavior.

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

Not applicable: this PR proposes a compact-display policy change rather than reporting a reproducible defect.

Is this the best way to solve the issue?

Unclear: the shared filter is a maintainable way to prevent menu/widget drift, but whether hiding previously visible diagnostic rows is the best product behavior requires maintainer intent.

AGENTS.md: found and applied where relevant.

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

Labels

Label justifications:

• P2: This is a bounded provider-usage presentation change with limited blast radius.
• merge-risk: 🚨 compatibility: Existing users can lose previously visible zero-use family rows from compact displays immediately after upgrade.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (screenshot): The PR body supplies after-fix rendered SwiftUI screenshots for the changed menu, widget, and settings states; no contributor action is needed for proof.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body supplies after-fix rendered SwiftUI screenshots for the changed menu, widget, and settings states; no contributor action is needed for proof.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. The PR body supplies after-fix rendered SwiftUI screenshots for the changed menu, widget, and settings states; no contributor action is needed for proof.

Evidence

What I checked:

• Supplied branch implementation: The supplied PR patch adds a shared Antigravity family classifier that returns untouched window IDs only when at least one other family has known usage, avoiding an empty post-reset compact view. (Sources/CodexBarCore/Providers/Antigravity/AntigravityQuotaFamilyVisibility.swift:9, b03b4b2a033c)
• Settings compatibility path: The supplied diff sets showsAllUsageLanes only for the provider-details card, preserving all reported Antigravity lanes in the diagnostic settings surface. (Sources/CodexBar/PreferencesProvidersPane.swift:596, b03b4b2a033c)
• After-fix visual proof: The PR body includes rendered SwiftUI screenshots for both usage-bar modes, both-family and single-family cases, all-untouched fallback, and settings retaining all lanes; the supplied context also marks proof sufficient. (b03b4b2a033c)
• Local inspection infrastructure failure: The repository sandbox rejected the read-only inspection command before it could read the checkout, so current-main behavior, branch ancestry, exact changed-head contents, and git ownership history could not be independently verified.

Likely related people:

• steipete: The target repository is steipete/codexbar and the supplied PR timeline shows a direct mention and subscription; local feature-history inspection was unavailable. (role: likely product-direction owner; confidence: medium; files: Sources/CodexBar/MenuCardView+ModelHelpers.swift, Sources/CodexBar/UsageStore+WidgetSnapshot.swift)

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• 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.

History

Review history (14 earlier review cycles; latest 8 shown)

• reviewed 2026-08-12T21:41:49.431Z sha 26c014f :: found issues before merge. :: [P2] Record the change in the unreleased section
• reviewed 2026-08-12T21:49:02.004Z sha f67c60d :: needs maintainer review before merge. :: none
• reviewed 2026-08-12T22:50:33.927Z sha f67c60d :: needs maintainer review before merge. :: none
• reviewed 2026-08-13T03:36:35.192Z sha ba47389 :: needs maintainer review before merge. :: none
• reviewed 2026-08-13T21:44:11.699Z sha 02e2fe4 :: found issues before merge. :: [P3] Remove the release-owned changelog entry
• reviewed 2026-08-14T02:08:36.822Z sha 2caeba7 :: needs maintainer review before merge. :: none
• reviewed 2026-08-14T04:56:29.952Z sha 47988bc :: needs maintainer review before merge. :: none
• reviewed 2026-08-14T05:52:55.848Z sha 6cdc166 :: needs maintainer review before merge. :: none

[urda]

@steipete Like a lot of agy users I only really use gemini, this helps "streamline" the UI.

[steipete]

Thank you @urda — the design is right and it's landing. Your fork disallows maintainer edits, so I've opened #2924 with your commits preserved verbatim (you as author) plus one correction: a family whose usage is unknown (nil) is no longer hidden as if it were known-zero — usageKnown is now required before a lane counts as idle. Closing this PR in favor of #2924; credit is preserved in the commits and changelog.

[urda]

@steipete I'll look into that / move the repo sometime (wonder why you can't)

I'm always also happy to make "corrections" via review.