Cursor: toggle between included usage and raw API usage

[robinebers]

Problem

Cursor tracks two different kinds of usage:

Kind	Meaning
Included usage	Consumption covered by the plan (CSV Cost column = Included)
Raw API usage	Billed on-demand / API usage (CSV Cost column is a dollar amount)

OpenUsage currently mixes both when showing Cursor spend. The Today / Yesterday / Last 30 Days tiles price every CSV row from token counts via the bundled model manifest, ignoring whether Cursor marked the row as included or billed.

That makes the spend tiles misleading for users who only care about one view — e.g. "how much of my included plan did I use today?" vs "how much API/on-demand spend did I rack up?"

Current behavior

• CursorUsageCSV.parse reads token columns but drops the Cost column (see comment in CursorUsageCSV.swift: actual-cost / CostMode path deferred for v1).
• CursorUsageMapper.appendSpendLines sums imputedCostDollars across all rows with no filter.
• Dashboard API metrics (apiPercentUsed, autoPercentUsed, totalPercentUsed) come from Cursor's Connect RPC and are separate from the CSV spend tiles.

Ask

Add a user-facing toggle (Cursor-specific) to choose which usage view to show for spend-related metrics:

• Included only — aggregate rows where Cost = Included (priced locally from tokens, or $0 if we treat included as non-billable)
• Raw API only — aggregate rows with an actual dollar Cost from the CSV (or non-Included rows)
• All usage (default) — current behavior for users who want the combined picture

UX ideas

• Setting in Settings under a Cursor section, or a compact control on the Cursor provider card
• Clear labels: e.g. "Included Usage" / "API Usage" / "All Usage"
• Persist preference per device
• Spend tiles (Today, Yesterday, Last 30 Days) respect the toggle; document whether bounded metrics (Total Usage %, API Usage %) should also switch or stay as Cursor reports them

Implementation notes

• Extend CursorUsageCSVRow to carry billing kind (included vs billed) parsed from the Cost column.
• Thread the preference through CursorProvider → appendSpendLines (and any Tauri plugin parity if still maintained on main).
• Add tests for mixed CSV rows (some Included, some $1.23) and verify each toggle mode sums correctly.
• Update docs/providers/cursor.md to explain the toggle and what each mode means.

References

• Sources/OpenUsage/Providers/Cursor/CursorUsageCSV.swift
• Sources/OpenUsage/Providers/Cursor/CursorUsageMapper.swift — appendSpendLines
• Sources/OpenUsage/Providers/Cursor/CursorProvider.swift — spend widget descriptors
• Prior art: cursorcat UsageCSV.swift CostMode path (dropped in v1 port)
• Test fixtures in Tests/OpenUsageTests/CursorSpendTests.swift already use Cost = Included

Acceptance

• User can switch between included-only, raw-API-only, and all-usage views for Cursor spend tiles.
• Each mode produces correct totals on mixed CSV data.
• Default preserves today's combined behavior.
• Documented in docs/providers/cursor.md.

[maxmilian]

@robinebers — a request and a heads-up, both out of the same event.

The request: could you assign this issue to me? #996 implements it and has been open since 13 July, but pr-policy.yml closed it this morning because this issue, while open and approved, has no assignee. I'd force-pushed a rebase (the branch had drifted to CONFLICTING against main), and that was the first synchronize on the PR since the policy landed, so the gate evaluated it for the first time. The rebased branch is intact at 141c5de4; once this is assigned I can reopen.

The heads-up, which probably matters more than my PR: the policy landed on 25 August (#1170) and triggers on opened, reopened, edited, synchronize, labeled. Every external PR opened before that date is currently unevaluated, not exempt. The next push, body edit, or label on any of them runs the gate for the first time, and wherever the linked issue isn't assigned to the PR author, it closes — days or weeks apart, with nothing tying the closures back to the policy change.

Two details that may make that noisier than intended:

• gate-passed isn't in the exemption list — only keep-open is. Some pre-policy PRs carry gate-passed (mine does). If that label was the earlier marker for "this one has been vetted", those PRs now read as unvetted.
• Assignment is a maintainer-only action for outside contributors, so an affected author can't clear the condition themselves — they can only ask, on an issue they may not realise is the blocker. The bot comment says "wait for a maintainer to approve and assign it to you", which reads as a step that has already happened when the approved label is right there.

I'm not suggesting the policy should change — the requirement is reasonable, and I'd rather the gate existed than not. It's only the retroactive reach into the existing backlog that looks worth a deliberate pass: either sweeping the open pre-25-August PRs now, or adding keep-open to the ones you want to survive their next event.

[maxmilian]

Following up with a new data point rather than repeating the ask.

This morning #1186 was opened against #1124 at 08:12:49Z and closed by pr-policy.yml at 08:12:59Z — ten seconds, for the same reason #996 was closed here: the issue carries approved but has no assignee, so the second condition can never be met by the contributor. @arpankanwer has since asked to be assigned, same as I did on 27 August.

So this is not a one-off. The gate is currently structured so that an approved issue with an empty assignee field is unactionable by design: contributing requires an assignment, and the assignment can only come from a maintainer. Every contributor who reads approved as "this is open for work" produces a PR that is closed within seconds.

Where #996 actually stands, in case it makes the assignment cheap to grant:

• You reviewed it on 14 July — "architecture and default look right" — and left three follow-ups.
• All three are in: 4ac3e81 covered the label copy and the pinning, 53176f5 folded in the API Usage naming point.
• The branch is at zero commits behind origin/main (git rev-list --count rebase/pr996..origin/main → 0), so there is no rebase debt.
• The gap is still real on main: CursorUsageCSV.swift:6 still reads "dropping the actual-cost / CostMode path for v1", and spendview has no matches under Sources/.

Happy either way — assign it and I'll reopen, or say the word and I'll close the branch out so it stops sitting in your queue. I'd just rather it be a decision than a timeout.