Cursor Time Tracking: What Actually Counts as Coding Time?
Hourly billing has always had a simple assumption behind it: the more time you spend working, the more work gets done. That worked reasonably well for most of the history of software development.
Cursor makes the whole thing a little less straightforward.
You might spend five minutes writing code, then ask the agent to change something, wait a few seconds for it to finish, read through the diff, reject half of it, change your prompt and run it again. You may not type much during that process, but you're still working.
That's the part traditional time tracking has trouble with. A lot of the work happening in Cursor doesn't look like "coding" in the old sense of the word.
What "coding time" means in Cursor now
A typical session in Cursor can involve several different things: writing code yourself, writing prompts, reading diffs, deciding what the AI got right or wrong, and waiting for an agent run to finish.
Take a simple refactoring task. You start an agent, wait for the changes, read through the result, spot something you don't like, explain what should change and run it again. The keyboard might be quiet for much of that time, but you're actively working on the project.
This is why keystroke-based tracking doesn't work particularly well with AI-assisted development. It can miss the time you spend reviewing or prompting.
The opposite approach has a problem too. If a tracker simply assumes that an open IDE means you're working, it will eventually count time when you're actually reading an email, making coffee or working in another application.
For Cursor, a more useful definition is active attention: you're actively engaged with the project, whether that means typing, reading a diff, writing a prompt or reviewing what an agent just produced.
Why a manual timer doesn't survive this workflow
Manual timers work reasonably well when you can clearly separate "working" from "not working". You start the timer when you begin coding and stop it when you leave.
Cursor makes that boundary much harder to see.
You start an agent run. While it's working, you read the result. Then you change the prompt and run it again. Maybe you spend a couple of minutes thinking about the approach before doing anything else.
At what point were you supposed to stop the timer?
In theory, you can keep track of all this yourself. In practice, manual timers tend to end up in one of two states: they run for much longer than the actual work, or you forget to start them in the first place.
Neither is particularly useful when you're trying to produce an invoice at the end of the month.
What should actually count as active time
A useful rule is fairly simple: the project you're working on is active, and you haven't gone idle.
That includes typing code, reading a diff, writing a prompt or deciding what to ask Cursor to do next. It doesn't require you to press a pause button every time the workflow changes.
If you switch to Slack and start answering messages, the work session should stop. If you walk away from your computer for twenty minutes, that shouldn't become twenty minutes of billable development time either.
This also makes per-project detection more important.
Imagine working on three client repositories during the same afternoon. With a manual timer, you have to remember when you switched from one project to another. With automatic tracking, the time can be assigned to the project you're actually working on.
That's a much more useful number when you eventually have to turn those hours into an invoice.
Setting it up
If you're using Cursor, JustClock installs from the Open VSX Registry. Cursor uses Open VSX for extensions rather than the VS Code Marketplace.
Once installed, the setup is straightforward: open Settings, add the API key from your JustClock account and save it.
After that, JustClock runs in the background. There's no start button to remember and no timer to pause when Cursor starts doing something differently.
The full setup, including screenshots, is available on the Cursor page.
Getting the hours back out
Tracking time is only useful if you can actually do something with the result.
JustClock lets you see time broken down by project and IDE. That's particularly useful if you work on the same client's code using Cursor, VS Code and a JetBrains IDE during the same week.
When it's time to prepare an invoice, you can export the tracked hours to XLS instead of trying to reconstruct your day from memory.
A few Cursor habits that change what ends up on the clock
The way you use Cursor can affect both your productivity and the amount of time you end up spending on a task. A few small habits make a noticeable difference.
Write project rules once instead of explaining them every time
If Cursor needs to know your stack, conventions and preferred patterns, put that information somewhere the agent can use it.
Otherwise, you can end up spending the same few minutes explaining the project over and over again. A good rules file can turn several rounds of "that's not quite what I meant" into one useful generation.
Those extra rounds are still work, and JustClock will track them. But ideally, they're rounds you won't need very often.
Know what you're trying to do before you start an agent run
There's a difference between exploring an idea with Cursor and asking it to implement something.
If you're discussing different approaches, looking at possible schemas or trying to understand an unfamiliar part of the codebase, that's perfectly normal development work.
But if you already know what you want and let the agent make a large number of speculative changes, you may end up reviewing code you'll never use.
Being clear about whether you're exploring or implementing can save quite a bit of back-and-forth.
Spend a little more time on the prompt
"Add search" is quick to type. It can also produce a lot of work you didn't actually ask for.
If you specify the field you're searching, the endpoint that should be changed and what the expected behaviour is, Cursor has a much better chance of producing something useful on the first attempt.
The few extra seconds spent writing a useful prompt are usually cheaper than reading a large diff, rejecting it and explaining the same thing again.
And all of that time is part of the development work anyway, so there's little reason to pretend otherwise.
The billing model isn't broken. Coding just looks different now.
Hourly billing doesn't really depend on who typed the code.
If you're reviewing a Cursor-generated diff, deciding what should stay, changing the implementation and guiding the agent towards the solution, you're working on the client's problem. The fact that your keyboard wasn't busy for every minute doesn't make that time disappear.
The challenge is simply tracking it accurately.
For AI-assisted development, that means measuring active work rather than keystrokes: prompting, reviewing, thinking through changes and working with the agent all need to be part of the picture.
That's what JustClock is designed to do automatically, without asking you to remember when each part of the work started and stopped.