Quick answer
Cursor's admin console reports usage per member for team plans. It shows included usage and on-demand spend, not per-prompt detail. For project-level attribution, each developer runs a local tracker and shares aggregate exports rather than raw sessions.
Where the numbers come from
| Question | Source | Granularity |
|---|---|---|
| Who has a seat? | Admin console | Per member |
| Who used the allowance? | Usage report | Per member, daily |
| What did we pay? | Billing | Per organization |
| Which project cost most? | Local session data | Per repository |
Collect without surveillance
- Agree the fields: usage, model, project, date.
- Export aggregates, not chat transcripts.
- Set a retention period.
- Report by team before reporting by person.
- Give developers their own numbers first.
Interpret carefully
- A high number can mean hard work or a retry loop.
- A low number can mean efficiency or disuse.
- Compare the same task type across members.
- Use the data to size plans, not to rank people.
UsageAtlas runs per machine and keeps Cursor usage beside the developer's other tools, which makes the local export useful without collecting prompts.
Collect aggregates, not transcripts
Per-developer reporting invites overreach. The fields you need are tokens or requests, model, project, and date. Prompt content adds nothing to a cost review and a lot of risk.
- Agree the fields and the retention period in writing.
- Export aggregates from the admin console.
- Add local project detail only where sessions allow it.
- Report team totals before individual totals.
- Give each developer their own numbers first.
UsageAtlas runs on each machine and keeps the data local unless sync is enabled. See expense tracking.
Questions, answered
Can admins see per-developer Cursor usage?
Yes, on team plans. The admin console reports per-member usage and spend for the billing period.
Can admins see prompts?
No. Reporting covers usage and billing metrics, not conversation content.
How do we compare Cursor with Codex per developer?
Use a local tracker on each machine and compare cost per completed task, not raw request counts.
