Cursor Analytics: Measuring Usage, Cost, and Engineering ROI

Cursor analytics can show adoption, accepted suggestions, and AI-attributed committed code. Measuring ROI also requires actual costs, completed work, and quality outcomes. A rise in usage is evidence of adoption, not proof of a financial return.

For engineering leaders, the useful question is whether the team's investment changes the cost and quality of delivering comparable work. This guide outlines the available data and a practical evaluation method. First-party documentation was reviewed on September 22, 2026.

What data does Cursor provide?

Cursor's usage dashboard is available to Team and Enterprise customers, with CSV exports. Its charts cover active users, Agent edits, Tab completions, and AI share of committed code. Tab acceptance counts suggestions, while Agent edit charts include changed lines; these are different units. See Cursor's analytics documentation.

The Analytics API documents team and user endpoints for Agent edits, Tab usage, and model usage. It is restricted to Enterprise teams. Confirm access during evaluation rather than designing a reporting process around an unavailable endpoint.

Accepted code and committed code are different

Cursor attributes AI code by comparing signatures of suggested lines with subsequent Git commits. It documents limitations involving formatting changes and the machine used to score CLI commits. Its “Other” category means code not detected as Cursor-generated, so that category must not be treated as verified human-only work. See Cursor's attribution definitions.

Use that distinction throughout the report:

• Accepted suggestions indicate that an edit was useful enough to keep at the time.
• Committed changes indicate that work entered source control.
• Merged PRs indicate that work passed the team's review process.
• Delivered changes connect the work to releases and subsequent quality outcomes.

Do not describe an acceptance rate as a merge rate. Avoid using accepted lines as the denominator for business value, since verbose or subsequently discarded code can increase that number without improving the product.

Reconcile Cursor spending with the invoice

Cursor's Admin API documentation distinguishes spendCents, which excludes included usage, from overallSpendCents, which includes it. Spending data uses the current billing cycle. The usage-events endpoint provides model, token, and cost details; Cursor recommends its chargedCents field for reconciling event costs with spending totals.

For financial reporting, begin with the actual subscription and usage expense in your billing records. Keep usage-valued amounts separate from additional charges. Adding all included usage to the subscription invoice would overstate the expense.

Separate three questions:

1. What did we pay? Use invoices and adjustments for the selected period.
2. Where was usage concentrated? Examine developers, models, and workflows using the available usage records.
3. What did that expense support? Connect the measured team or repository to eligible completed work.

Record your allocation rule for subscription costs. If a developer contributes to several repositories and reliable repository-level usage is unavailable, retain a broader team-level cost view. Do not infer precise task costs from request counts alone.

Calculate cost per output without overstating attribution

A starting measure is:

Team AI cost per merged PR = eligible AI expense for the team and period / eligible PRs merged by that team in that period.

For illustration, $900 of monthly expense across 45 eligible merged PRs is $20 per PR. This is a team-level allocation, not evidence that all 45 PRs used Cursor or that any specific PR consumed $20.

Keep tool-specific contribution measures alongside that ratio. Match identities across Cursor and source control, then inspect a sample of commits and associated PRs. Mark the evidence as direct attribution, inferred association, or unknown. Deduplicate PRs touched by multiple tools when calculating total output.

Use the same rules for generated files, bot changes, abandoned PRs, and late merges across comparison periods. Track review effort, reversions, defects, and follow-up work separately. A cheaper merged PR is not necessarily better value if the maintenance burden increases.

The AI ROI measurement methodology provides shared definitions for costs, output, attribution, and quality.

A practical Cursor evaluation

Choose one team and a representative set of repositories. Document a specific decision, such as whether a broader rollout is justified or whether unused seats should be reassigned.

Capture a pre-change baseline and an observation period long enough to include review and follow-up quality signals. Compare similar task types and account for team size, project complexity, and release timing. A staggered rollout can provide a more useful comparison than a single before-and-after snapshot, although observational comparisons still have confounders.

Ask developers where Cursor helps or introduces work. Combine that feedback with adoption, cost per output, and quality evidence. Do not set targets for prompts, AI line share, or acceptance volume: those encourage activity without establishing useful outcomes.

A successful pilot should produce a reconciled cost total, documented coverage gaps, an inspectable output sample, and a decision with clear limitations. Report insufficient evidence when the sample or attribution is too weak.

Measure across tools with Weave

A team may use Cursor alongside Claude Code or Codex, so one vendor's dashboard will not describe the complete investment. Token Intelligence addresses AI usage and spending, and Code Intelligence supplies engineering output and code signals.

During a Weave evaluation, confirm which Cursor data your plan can provide, how identities are matched, and how overlapping tool contributions are handled. Request a walkthrough using your own billing period and a real merged change. That demonstrates whether the connection is useful for your decision rather than simply adding another adoption chart.