Quick Answer
The best way to track freelance developer hours is passive tracking: a git baseline that reconstructs your work history automatically, plus a lightweight telemetry layer (editor extension or CLI) that captures accurate active time, including sessions where an AI agent is doing the typing. It beats manual timers because it cannot forget, cannot be padded, and produces a record you can show a client when an invoice gets questioned. Manual timers like Toggl or Clockify still have a place when a client contract mandates them. Below: the full setup in six steps, a comparison of every method, and how to turn tracked hours into invoices clients do not argue with.
Why manual timers fail freelance developers
If you have ever ended a Friday trying to remember whether Tuesday's auth bug took two hours or four, you already know the core problem. Manual tracking depends on the one thing a developer in flow does not have: the presence of mind to press a button before and after every work block. The result is reconstructed guesswork, and it is usually wrong in both directions. You forget the 40 minutes of debugging at 11pm, and you round the distracted afternoon up to a full block.
There is a second failure that matters more in 2026. A timer measures presence, not work. With Claude, Cursor, or Codex running big chunks of the build, your billable value is no longer "hours with the editor open." An agent can generate a feature-sized diff while you review a different repo. A timer has no idea any of that happened. This is why the method question has changed: the best tracking now has to see the work itself, not just the clock.
And underneath both problems sits the trust problem. When a client questions a 32-hour invoice, a timesheet is just your own claim written in a grid. Hours you can trace back to actual commits, sessions, and shipped output are a different kind of artifact. That difference decides disputes.
What the best method depends on
Before picking tools, be honest about your situation, because the right answer shifts with it. Three questions do most of the work.
First: does your client dictate the tool? Some contracts and platforms (Upwork's screenshot tracker, an agency's Clockify workspace) leave you no choice. Use theirs for compliance and run passive tracking alongside it for your own record.
Second: do you bill hourly or fixed price? Hourly billing needs defensible numbers on every invoice. Fixed price does not, but tracked hours still tell you whether a project was profitable, which is how you learn to quote. In practice most freelancers discover their quotes were subsidising clients only after they start measuring.
Third: how much of your work happens outside one editor? If you split time between VS Code, a terminal running Claude Code, and the occasional JetBrains session, per-editor plugins will undercount you. You want tracking that follows the work, not one app.
The setup, step by step
This is the stack I run and the one I recommend to any freelancer billing for code. It takes under an hour to set up and then costs you nothing day to day.
- Make passive the default, manual the exception. Decide up front that your hours come from observation, not memory. Anything you have to remember to do daily will fail by week three. Almost always, the freelancers with clean books are the ones who removed themselves from the loop.
- Establish your git baseline. Connect your repos so your commit history becomes a reconstructed work timeline. This gives you an instant benchmark across every project, including months you never tracked. One caveat, and it is load-bearing: git alone is a benchmark, not a clock. An agent can produce a thousand-line commit in seconds, and a one-line fix can follow an hour of reading. Treat the baseline as the skeleton, then calibrate it. The mechanics are covered in how to track coding time from git.
- Add the telemetry layer for accurate time. Install a lightweight editor extension, or an editor-agnostic CLI tracker if you live in the terminal. Telemetry observes work as it happens, which makes it the accurate layer: real active time, idle gaps excluded, AI-agent sessions included. This matters because agentic coding is exactly the work a git-only view misestimates and a timer misses entirely. DevClocked's model learns the relationship between your commits and your telemetry over time, so even repos without telemetry get calibrated estimates instead of raw guesses.
- Attribute time to clients by repo. Map each repository (or org) to a client or project once, and every future work block lands in the right bucket automatically. This kills the worst freelance chore: untangling whose project Thursday belonged to. If you juggle several projects in one week, the per-project view in how to track time spent on a coding project shows how the same data splits cleanly.
- Turn work blocks into invoices. At billing time, pull the period's tracked hours per client and generate the timesheet or invoice from real data. No Friday reconstruction, no rounding rituals. If you bill for AI-heavy work, consider itemising agent time and even token costs as their own line: clients respond well to seeing the leverage they are paying for. The full billing workflow lives in developer time tracking for invoicing.
- Keep the audit trail. This is the step most freelancers skip and the one that saves you. Every billed hour should trace back to observable work: sessions, commits, output. You will often see a client query exactly one invoice in a year. Answering with a work record instead of a spreadsheet ends the conversation in one reply. Hours you assert are a claim; hours you can audit are proof, and clients can tell the difference even when they cannot articulate it.
Comparing every way to track freelance developer hours
Most freelancers try at least two of these before settling. The table below is the honest version of that journey.
| Method | Examples | Effort | Accuracy | Billing-ready | Sees AI-agent work |
|---|---|---|---|---|---|
| Manual timers | Toggl, Clockify | High (daily discipline) | Low to medium (memory-bound) | Yes, if you kept it up | No |
| Editor plugins | WakaTime | Low | Medium (per-editor gaps, idle inflation) | Partially (needs export) | Mostly no |
| Screenshot trackers | Upwork, Hubstaff | Low but invasive | Medium (presence, not output) | Yes (platform-locked) | No |
| Git estimation alone | Scripts, git-hours | None | Low to medium (benchmark only) | Risky on its own | Distorted by big AI diffs |
| Git baseline + telemetry | DevClocked | Low (one-time setup) | High (calibrated active time) | Yes | Yes, first-class |
If you are comparing the manual tools directly, the head-to-heads at DevClocked vs Toggl and DevClocked vs Clockify go feature by feature, and DevClocked vs WakaTime covers the plugin route. For a rough retroactive number on a project you never tracked, estimating developer hours from commits shows what git alone can and cannot tell you.
Where DevClocked fits
Full disclosure: I build DevClocked, so weigh this paragraph accordingly. If your client requires their own tracker, use theirs; fighting a contract over tooling is never worth it. If you only ever bill fixed price and never need to defend a number, a simple timer, or nothing at all, may be plenty. DevClocked wins when you bill for code and want the hours to defend themselves: it builds the git baseline automatically, adds telemetry for calibrated active time (including Claude Code, Cursor, and other agent sessions, with token and cost tracking), splits time by client repo, and generates timesheets and invoices from hours that are audited to source. The same record doubles as a public proof-of-work profile, which has a way of turning one finished contract into the next one.
Common mistakes to avoid
A few failure patterns come up so often they are worth naming before you hit them.
- Billing raw git estimates. Commit timestamps are a benchmark, not a clock, and in the AI era the gap between diff size and time is enormous. Calibrate with telemetry before a number touches an invoice. The long version of this argument is in why manual timesheets lie, which cuts both ways: manual and naive-git tracking both drift from reality.
- Tracking only inside one editor. Terminal sessions, agent runs, and code review are billable work. Per-editor plugins miss them; editor-agnostic telemetry does not.
- Not billing for AI-agent time. You supervised the agent, reviewed its output, and own the result. Discounting that work to zero because "the AI did it" misprices your leverage. Track it, show it, bill it.
- Starting to track after the dispute. The audit trail only protects you if it existed before the question. This is usually the point where freelancers adopt passive tracking; the cheaper version is doing it one project earlier.
