What Cursor time tracking can and cannot see
Before you install anything, it helps to be precise about what a tracker bolted into Cursor is watching, because that boundary decides how accurate your number is. A Cursor time tracker sees the editor window: which file is focused, when the window is active, and often which language and project you are in. That is genuinely useful, it is passive, and because Cursor is built on VS Code, the tooling you already know works here with little or no change.
Quick Answer
To track time in Cursor, install a passive editor extension like WakaTime and it will record your active editing without a timer, because Cursor is a VS Code fork and most VS Code trackers run in it unchanged. That is the fastest setup and, for a rough hours total, it is enough. The catch in Cursor is that the plugin cannot tell your keystrokes apart from a Composer diff the agent wrote in one shot, so it happily logs the minutes you spent reading and approving AI output as your coding time. It also misses the terminal and any agent you drive from the command line. So the honest answer has two layers. If you want a quick heatmap of your editing, a plugin works. If you want hours you can trust and stand behind, including agent work attributed correctly, you want telemetry from an editor-agnostic tracker with a git baseline as a cross-check. This guide covers all three routes, what each captures in an agent editor, and how to pick.
The boundary that bites is authorship, not the editor frame. Most developers hit this the first time they check a plugin's dashboard after a long agent session and the total looks suspiciously high. Cursor's Composer and chat can land a hundred lines in one pass while you read and click accept, and to a time tracker those minutes look identical to minutes you spent typing. The plugin gets the wall clock right and the authorship wrong. Tracking an agent editor measures window-active time, and in Cursor a growing share of that time is you supervising the model, not writing code.
There is a second, smaller boundary that carries over from any editor tracker. Anything you run outside Cursor, a build in an external terminal, a command-line agent, a task in another tool, does not register. If you have ever driven a job from the terminal beside Cursor and watched the plugin count none of it, that is the frame doing its job, which is only watching the editor.
The three ways to track time in Cursor
There are really three routes, and in an agent editor they differ less in what they can see and more in whether they can tell your effort from the agent's. Here they are side by side before we go deep on each, so the trade-offs are visible up front.
| Method | What it captures in Cursor | What it misses | Setup | Best for |
|---|---|---|---|---|
| Editor extension (e.g. WakaTime) | Active window time, per-language and per-file | Terminal, external agents; counts Composer diffs as your typing | Install extension, add API key | A quick heatmap of your editing habits |
| Git-based inference | Sessions reconstructed from commit timestamps | Effort behind small commits; badly misreads big agent diffs | Nothing installed in the editor | An approximate baseline with zero setup |
| Telemetry (editor-agnostic tracker) | Real activity across editor, terminal, and agent, with attribution | Nothing structural; needs a tracker running | Install a lightweight extension or CLI | Accurate hours you can prove |
The shape of that table is the lesson. The method that installs cleanest into Cursor is also the one most flattered by agent work, and the method that separates your effort from the model's needs a tracker that watches activity directly. There is no option that reads your true hours from nothing. Below, each route in turn.
Route 1: a Cursor extension (the fast path)
Most people start here, and it is a reasonable place to start. You install an extension like WakaTime from the marketplace, paste an API key, and from then on it records your editing passively. If you have ever wanted to know which languages ate your week or how long a project has kept you in Cursor, this is where those charts come from, with no behaviour change on your part.
The limitation is authorship, and it is sharper in Cursor than in plain VS Code. The extension logs the window-active minutes and cannot see that eight of them were you watching Composer write a diff. An agent-heavy week can look more impressive than it was because the plugin credits the agent's output to your clock. Treat the plugin total as an upper bound on effort, not a measure of it. It also does not travel, so a task you run in the terminal or in a command-line agent stays invisible. This is exactly why the "no plugin" intent exists, and the phrase is worth pinning down. A coding time tracker without an IDE plugin means one editor-agnostic tracker instead of one plugin per editor, or a git baseline that needs nothing installed, rather than no software at all. If you are weighing the plugin category itself, the best WakaTime alternatives lay out the options, and the DevClocked vs WakaTime comparison covers where an editor plugin stops being enough in an agent workflow.
Route 2: git-based inference (zero setup)
If installing an extension feels like too much, the appealing idea is to skip the editor and read your time from git, since the commits are already sitting in the repo. You can get a real baseline this way. A good git-based estimate does not count commits, because a commit can represent five seconds or five hours. It reconstructs sessions by grouping commits that sit close together in time, treats long quiet gaps as breaks, and estimates elapsed time from the shape of that activity.
Git records output, not effort, and Cursor's whole point is generating a lot of output fast. That is the limitation that hits Cursor work hardest of all. Composer lands a huge diff in seconds, so a large commit can represent almost none of your time, while a one-line fix can follow an hour of correcting the model. The thing git can see, the size and timing of the diff, no longer maps to the thing you want, which is time you spent, and an agent editor is precisely where that gap is widest. Treat git as a strong benchmark and a cross-check, never as an accurate clock. Tracking coding time from git goes deeper on getting the most out of the baseline without over-trusting it.
Route 3: telemetry from an editor-agnostic tracker (the accurate path)
If a plugin measures the window and git infers time after the fact from output, telemetry measures the work while it happens and, in Cursor, can tell your activity apart from the agent's. Telemetry here means lightweight activity signals captured as you work: active editing in Cursor, yes, but also terminal sessions and agent sessions, along with the signal of when a change was your keystrokes versus a generated diff. Because it observes the work directly rather than the window alone, it catches the hour you spent steering the model and refuses to credit you for the two minutes Composer spent typing.
This is what makes a Cursor time total trustworthy. In an editor where code is cheap to generate and a real share of a session is supervision rather than authorship, watching the activity and attributing it is the only reliable measure. The cost is that telemetry needs a small tracker running, either a lightweight editor extension or an editor-agnostic CLI that also covers terminal and agent work. That is the trade across the whole table: a little software watching, in exchange for hours you do not have to reconstruct or defend from memory. Because Cursor sits next to terminal agents like Claude Code in most real workflows, the same tracker covering both surfaces is what makes the number whole, and tracking Cursor usage walks through the attribution layer in detail.
How to pick a route for your situation
The right choice is rarely one route, it is usually a small stack, and it depends on why you are tracking at all. Most Cursor developers land in one of a few situations, so match yourself to the closest.
If you want a sense of your editing habits with the least effort, a plugin is fine, as long as you remember it is crediting the agent's diffs to your clock. If you bill clients, a plugin alone is risky, because the inflated hours are ones you cannot honestly stand behind and the terminal hours it misses are ones you lose, so you want passive capture across the whole environment plus a record you can show. If you build heavily with Cursor's agent, an editor-only plugin will overstate your effort on exactly the sessions where you typed least, and git will misread the diffs, so telemetry with attribution is doing the real work. And if you want a rough number with zero setup, the git baseline is a reasonable starting point as long as you treat it as approximate and expect it to drift the more the agent writes. The pattern across all of these: the more your hours need to survive someone else's scrutiny, the more you want measured, attributed activity rather than a partial or flattered figure.
Common mistakes
A few errors show up constantly with Cursor tracking, and they are easy to avoid once named. The most common is assuming the plugin's total is your real coding time, when in an agent editor it counts the model's writing as yours, so a supervise-heavy day looks like a marathon of typing. The second is installing a tracker in Cursor and nowhere else, then wondering why the numbers drop whenever you work in the terminal or another tool. The third is trusting commit volume as a proxy for effort, which was shaky before agents and, with Composer landing hundreds of lines at once, is now wrong. The fourth, and the one that quietly matters most, is treating any of these numbers as proof when they are really claims. A padded plugin heatmap or an agent-inflated commit graph proves nothing to a client or an employer on its own. The fix in every case is the same move: measure the work as it happens across the whole environment and attribute it, then keep the record, rather than reconstruct a flattered view later and ask people to take your word.
Where DevClocked fits
Full disclosure: I build DevClocked, so treat this as the honest placement, not a verdict. DevClocked leads with leverage and output, measuring what you and your AI coding agents shipped, not just minutes the Cursor window was open. The mechanism is the combination this guide keeps pointing at: a git baseline that needs no per-editor plugin, plus telemetry from a lightweight extension and an editor-agnostic CLI that covers the terminal and agent sessions a Cursor plugin misses, with a model that learns the relationship between your commits and your measured activity so the estimate calibrates over 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.
Be honest about when it is not the answer. If all you want is a per-language heatmap of your Cursor editing and you never leave the editor, a plain plugin is less to think about and does that job well. If you want your entire non-coding workday tracked, a general tracker like RescueTime fits better, and WakaTime vs RescueTime covers that split. If you refuse to install any tracker at all, you are left with the git baseline alone, and you should treat it as approximate, more so the more the agent writes. DevClocked earns its place when your work is code, a real share of a Cursor session is you steering the agent rather than typing, and you want an accurate measure that doubles as a record you can stand behind. A developer dashboard is where those hours turn into something you can read and show.
Related Guides
- Developer time tracking: the complete guide: the four methods to track coding time and how to pick, in depth.
- VS Code time tracking: the same three routes for the editor Cursor is forked from.
- Track Cursor usage: the attribution layer, AI-diff share, and shipped output for agent sessions.
- Coding time tracker without an IDE plugin: what "no plugin" really means and the editor-agnostic option.
- Track coding time from git: how the git baseline works and why it is a benchmark, not a clock.
- Developer dashboard: turning tracked hours into something you can read and show.
