Developers
Time tracking for developers, without a commit-hook ritual
Nobody has ever sustainably tracked their time by remembering to run a command. The tracking has to be something that happens to you, not something you do.
In short
Time tracking for developers works best when it captures editor, terminal and browser activity automatically rather than depending on a command, a plugin or a commit hook. The result is a timeline showing how a day split across projects and how much of it was continuous work rather than interruption, which is the number that explains a slow week.
- No plugin required
- Any editor
- Read your hours from your AI client
- MCP
- Local first, syncs after
- Offline
- Idle threshold
- 30 s
Commits are not hours
The developer-specific version of time tracking usually starts with the repository, because the repository is where the evidence appears to live. It does not survive contact with a real week.
A commit says something was finished. It says nothing about the two hours of reading that preceded it, the hour lost to an environment that would not build, the review you did on someone else's branch, or the afternoon in a document deciding what to build. On a bad week the commits look thin and the work was hard, which is precisely the week you most need an honest record of.
Capturing at the operating system level gets all of it: the editor, the terminal, the browser tabs that were documentation, the meeting client. No plugin per tool, no hook to install, nothing to keep working when you change editors.
What it gives a developer specifically
- Where the day actually went
- Editor against terminal against browser against meetings, per project. Most people are surprised by this the first week, usually by how little of the day was in the editor.
- Fragmentation, not just totals
- Six hours in one-hour blocks and six hours in ten-minute blocks are the same total and completely different days. The timeline shows which one you had.
- Contract hours you can hand over
- If you bill a client for development time, the evidence trail behind each entry is the thing that makes an invoice easy to approve.
- Your hours, inside your AI client
- Stunda hosts an MCP endpoint, so Claude Code, Claude Desktop, Cursor, Codex and VS Code can query your tracked time directly. Read tools are annotated read-only so your client can auto-approve them.
It counts keystrokes and cannot read them
Worth being precise about, for an audience that will ask. On macOS the keystroke count comes from a system call that returns a running total of input events, so there is no code path in which characters are available. On Windows it samples key state rather than installing a low-level keyboard hook, which is the mechanism a keylogger uses and which we avoid on purpose.
Window titles and browser hosts are optional and sit behind an operating system permission. When they are on, query strings and fragments are stripped before storage, so tokens in URLs never arrive.
Questions
What is the best time tracker for developers?
One that captures at the operating system level rather than through a per-editor plugin, so it keeps working when you switch tools and covers the terminal, the browser and meetings as well as the editor.
Does it need a plugin for my editor?
No. It reads which application and window has focus from the operating system, so any editor, terminal or browser is covered without an extension.
Can I query my tracked time from Claude or Cursor?
Yes. Stunda hosts an MCP endpoint that Claude Code, Claude Desktop, Cursor, Codex and VS Code can connect to with a personal access token you create and revoke yourself. It is available on every plan including Free.
Does it track time spent in code review or documentation?
Yes, because it captures at the window level rather than from commits. Reading, reviewing and writing documentation are ordinary tracked activity rather than gaps.
Does it work offline?
Yes. Sessions are written to a local database first and synced afterwards, so a dropped connection or a flight does not lose work.