Why project-level tracking is a different problem
If you have ever tried to answer "how long did this project actually take" after the fact, you already know the shape of the problem. Your memory has the big days and none of the small ones. Tracking your overall coding time answers "how much did I code this week." Project tracking has to answer a harder question, which slice of that time belongs to this repo, and it has to keep answering it across weeks where the project shares your attention with everything else you touch.
Quick Answer
To track time spent on a coding project, scope the tracking to the project instead of to yourself: define what counts as the project (usually one or two repos plus the terminal sessions that touch them), pull a free baseline from the repo's git history, then add a passive layer that attributes activity to the right project automatically. Manual timers fail here because the hard part of project tracking is attributing time on days you touch three different codebases, not measuring it. Below: the step-by-step setup, the mistakes that quietly corrupt the number, and what to do when most of the project's code was written by an AI agent in your terminal.
This is where per-person tools quietly fall over. An editor plugin can log eight active hours without telling you which project deserved them, and a manual timer depends on you re-clicking it every time you context-switch, which is exactly the moment you are least likely to remember. In practice this means the tracking method has to carry the attribution for you, and the project's own repo is the natural anchor, because every commit, branch, and working directory already declares which project it belongs to. This is why git-anchored methods beat calendar-based ones for project work. The attribution comes free.
There is also a newer wrinkle. On most projects now, a real share of the work happens in a terminal driving Claude Code, Cursor, or Codex rather than typing in an editor. That time belongs to the project just as much as hand-written code does, and most tracking setups never see it. Any method you pick in 2026 has to count agent sessions or the number will drift further from the truth the more leverage you use.
How to track time spent on a coding project, step by step
Most developers hit this need in one of three situations: billing a client for a specific build, sanity-checking an estimate mid-project, or doing an honest retro on how long something really took. The steps are the same for all three, the difference is only how defensible the final number needs to be.
- Define the project boundary before you track a minute. Decide which repos count, whether planning and code review count (they should), and whether the terminal sessions where you steer an agent count (they must). A project is rarely just one repo's editor time. Writing the boundary down takes two minutes and prevents the classic failure, where the "project total" silently means different things in week one and week six.
- Pull the free baseline from the repo's git history. Commit timestamps already sketch the project's timeline: group commits that sit close together into sessions, treat long gaps as breaks, and you get a rough per-project read with nothing installed. Estimating hours from commits walks through the method and its error bars. Treat this as scaffolding, not the answer. Commit size stopped mapping to effort once agents started writing large diffs in seconds, so the baseline drifts low exactly when the project leaned hardest on AI.
- Add a passive layer that attributes time by project automatically. This is the step that separates a real system from a guess. A telemetry tracker that watches actual activity and tags it by repo or working directory means a context switch is recorded as a context switch, with no timer to remember. If your whole day lives in one IDE, an editor plugin like WakaTime gets you partway there with per-project stats, though only inside that editor. Tracking coding time from git covers how the baseline and telemetry layers fit together, and the DevClocked vs WakaTime comparison covers where the plugin approach runs out.
- Make sure terminal and AI-agent sessions land on the right project. You will often see a week where the dashboard says the project got six hours but you know it dominated your attention, and the missing time is almost always agent sessions the tracker never saw. An editor-agnostic CLI tracker closes this gap by watching the terminal too, and because agent sessions run inside the project's directory, attribution stays automatic. Coding time tracker without an IDE plugin covers this setup in detail.
- Handle multi-project days with attribution, not discipline. A general timer like Toggl or Clockify can absolutely hold per-project totals, and for meetings, calls, and non-code work it is a reasonable supplement. As the primary system for code it asks you to be perfect at re-clicking a timer across every switch, forever. Almost always, self-reported switching data rounds toward whichever project you feel guiltier about. If you are coming from one of those tools, the Toggl comparison and the Clockify alternatives page cover the code-aware options, and Clockify alternatives for engineering teams goes deeper on the team angle.
- Reconcile weekly against your estimate. Once a week, put the tracked total next to what you predicted at that point. This is usually where the project's real shape shows up. Scaffolding and first-pass features come in fast because the agent is fast, then integrations, auth, and the last hardening 20 percent absorb everything the early weeks saved. Catching that curve mid-project is what makes tracking worth the setup. You can re-estimate while it still matters.
- Keep the record auditable, not just visible. A total in a private dashboard is a note to self. A total backed by a trail of real activity, commits, sessions, and agent work is something you can hand a client with the invoice, or point to when someone asks how long the build really took. If billing is the goal, time tracking for invoicing covers turning the record into defensible line items. The difference matters because a claimed number invites negotiation and a proven one ends it.
Common mistakes
A few habits reliably corrupt project totals, and they are worth naming because each one feels harmless in the moment. Counting only editor time is the big one now, since it silently excludes the terminal sessions where agent-driven work happens, which on some projects is most of the work. Reconstructing the total at invoice time from memory and the commit log is the second, it produces a number that rounds up on effort and still undercounts thinking time. The third is scope creep in the definition itself. The "project" starts as one repo, quietly absorbs a second service and a deploy pipeline, and the total stops meaning anything. And treating the git baseline as the final answer rather than a cross-check overweights hand-written commits over reviewed, agent-generated ones, which inverts where your actual effort went.
Where DevClocked fits
Full disclosure: I build DevClocked. If this is a weekend project with no client and no estimate to defend, a rough git-log skim at the end is enough, and nothing needs installing. DevClocked earns its place when the project total has to hold up. It measures what you and your AI agents shipped on each project, using the repo's git history as a no-plugin baseline plus telemetry from a lightweight extension and an editor-agnostic CLI that sees terminal and agent sessions, learned together into a calibrated per-project number. Attribution rides on the repo, so multi-project days sort themselves, and the result is an audited record of the project rather than a self-reported total.
