Add per-provider quota row visibility - #3123
Conversation
Providers can report a dozen extra quota lanes beyond session/weekly — Claude's model-scoped weekly limits (Fable, Design, ...), Antigravity's per-model quotas, and so on — and the menu shows all of them. Today the only way to trim that list is the one-off toggles that exist per lane family (claudeDailyRoutinesUsageVisible, codexSparkUsageVisible). Add a generic per-provider set of hidden row IDs with a checkbox list in the provider pane, discovered from the latest snapshot rather than hard-coded so it follows whatever lanes the account actually exposes. Hidden rows stay listed in settings so they can be restored, alongside a Show all button. Only the menu rows are filtered; fetches, quota warnings, and history are untouched.
|
🦞👀 Pull request received. I will update this pull request when review starts. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7c735a2ca1
ℹ️ 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".
|
|
||
| private func binding(for id: String) -> Binding<Bool> { | ||
| Binding( | ||
| get: { self.settings.isQuotaRowVisible(id, for: self.provider) }, |
There was a problem hiding this comment.
Reflect upstream visibility gates in quota checkboxes
When optional credits/extra usage, Codex Spark usage, or Claude Daily Routines usage is disabled, the snapshot rows remain listed here and this getter still reports them as checked because it consults only the hidden-ID set; however, extraRateWindowMetrics removes those rows through the existing family-level gates. Consequently, a checkbox can claim that a row is visible while it is absent from the menu, and toggling it or using “Show all” cannot restore it. Make these bindings or their enabled/visible state account for the existing gates.
Useful? React with 👍 / 👎.
|
Codex review: needs real behavior proof before merge. Reviewed August 21, 2026, 12:20 PM ET / 16:20 UTC. ClawSweeper reviewWhat this changesAdds a stored per-provider hidden-row list and provider-pane checkboxes to suppress reported extra quota rows from the menu. Merge readiness⛔ Blocked until real behavior proof is added - 9 items remain Keep open for product sponsorship and repair: the new picker can report rows as visible while existing display settings intentionally suppress them from the menu, and no after-fix UI proof is provided. Priority: P3 Review scores
Verification
Live VerificationCommand: Result: FAIL (failed) — execution before step 1 Assertions:
How this fits togetherProvider adapters produce usage snapshots containing primary limits and extra quota windows. The provider settings pane stores display preferences, which the menu-card model applies before rendering menu rows. flowchart LR
A[Provider usage snapshot] --> B[Extra quota rows]
B --> C[Provider settings pane]
C --> D[Per-row visibility preference]
G[Existing family visibility settings] --> E[Menu-card display decision]
D --> E
E --> F[Rendered menu rows]
Decision needed
Why: The branch adds a broad new user preference rather than repairing an established contract, and the discussion contains no maintainer approval for the lasting settings direction. Before merge
Findings
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: If sponsored, make the row picker reflect the existing display gates, add regression coverage for those gate combinations, and provide a redacted after-fix settings-to-menu demonstration. Do we have a high-confidence way to reproduce the issue? Yes—source inspection provides a high-confidence path: disable an existing family-level gate while its snapshot still has extra rows; the new pane marks them visible while the menu removes them. Is this the best way to solve the issue? No—the branch does not yet preserve the established visibility gates. A row picker must reflect both the global/family gate and the per-row preference. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against f74117aeb7a9. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
|
Summary
Providers report a growing number of extra quota lanes beyond session/weekly — Claude's
model-scoped weekly limits (Fable, Design, …), Antigravity's per-model quotas, Factory's
core windows — and the menu renders all of them. Today the only way to trim that list is a
one-off toggle per lane family (
claudeDailyRoutinesUsageVisible,codexSparkUsageVisible,copilotBudgetExtrasEnabled), which needs new code and a newsetting for every family that appears.
This adds the generic version: a per-provider set of hidden row IDs, so a user can hide the
individual lanes they never use.
Changes
QuotaRowVisibilityState: pure set arithmetic for the hidden-ID storage, kept out ofSettingsStoreso it is testable without constructing a store.SettingsStoreaccessors (hiddenQuotaRowIDs(for:),setQuotaRow(_:visible:for:),showAllQuotaRows(for:)) persisted underhiddenQuotaRowIDs, plus menu observation sothe menu re-renders on change.
Model.Input.hiddenQuotaRowIDsfiltersextraRateWindowMetrics. The existingCodex Spark and Daily Routines filters are unchanged and still apply on top.
ProviderQuotaRowVisibilitySettingsView: a "Quota rows" section in the provider pane.Rows come from the latest snapshot rather than a hard-coded list, so it follows whatever
the account exposes; rows the user hid stay listed so they can be restored, plus a
"Show all" button.
Commands run
swift build --target CodexBar— clean (typechecks the whole module)node Scripts/check-app-locales.mjs—App locales OK: Checked 22 catalogs against 1482 English keys.Notes
SettingsStoreso they cannot reach Keychain-backedstores, per the testing guidance in AGENTS.md.
same mechanism; this PR deliberately leaves them alone.
Verification caveat
Developed on a machine with only CommandLineTools and no Xcode, so
make testandswiftlintcould not run here (Testingmodule unavailable; swiftlint fails loadingsourcekitdInProc), and there is no screenshot of the new section for the same reason.Relying on CI for the suite — happy to iterate on anything it flags.