Cursor Extra Usage is inaccurate for Business plans

[cszmzh]

Cursor Extra Usage is inaccurate for Business plans — usage-summary.used excludes Cursor Token Fee

Problem

The Cursor Extra Usage displayed in CodexBar is inaccurate for Cursor Business plans.

The issue comes from this Cursor API:

https://cursor.com/api/usage-summary

The limit returned by this endpoint is correct, but used does not include charges from Cursor Token Fee.

As a result, requests that incur Cursor Token Fee are not reflected in Extra Usage, causing CodexBar to report a lower usage amount and percentage than the actual amount charged by Cursor.

Comparison with another Cursor API

Cursor also provides:

https://cursor.com/api/dashboard/get-team-spend

The spendCents returned by this endpoint includes Cursor Token Fee and matches the actual Extra Usage charges.

However, the response from this endpoint is quite large, so it may not be ideal if the only goal is to retrieve Extra Usage.

A more accurate approach

Another solution is to calculate Extra Usage by aggregating the current month's Usage Events / usage history.

Cursor's usage history indicates whether each request is included in the Business plan:

• USAGE_EVENT_KIND_INCLUDED_IN_BUSINESS: included in the Business plan and should not count toward Extra Usage
• Other billable Usage Events: count toward Extra Usage

By aggregating the actual costs of all billable events for the current month, the resulting Extra Usage matches the actual charges shown on the Cursor Dashboard.

Reproduction

After using a model that incurs Cursor Token Fee:

1. Cursor charges the request as Extra Usage.
2. spendCents from get-team-spend increases accordingly.
3. The corresponding billable entry is present in Usage Events.
4. used returned by usage-summary does not include the Cursor Token Fee.
5. CodexBar therefore displays an incorrect Extra Usage amount and percentage.

The usage-summary.used field does not represent the complete Extra Usage billing amount for Cursor Business plans.

I suggest using either get-team-spend.spendCents or aggregating the current month's Usage Events to calculate Cursor Extra Usage.

CodexBar:

Actually accurate:

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 13, 2026, 5:59 AM ET / 09:59 UTC.

Summary
Keep open: current main still maps usage-summary on-demand used into the menu’s Extra usage value, while a separate opt-in cost path already computes Cursor-metered spend from usage-event chargedCents. The report identifies a plausible mismatch, but choosing the regular-status data source has refresh and team-scope implications.

Likely related people

• Peter Steinberger — medium confidence; current snapshot and release-history attribution point to this Cursor surface.

Reproducibility: no. high-confidence live reproduction was run because it requires a Cursor Business account with a token-fee event; current source does confirm that the affected card directly projects usage-summary on-demand usage.

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.

Maintainer decision needed

Question	Recommendation
Should the regular Cursor Extra usage card adopt the usage-event metered total for Business accounts, despite that source currently being an opt-in paginated cost fetch?	Promote metered usage with a safe fallback: Use the cached, billing-cycle-scoped event total when complete and visibly fall back to the existing summary value when Cursor cannot provide a complete metered result.

Why: Current main has both a lightweight status source and a more authoritative event-derived metered source, but only maintainer intent can set the acceptable refresh, privacy, caching, and team-attribution behavior for the default menu surface.

Next step
A maintainer must choose whether the accurate but paginated event source belongs in normal status refresh before a focused repair can be safely scoped.

Review details

Best possible solution:

Define the Extra usage card as a billed, account-scoped value and reuse the metered event total with an explicit cache, scope rule, and clearly labeled fallback when Cursor does not return complete metered data.

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

No high-confidence live reproduction was run because it requires a Cursor Business account with a token-fee event; current source does confirm that the affected card directly projects usage-summary on-demand usage.

Is this the best way to solve the issue?

Unclear: event-derived chargedCents is the narrower existing accuracy mechanism, but making it the menu-card source needs a maintainer decision on refresh cost, billing-cycle scope, and team attribution.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Using the usage-events endpoint during ordinary status refresh could add a paginated, cookie-authenticated request path that is currently opt-in and bounded separately.
• A Business-team validation is needed to confirm whether the metered event total should represent an individual member, a shared pool, or both in the menu card.

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

Label changes

Label changes:

• add P2: The report concerns an inaccurate displayed spend amount for Cursor Business users, with a bounded but provider-specific remediation path.
• add impact:other: The concrete impact is inaccurate provider billing presentation, which does not fit the more specific owned impact classes.
• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-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:

• P2: The report concerns an inaccurate displayed spend amount for Cursor Business users, with a bounded but provider-specific remediation path.
• impact:other: The concrete impact is inaccurate provider billing presentation, which does not fit the more specific owned impact classes.

Evidence reviewed

What I checked:

• Current status projection: The status parser assigns individualUsage.onDemand.used from the usage-summary response to onDemandUsedUSD; the resulting snapshot uses that value as the provider-cost amount displayed as Extra usage. (Sources/CodexBarCore/Providers/Cursor/CursorStatusProbe.swift:1685, 8518b14e2b7a)
• Existing metered alternative: Current main already decodes each usage event’s chargedCents and aggregates it as the plan-deducted Cursor-metered total, returning no total if any valid event lacks a metered amount. (Sources/CodexBarCore/Providers/Cursor/CursorUsageEventsFetcher.swift:449, 8518b14e2b7a)
• Documented product boundary: Cursor documentation says the event fetch is opt-in through Show cost summary, may page up to 200, and reports Cursor-metered spend separately from the status provider cost. (docs/cursor.md:90, 8518b14e2b7a)
• Shipped related capability: Release v0.49.3 already contains the documented Cursor-metered event aggregation; this is a related capability, not a fix for the menu Extra usage projection. (docs/cursor.md:104, fc57a317cee4)
• History attribution: Available blame attributes the current Cursor status and usage-event lines to the v0.49.3 release snapshot by Peter Steinberger; the local history is grafted, so earlier feature-level provenance is not available locally. (Sources/CodexBarCore/Providers/Cursor/CursorUsageEventsFetcher.swift:295, fc57a317cee4)
• Vision fit: VISION.md supports bounded provider bug fixes but requires sign-off for provider-auth, privacy, or meaningful-complexity behavior changes, which applies to promoting a paginated cookie-authenticated event fetch into routine status refreshes. (VISION.md:1, 8518b14e2b7a)

Likely related people:

• Peter Steinberger: Available blame attributes the current status projection and metered event aggregation to the v0.49.3 snapshot, and the release commit is authored by Peter Steinberger. (role: recent Cursor-surface and release snapshot contributor; confidence: medium; commits: fc57a317cee4; files: Sources/CodexBarCore/Providers/Cursor/CursorStatusProbe.swift, Sources/CodexBarCore/Providers/Cursor/CursorUsageEventsFetcher.swift, docs/cursor.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.