What "usage" means in Cursor
If you have ever closed Cursor after a long session and could not honestly say whether you built something or just approved a pile of agent diffs, you have already run into the ambiguity in the word "usage." It splits into three separate questions, and most tools only answer one of them cleanly. Getting the split straight first keeps you from measuring the wrong thing with great precision.
Quick Answer
To track Cursor usage, decide which question you are actually asking: editor time answers "how long was I in Cursor," AI-diff share answers "how much of this did the agent write," and shipped-output tracking answers "what did those sessions produce and keep." Because Cursor is a VS Code fork, a normal editor plugin can capture your time in it, which makes Cursor easier to measure than a terminal agent like Claude Code. The catch is that the same plugin cannot tell your keystrokes apart from a Composer diff the agent generated in one shot, so raw editor time flatters agent-heavy sessions. The number worth defending combines editor time with a git baseline and telemetry that learns what actually shipped. Below: the three layers, a comparison of the tools that cover them, and the mistakes that make Cursor usage data misleading.
The first question is time: how many minutes of your day happened inside Cursor. The second is authorship: of the code that landed, how much did the AI write versus you. The third, and the one that decides whether any of this was productive, is output: what those sessions shipped that survived review. In practice these three drift apart quickly. A short session can ship a hardened feature you steered carefully, and a long one can end with Composer's output reverted after it looked right and was not. Track a single layer and you will confidently answer a question you never meant to ask.
There is a wrinkle specific to Cursor that changes the tooling. Cursor is built on VS Code, so most editor time trackers that support VS Code also see Cursor with little or no change. That solves the visibility problem that makes terminal agents hard to track. It does not solve the attribution problem, and in the agent era the attribution problem is the one that distorts your numbers.
The three layers, and what each one sees
These layers stack rather than compete, and the interesting signal is the relationship between them, not any single number. Before the table, hold onto one idea: in Cursor, seeing the time is easy and trusting the diff is hard. Here is what each layer covers and where it goes blind.
| Layer | What it measures | Good for | Blind spot |
|---|---|---|---|
| Editor time (VS Code-style plugin, e.g. WakaTime) | Minutes and languages inside Cursor | Rough coding-hours totals, project splits | Counts agent-generated diffs as if you typed them |
| AI-diff share (git diff analysis / churn scan) | How much of the landed code the agent wrote | Spotting AI-heavy files, review load | Says nothing about time or whether work survived |
| Shipped output (git baseline + telemetry) | What the sessions produced and whether it stuck | Productivity, leverage, defensible attribution | Needs a baseline plus instrumentation, not one metric |
Layer one, time. Because Cursor is a VS Code fork, an editor plugin is the fastest way to see your Cursor hours, and for a plain "how long am I in this editor" question it is enough. This is usually where people stop, and stopping here is exactly what makes AI-heavy sessions look more impressive than they were. The plugin logs the wall-clock minutes the window was active. It has no idea that eight of those minutes were you reading a Composer diff and clicking accept.
Layer two, authorship. The moment you use Cursor's agent features, the more honest question becomes how much of the result was yours. A git diff or churn scan against your history gives you a rough read on how AI-heavy a change was, which is the same technique covered in tracking AI-generated code percentage. It is a useful cross-check and a poor clock, because a large agent diff can represent seconds of your time and a small hand-edit can follow an hour of steering.
Layer three, output. The only layer that answers the productivity question crosses your git history with real activity telemetry. The git baseline gives you the shape of what landed, the telemetry gives you the effort behind it, and a model learns the relationship between the two over time so the result is calibrated instead of assumed. This is the difference between "I was in Cursor for three hours" and "I was in Cursor for three hours, here is what shipped, and here is the share I drove." It is also the only layer that cleanly separates your work from the agent's, which is the real subject of AI versus human code attribution.
How to set this up
Most developers want this running in an afternoon, not turned into a project. Here is the honest sequence, from the cheapest signal to the most defensible.
- Point a VS Code-style time tracker at Cursor. Because Cursor is a fork, a standard editor plugin captures your time with almost no setup. Use it as a rough hours signal and nothing more. It will happily count the minutes Composer spent writing code as your minutes, so treat the total as an upper bound on effort, not a measure of it.
- Add a git baseline. Your commit history already exists and needs nothing installed, so it is the fastest way to see the shape of what landed from your Cursor sessions. Treat it as a benchmark, never as a clock. In the agent era a huge Cursor commit can be thirty seconds of accepting a Composer diff, and a one-line change can follow an hour of correcting the model, so tracking coding time from git alone will misread agent-heavy work. It is the frame, not the answer.
- Get an AI-diff read on what landed. Before you trust any hours number, look at how much of the change the agent wrote. A churn or diff scan tells you which files are AI-heavy and where your review attention should go. You will often see that the biggest diffs came from the least of your time, which is the whole reason editor time alone lies.
- Tie sessions to shipped output. Once the baseline and telemetry run together, the model calibrates time against what shipped and attributes your share of it, so you get output per unit of real effort rather than raw editor minutes. This is where usage tracking turns into something you can defend to a client or a lead, because the number is anchored to work that survived, not to how long a window was open.
Almost always, people run step one, see a big hours total, and quietly feel that it overstates the week. It does overstate it, because editor time in an agent editor counts the agent's work as yours.
Cursor versus Claude Code: why the tracking differs
If you also run terminal agents, it is worth knowing why the two need different setups, because the instinct is to treat all AI coding as one thing. Cursor and Claude Code sit on opposite sides of the same visibility line.
Cursor is an editor, so the time problem is basically solved: a VS Code-style plugin sees it. Its hard problem is authorship, because agent diffs and your keystrokes land in the same editor and look identical to a time tracker. Claude Code is the mirror image. It runs in the terminal, so editor plugins never see it and the time problem is the hard one, which is why tracking Claude Code usage leans on an editor-agnostic CLI to capture terminal sessions at all. This is why a setup that measures one well can badly miss the other. If your day mixes both, you want a layer that covers the editor and the terminal and still ties everything back to what shipped, rather than one plugin per surface.
Where DevClocked fits
If your only question is rough Cursor hours, a VS Code-style plugin already does that and you do not need anything heavier. If you just want a one-time gut check on how AI-heavy a repo has become, a diff-churn scan against your git history gets you there with no ongoing setup. And if you live in one editor and never touch terminal agents, a single editor plugin like WakaTime may be all the visibility you want. Full disclosure: I build DevClocked, and I would rather point you at the lighter tool when the question is light than pretend a profile is the answer to every version of this.
DevClocked earns its place when the question is time and output rather than raw minutes, and especially when Cursor's agent work makes authorship murky. It combines a git baseline with lightweight telemetry from an editor extension and an editor-agnostic CLI that also sees terminal and agent sessions across Cursor, Claude Code, and Codex, then learns the relationship between commit history and observed activity to produce calibrated time. That rolls up into a Leverage Score, output per unit of real effort, Work Blocks that show where the day went, and an AI-versus-human split so a big Composer diff does not read as a big personal effort. The point is not a nicer hours chart, but that your Cursor sessions become part of a record that proves what you shipped, audited to source, instead of an editor-time figure that quietly counts the agent's work as yours. That gap is the whole game: usage is a claim about activity, and shipped, attributed output is the proof underneath it.
Common mistakes when tracking Cursor usage
The most common mistake is trusting editor time in an agent editor. Because Cursor is a VS Code fork, the plugin faithfully logs every minute the window was active, including the minutes the agent was writing while you watched. That total is real, but it is not your effort, and treating it as effort inflates exactly the sessions where you did the least typing.
The second is equating a big diff with a big effort. Cursor's Composer can land hundreds of lines in one pass, and counting that as hundreds of lines of your work is how commit volume stops mapping to real work entirely. The size of the diff tells you what the agent produced, not what you did.
The third is measuring usage and calling it productivity. Time in Cursor and lines generated are activity numbers. Productivity is what that activity shipped that survived, with your share attributed, which is the framing in measuring AI coding productivity. You can have a high-usage week that shipped almost nothing that stuck, and usage-only tracking will flatter it.
