How coding time is counted, and why two trackers disagree

No editor plugin knows how long you worked. What it knows is that something happened: you saved a file, switched to another one, typed. Every tracker in this category turns those moments into hours on the server, and almost every disagreement between two trackers comes down to how they do it.

Beats, not durations

The plugin sends a heartbeat: a timestamp, the file, the language, the branch. At most one per file every two minutes while you are active, plus one on every save. The Claude Code plugin sends one per minute in which the session did anything, because reading code and waiting on an answer are work too.

Durations are not stored with the beats. They are computed when you open the dashboard, from the gaps between consecutive beats. That is what makes the rule below changeable after the fact: change your timeout and recent history is recomputed with it. Beats old enough to be rolled up into daily totals keep the timeout they were rolled up with.

The rule

Take each beat and the next one. If the gap between them is within your keystroke timeout, the whole gap counts. If it is longer, it counts for nothing: you walked away, and a new block of work starts at the next beat.

That is the whole rule, and it is the one WakaTime documents. The default timeout is 15 minutes.

A worked example

You code for 2 minutes, stop for 13, then code for 1 more.

• With a 15-minute timeout: 16 minutes. The 13-minute pause is shorter than the timeout, so it sits inside one continuous block. Reading a diff or thinking through a bug is work.
• With a 10-minute timeout: 3 minutes. The pause is longer than the timeout, so it splits the morning into two blocks and counts for nothing.

Same beats, same morning, five times the total. Neither answer is wrong; they answer different questions about what a pause is.

The clamping mistake

The tempting version of the rule is to cap each gap at the timeout instead of dropping it: a 40-minute lunch counts as 15. It looks conservative. It is not. Every break longer than the timeout now adds a full timeout of time that nobody worked.

Five breaks in a day make 75 phantom minutes. Inlinr used to compute time this way, and it was the reason it reported more than WakaTime on the same work. The fix was to drop long gaps entirely, everywhere the rule is applied.

Why two trackers disagree

Running two trackers side by side, expect differences from:

• Different timeouts. As the example shows, this alone can change a day by a factor of several.
• Different beat rates. A plugin that sends a beat every 30 seconds sees short sessions another one misses.
• What counts as activity. A tracker that only listens to the editor never sees an assistant running tests in a terminal; one that reads assistant transcripts does.
• Clamping instead of dropping long gaps, which inflates every day with breaks in it.

Moving from WakaTime? Imported history goes through the same rule as live data, so totals from before and after the switch are comparable. The comparison page says where each still does better.

Choosing a timeout

Inlinr offers 5, 10, 15 and 30 minutes in Settings. Shorter suits work that is mostly typing. Longer suits work that is mostly reading, reviewing or waiting on an assistant, where long quiet stretches are the job. If you bill clients from these numbers, pick one, tell the client which, and leave it alone: a total that changes because the setting did is the hardest kind to defend.