Quick Answer: To measure coding time without a timer, stop trying to remember to start one and read the activity you already produce instead. The fastest method is to group your git commits into sessions by their timestamps, which gives you a free benchmark of when you worked and roughly how long. For hours you can defend, add passive telemetry: a lightweight editor extension or an editor-agnostic CLI that records real activity as it happens, including terminal and AI-agent work. Both approaches share the same point: the measurement runs itself, so there is no stopwatch to forget.
If you have ever finished a long session and realised you never started the timer, you already know why timer-free measurement is the goal. A stopwatch only captures the time you remembered to capture, and the block you forget is almost always the one a client or your own curiosity asks about later. The good news is that you are leaving a trail the whole time you code, and that trail can be read without you babysitting anything.
Why the timer is the part that breaks
Most developers reach this question the same way: they tried a manual timer for a week, forgot it on day three, and gave up. A timer like Toggl or Clockify is accurate in theory and leaky in practice, because it depends on a human remembering to press start and stop around every interruption, every Slack message, every context switch. In practice that discipline does not survive a real working day.
A manual timer does not measure your work. It measures your memory of your work. The moment the two diverge, and they always do, the number on the timer is fiction. Passive measurement flips the problem: instead of asking you to log the work, it watches the artefacts the work leaves behind, so there is nothing to remember and nothing to forget. We dug into why hand-kept records drift in why manual timesheets are lying to you.
Three ways to measure coding time without a timer, compared
There is no single timer-free method; there are three, and they trade setup against accuracy in different ways. Before the table, the honest summary: reading git is the lowest friction and the roughest, passive telemetry is the most accurate, and the combination is what you want when the hours have to hold up. Here is how they compare.
| Method | Setup | What it reads | Accuracy | Best for |
|---|---|---|---|---|
| Git commit history | None (already in your repo) | Commit timestamps | Low to medium on its own | A free benchmark of when and roughly how long |
| Passive telemetry | A lightweight extension or one CLI | Real activity events as they happen | High | Defensible hours, terminal and AI work |
| Manual timer | Start/stop discipline | Whatever you remember to log | High if perfect, usually leaky | Almost nothing, once you have the above |
The table makes the trade-off concrete. Git costs nothing and runs itself, but it only sees the moment a commit landed, not the hour that led to it. Passive telemetry sees the work as it happens, which is why it is the accurate layer. The manual timer is the row you are trying to leave behind, and once the other two are in place there is very little reason to go back to it.
Method 1: read your git history
The reason this works at all is that git already timestamps every commit down to the second. You did not set out to track time, but you have been recording it as a side effect of committing. A session-grouping approach turns that side effect into a number.
The mechanism is simple. Sort your commits, look at the gap between each one, and treat anything closer than a threshold (30 minutes is the common default) as the same working session. A bigger gap starts a new session. Sum the sessions and you have hours, with zero setup and no plugin. This is the entire foundation of git-based time tracking, and for personal curiosity it is genuinely enough.
What it cannot see is the catch. The first commit of any session has nothing before it to measure, so the tool has to guess your ramp-up. A long stretch of reading or debugging that ends in one small commit looks like almost no time. And commit size tells you nothing about duration anymore, which is the part 2026 broke wide open. The full method, including the gap-threshold math and its error bars, is in time tracking from git commits.
Method 2: add passive telemetry
If you have ever watched an agent generate a 400-line commit in under a minute, you have seen exactly why commit data alone is not enough. The fix is to observe the work directly instead of inferring it after the fact, and to do it without a per-editor plugin for every tool you touch.
Passive telemetry records activity events as they happen: files you are editing, the terminal you are working in, the AI sessions you run. The key detail is that "no plugin" does not mean "no software at all." It means you do not need a separate plugin for VS Code, then another for your JetBrains IDE, then nothing at all for the terminal. A single editor-agnostic CLI can cover the terminal and agentic coding that plugin trackers like WakaTime miss entirely. The reasoning behind one tracker over many is in coding time tracker without an IDE plugin, and if you are weighing the plugin route, WakaTime alternatives covers where it does and does not fit.
This is what separates a benchmark from a record. Telemetry runs in the background with no start button, so it is still timer-free, but because it watches the work as it happens it captures the reading, the debugging, and the agent runs that commits alone would erase. You get accurate hours without ever touching a stopwatch.
Method 3: combine them (the one you want)
In practice, most developers who care about the number land here. Git gives you the baseline shape for free, telemetry fills the gaps the commits cannot see, and the merged timeline is far harder to argue with than either one alone. You are still not running a timer; two passive sources are doing the work.
The combination also fixes the accuracy ceiling. A commit-only estimate tops out at "roughly right" because it is reconstructing your day from after-the-fact markers. Add telemetry and you are no longer reconstructing, you are reading a record, and a model can learn how your commits relate to your real activity over time to calibrate the estimate. If you bill from this, estimating developer hours from commits walks through turning the combined view into hours you can stand behind.
Where DevClocked fits
If all you want is a rough sense of when you worked last week, you do not need a product at all. A short script over git log with a 30-minute gap rule gets you there, and for personal curiosity that is completely fine. The same holds if you work entirely heads-down in a single editor and never touch the terminal, because a single plugin tracker will see most of what you do.
DevClocked earns its place when the number has to be defensible, or when an AI agent does a lot of your typing and the commit trail stops reflecting your effort. It uses your git history as the baseline, then adds passive telemetry from a lightweight editor extension and an editor-agnostic CLI that covers terminal and agentic coding (Claude Code, Cursor, Codex), and it learns the relationship between commits and real activity to produce calibrated time. It reports leverage, meaning output per unit of effort, not just raw hours, and it separates AI-driven work from your own, so the time you show is audited to source rather than reconstructed from a log. If you would rather keep a simple manual timer and do not mind the gaps, an honest tool like Toggl does that one job well. Full disclosure: I build DevClocked, in public as @builtbysketch.
A reconstructed timeline is a claim about your work; a passively recorded one is evidence of it. When AI writes much of the code, that difference stops being academic, because both how long it took and how much you drove get harder to assert and easier to prove only if something was watching.
Common mistakes
The most common mistake is assuming "no timer" has to mean "no measurement," and then logging nothing at all. The opposite is true: the timer is the weakest part of tracking, and removing it is an upgrade, not a sacrifice. The second mistake is trusting a commit-only number as if it were exact, when the first commit of every session and every long thinking stretch is an inference, not a measurement. The third, and the most expensive, is scaling time by diff size in the AI era, where a huge commit can take seconds and a one-line fix can follow an hour of reading. Measure the work as it happens and let the commits cross-check it, never the other way around.
