Make Cursor extra usage optional

[Zihao-Qi]

Summary

• stop showing Cursor's static Credits placeholder because Cursor does not provide an account credit balance
• make Cursor on-demand usage respect the existing "Show credits & extra usage" setting in both menu presentations
• generalize the setting description for all supported providers and update its localizations
• preserve the section separator when Cost is the only optional section shown

Why

Cursor's descriptor advertised Credits even though CodexBar did not fetch a credit balance. At the same time, Cursor's real provider-metered on-demand usage was always visible and could not be controlled by the existing optional-usage setting. This aligns the UI with the data CodexBar actually receives and makes the setting behavior consistent.

Validation

• swift test --filter StatusMenuNativeSectionSpacingTests
• make check

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed July 19, 2026, 11:07 AM ET / 15:07 UTC.

Summary
This PR removes Cursor’s unsupported credits placeholder, makes Cursor on-demand usage follow the existing credits-and-extra-usage preference in card and native menus, and updates spacing, tests, and localized setting text.

Reproducibility: yes. at source level: the changed model and provider-menu branches are directly exercised by focused tests with the preference enabled and disabled. No high-confidence freshly built native-menu runtime reproduction was supplied.

Review metrics: 2 noteworthy metrics.

• Patch surface: 31 files affected; 220 added, 44 removed. Four implementation/test files are accompanied by 23 localized setting-description updates, so the preference-contract decision propagates across the app.
• Focused regression coverage: 4 test files changed or added. The patch covers Cursor card state, Cursor native-menu entries, general optional credits, and native section spacing.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🐚 platinum hermit
Result: blocked until real behavior proof from a real setup is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Attach redacted fresh-bundle proof of Cursor with the preference enabled and disabled, including the native cost-only layout.
• Obtain maintainer confirmation that the existing preference should change behavior for non-Cursor credit sections as covered by the new Augment test.

Proof guidance:

• [P1] Needs real behavior proof before merge: The PR body reports focused tests and make check, but does not include after-fix evidence from a real freshly built CodexBar menu; please attach redacted screenshot, recording, terminal output, or runtime logs, then update the PR body for re-review.

Risk before merge

• [P1] Existing users with the preference disabled will now lose visible credit sections for supported providers beyond Cursor; that compatibility change is intentional in the branch tests but needs explicit maintainer confirmation before merge.
• [P1] The supplied validation is test/check-only, so native menu rendering and separator placement have not been demonstrated from a freshly built app bundle.

Maintainer options:

1. Confirm the preference contract and prove it (recommended)
   Before merge, confirm the cross-provider meaning of the existing setting and attach redacted fresh-bundle evidence for Cursor enabled/disabled plus the cost-only native-menu layout.
2. Narrow the behavior to Cursor
   If the stored preference should retain its previous provider scope, restrict the generalized card-model change and keep only Cursor’s optional on-demand-usage behavior.

Next step before merge

• [P1] The remaining blocker is a maintainer choice about an existing preference’s cross-provider contract plus contributor-supplied runtime proof, not a safe autonomous repair.

Maintainer decision needed

• Question: Should the existing “Show credits & extra usage” preference become a cross-provider control that hides credit sections for providers such as Augment as well as Cursor?
• Rationale: The branch deliberately changes behavior beyond the Cursor-specific request and alters what existing users see when an already-stored preference is disabled; source tests prove the implementation but cannot establish the intended permanent preference contract.
• Likely owner: steipete — Likely repository-level owner for the provider-menu preference contract; historical per-file ownership could not be established from the supplied read-only evidence.
• Options:
  • Approve cross-provider semantics (recommended): Keep the generalized model behavior after contributor proof confirms the enabled and disabled menu states for Cursor and a credit-bearing provider.
  • Limit the change to Cursor: Retain Cursor on-demand usage gating but restore the previous behavior for unrelated providers until their inclusion is separately approved.

Security
Cleared: The diff changes provider display logic, tests, and localized strings without introducing dependency, workflow, credential, secret, or supply-chain changes.

Review details

Best possible solution:

Confirm that “Show credits & extra usage” is the intended cross-provider preference contract, then add redacted fresh-bundle proof showing Cursor with the setting both enabled and disabled, including the cost-only native menu case.

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

Yes at source level: the changed model and provider-menu branches are directly exercised by focused tests with the preference enabled and disabled. No high-confidence freshly built native-menu runtime reproduction was supplied.

Is this the best way to solve the issue?

Yes, conditionally: reusing the existing preference is the narrowest implementation path, but maintainers must first confirm that its contract should cover credits and extra usage across providers rather than only Cursor.

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

• add P3: This is a low-risk provider-menu consistency improvement rather than an urgent service interruption.
• add merge-risk: 🚨 compatibility: The PR changes the effect of an existing persisted preference for providers beyond Cursor, so some upgraded users may see different menu sections.
• add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body reports focused tests and make check, but does not include after-fix evidence from a real freshly built CodexBar menu; please attach redacted screenshot, recording, terminal output, or runtime logs, then update the PR body for re-review.

Label justifications:

• P3: This is a low-risk provider-menu consistency improvement rather than an urgent service interruption.
• merge-risk: 🚨 compatibility: The PR changes the effect of an existing persisted preference for providers beyond Cursor, so some upgraded users may see different menu sections.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body reports focused tests and make check, but does not include after-fix evidence from a real freshly built CodexBar menu; please attach redacted screenshot, recording, terminal output, or runtime logs, then update the PR body for re-review.

Evidence reviewed

What I checked:

• Cursor card behavior: The branch makes UsageMenuCardView.Model suppress credits whenever the optional-usage preference is off, rather than applying that suppression only to the earlier Codex-projection condition. (Sources/CodexBar/MenuCardView.swift:906, 477c8568a43d)
• Cursor native-menu behavior: The Cursor provider implementation now returns no on-demand usage entry when showOptionalCreditsAndExtraUsage is disabled, with focused coverage for both disabled and enabled states. (Sources/CodexBar/Providers/Cursor/CursorProviderImplementation.swift:85, 477c8568a43d)
• Cross-provider preference expansion: The branch also adds an Augment regression test asserting that its credits are hidden when the same preference is disabled, so the behavioral change is intentionally broader than Cursor alone. (Tests/CodexBarTests/MenuCardOptionalUsageModelTests.swift:7, 477c8568a43d)
• Native spacing coverage: The branch adds coverage for a standalone cost section, matching the unconditional section-separator changes in the native menu builder. (Tests/CodexBarTests/StatusMenuNativeSectionSpacingTests.swift:9, 477c8568a43d)
• Contributor validation and proof gap: The PR body reports a focused test and make check, but provides no redacted screenshot, recording, terminal output, or runtime log showing the changed Cursor menu after a fresh bundle launch. (477c8568a43d)

Likely related people:

• steipete: The current repository documentation places provider-specific menu hooks in Sources/CodexBar/Providers/<ProviderID>/ and describes Cursor as a supported provider; no stronger per-line ownership provenance was available in the supplied read-only review evidence. (role: likely provider/menu follow-up owner; confidence: low; files: Sources/CodexBar/Providers/Cursor/CursorProviderImplementation.swift, Sources/CodexBar/MenuCardView.swift, Sources/CodexBar/StatusItemController+Menu.swift)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

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.

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.