Cursor analytics comes from two places: the team analytics dashboard in the Cursor web dashboard, and Cursor’s APIs (the Admin API, the Analytics API and the AI Code Tracking API). Together they show who is active, how many AI suggestions get accepted, and what share of committed code Cursor wrote.
This guide covers what each source shows, which Cursor plan you need for it, how AI share of committed code is calculated, how to break usage down by team, and what admins can and cannot see about prompts. It ends with where Cursor’s own reporting stops and how to see Cursor next to your other AI tools.
Worklytics measures this across your organization. See Cursor Analytics for adoption, AI fluency and impact by engineering team.
Cursor’s usage analytics dashboard is available on the Team and Enterprise plans (Cursor docs: Analytics). Admins see data for every team member. Members see their own data, plus the usage leaderboard. Data is only collected from Cursor client version 1.5 or later.
The main charts are:
On Enterprise, Conversation Insights is on by default. It classifies conversations by category, work type (such as maintenance, bug fixing or new features), complexity and specificity. Classification runs on the developer’s machine, and admins can turn the feature off in team settings (Cursor docs: Analytics).
You can filter by user, by directory group and by date (up to 10 users and 90 continuous days at a time), and download any chart as CSV.
AI share of committed code answers the question most leaders ask first: how much of the code we ship did Cursor write? Cursor records a signature for every line that Tab or Agent suggests. When the same author later commits, Cursor compares the commit’s lines with those signatures and attributes matching additions and deletions to AI. Everything else counts as "Other" (Cursor docs: Analytics).
Three details matter when you read the number:
For commit-level data, Enterprise teams can use the AI Code Tracking API. It returns each commit’s added and deleted lines split into Tab, Composer (Agent) and non-AI, plus a feed of accepted AI changes, as JSON or CSV. Cursor labels this API alpha, available on Enterprise through sales, and it only covers the git repository at the workspace root (Cursor docs: AI Code Tracking API).
If you want Cursor data in your own warehouse or BI tool, Cursor offers two APIs. Both use an API key created in the Cursor dashboard with Basic Authentication.
Admin API (Cursor docs: Admin API):
Analytics API (Enterprise only) (Cursor docs: Analytics API):
For a step-by-step walkthrough of pulling this data out, see our guide to exporting and analyzing Cursor usage data.
Cursor’s dashboard can filter by directory groups, so you can look at one group at a time (Cursor docs: Analytics). Most organizations want more than that: every department side by side, broken down by role, level, manager or location, and tracked over months rather than in 90-day windows.
That means joining Cursor’s per-user data to your HR directory. You can do it yourself by exporting from the Admin API and matching on email. Or you can use a platform that does it continuously. Worklytics connects to Cursor through the Admin API, collecting daily usage per person (activity, lines added and accepted, suggestion accepts and rejects, Tab completions, and feature usage such as chat, composer, agent, Cmd-K and Bugbot) and the per-request event feed (tokens, model and cost). It then reports adoption by team and role, aggregated at the team and department level. Worklytics requires a Cursor Team or Business plan, because individual Cursor accounts are not supported.
This is the question both admins and developers ask: can the company see what people type into Cursor? Here is what Cursor’s documentation says.
What admins can see:
What admins cannot see in Cursor’s built-in tools:
The exception: hooks. Cursor hooks are scripts that run during the agent loop. The beforeSubmitPrompt hook receives the prompt text and can block submission, and Enterprise teams can push hooks to every member from the web dashboard or through MDM (Cursor docs: Hooks). So an organization can capture prompts if it builds and deploys that logging itself. Cursor’s own guidance is to be careful: prompts may contain sensitive information, so log metadata such as who, when and which file rather than content where you can (Cursor docs: Compliance and Monitoring).
Separately, Privacy Mode controls whether code is used for model training. It is on by default for team members, and Team and Enterprise admins can enforce it so members cannot turn it off (Cursor: Privacy).
For most adoption and ROI questions, you do not need prompt content. Usage metadata (who is active, how often, which features, how much AI code ships) answers them and is far easier to roll out with your engineers’ trust.
Cursor’s built-in analytics give valuable insights into how developers interact with the tool. But when it comes to understanding AI adoption across the entire organization, there are some important gaps. Here are three big limitations to keep in mind:
Developers rarely use only one AI tool. While Cursor may be the official coding assistant, other employees might lean on ChatGPT Enterprise, Notion AI, Codex, GitHub Copilot, Claude Code or Windsurf. Each platform has its own stats, but they live in silos.
This fragmented view makes it difficult for leaders to see the bigger picture. For example, you might see strong Cursor usage in engineering, but have no visibility into how other departments are engaging with AI. Without a unified lens across tools, executives risk missing organization-wide trends, adoption patterns, and best practices.
Cursor reports on activity inside the IDE, but it does not explain the business impact. You can see an acceptance rate climb from 25% to 35%, which looks promising, but does that improvement translate into faster release cycles, fewer bugs, or happier employees?
Answering those questions requires connecting Cursor data with broader business metrics like sprint velocity, defect counts, or delivery timelines. Cursor does not perform that correlation automatically. As a result, many organizations either export the data manually and combine it with other sources or rely on external analytics platforms that integrate usage data with productivity outcomes.
For a worked example of tying an AI coding tool to outcomes, see our metrics-driven analysis of GitHub Copilot ROI.
Finally, Cursor’s analytics are designed for engineering oversight, not enterprise-wide monitoring. Compliance teams may need alerts if employees use unapproved AI tools or a centralized view of AI activity for audits. Cursor alone cannot flag off-platform usage, such as employees experimenting with ChatGPT outside approved channels, nor can it enforce AI usage policies across different systems. Companies with these requirements often turn to external solutions that track AI usage at the organizational level, rather than just within a single application.
In short, Cursor’s built-in analytics are necessary but not always sufficient for enterprise AI governance. They give excellent insight into how engineers use Cursor itself, which is great for engineering managers measuring team adoption and coding impact. But strategic decision-makers (IT leadership, HR analytics, etc.) often require a more holistic and correlated dataset: one that spans multiple tools and ties usage to outcomes like productivity, quality, or even cost savings. This is where third-party analytics platforms come into play.
Anthropic has moved in this direction too: Claude Enterprise now exposes audit logs and conversation-level access through its Compliance API, covered in our Claude Enterprise tracking guide.
Measure AI Adoption
Track whether Cursor is actually improving output, not just being installed. Privacy-first analytics across your entire engineering team.
Measure Cursor Adoption →
In conclusion, tracking how employees utilize Cursor AI (and other AI tools) is about more than just monitoring activity – it’s about understanding and maximizing the value of these tools in your organization. By carefully measuring adoption, encouraging usage through support and best practices, and leveraging platforms like Worklytics to gather meaningful insights, you can ensure that AI assistance becomes a true asset rather than a black box. The era of AI in the workplace is here, and those who manage its adoption with clarity and purpose will lead the way in productivity, innovation, and employee empowerment. Worklytics can be the partner that helps you chart this course, turning AI usage data into smarter decisions and real business value.
To see these metrics for your own teams, visit Cursor Analytics or book a demo.
Cursor analytics is the usage reporting built into Cursor for Team and Enterprise plans. The team dashboard shows active users, Agent edits, Tab completions, messages sent, a usage leaderboard and AI share of committed code. Enterprise teams can also pull the same metrics through the Analytics API.
Cursor records a signature for each line that Tab or Agent suggests, then compares those signatures with the lines in the same author's later commits. Matching lines count as AI and everything else counts as Other. The detection runs on the developer's machine and only line counts are sent to the dashboard.
Not through Cursor's built-in dashboard, APIs or audit logs, which show usage metadata and exclude prompts, agent output and generated code. Enterprise organizations can deploy Cursor hooks that receive prompt text before it is sent, so a company that sets up that logging can capture prompts. Ask your admin whether any hooks are deployed.
All users on a Cursor team can view the usage leaderboard. It lists the top users with their favorite model, chats, Tab completions accepted and Agent lines of code accepted.
Cursor's dashboard can filter by directory group, one selection at a time. To compare every team side by side over time, export per-user data from the Admin API and join it to your HR directory, or use a platform like Worklytics that does this automatically and reports at the team level.
