Vim Time Tracking: How to Track Coding Time in Vim and Neovim (2026)

What a Vim time tracker can and cannot see

Before you drop a plugin into your config, it is worth being precise about what a tool living inside Vim is watching, because that boundary decides how accurate your number will be. A Vim time tracker hooks into editor events: buffer focus, insert-mode keystrokes, the file type you are editing, and how long since your last motion. That is genuinely useful, and it is passive, which already beats a stopwatch you forget to start when you drop into a buffer at 9am.

The boundary is the Vim process itself, and Vim is unusual here. Most editors are a window you leave to do everything else. Vim is often one pane in a terminal where the rest of the work is happening right next to it. You have ever built this exact setup: Vim in one tmux split, a shell running tests in another, an agent streaming a diff in a third. A Vim tracker counts only the first pane as coding time. From its point of view, the moment you hit the shell split to run a migration or talk to an agent, you went idle. Editor-based tracking in a terminal workflow measures buffer activity, which for Vim users is a smaller slice of the real day than it is for almost anyone else, because so much of the job lives one pane over.

The four ways to track time in Vim and Neovim

There are really four routes, and they differ in what they see and how much you have to trust them. Here they are side by side before we go deep, so the trade-offs are visible up front.

The shape of that table is the lesson. The two methods that install into Vim see the least of a terminal-heavy day, and the method that sees the whole day is a CLI that is not tied to the editor at all, which for a Vim user is the least foreign option on the list. There is no route that reads your true hours from nothing. Below, each one in turn.

Route 1: vim-wakatime (the fast passive path)

Most people who want tracking without babysitting a timer start here, and it is a reasonable place to start. You add vim-wakatime through your plugin manager, paste an API key, and from then on it records your editing passively across Vim and Neovim. If you have ever wanted to know which languages ate your week or how long a project kept you in a buffer, this is where those charts come from, with no change to how you work.

The limitation is coverage, and for Vim it bites harder than for a GUI editor. The plugin sees editor events and only those, so a day spent mostly in shell splits driving builds and agents reads as light editing. It also does not travel: the tracking follows the buffer, not the work, so the hour you spent in a tmux pane running aider is invisible. This is exactly why the "no plugin" search intent exists, and the phrase is worth being precise about. A coding time tracker without an IDE plugin means one editor-agnostic tracker instead of a per-editor plugin, or a git baseline that needs nothing installed, rather than no software at all. If you are weighing the plugin category itself, the best WakaTime alternatives lay out the options, and the DevClocked vs WakaTime comparison covers where an editor plugin stops being enough. There is also a WakaTime alternative page if you have already decided to switch.

Route 2: DIY autocmds or a self-hosted watcher (the tinkerer route)

Vim users are the crowd most likely to want to build this themselves, and Vim makes it temptingly easy to start. You can wire autocmd hooks in your vimrc on events like InsertEnter, CursorHold, and BufWritePost to append timestamps to a log file, then total them with a script later. If you would rather not maintain that, a self-hosted watcher such as the ActivityWatch Vim extension does a similar job and keeps the data on your own machine, which appeals if you dislike sending activity to a hosted service.

The limitation is that you are still only watching Vim, and now you also own the maintenance. Almost always, the hand-rolled version undercounts or double-counts in ways you only notice weeks later, because idle detection and pane focus are genuinely fiddly to get right. The hard part of time tracking was never capturing keystrokes. It was deciding what counts as work and stitching the whole environment together, and a buffer-scoped logger solves only the easy half. It is a fun weekend project and a poor source of numbers you would put in front of a client.

Route 3: git-based inference (zero setup)

If dropping anything into your config feels like friction, the appealing idea is to skip the editor entirely and read your time from git, since the commits are already sitting in the repo. You can get a real baseline this way, and it works identically whether you commit from inside Vim or from the shell split next to it. A good git-based estimate does not count commits, because a commit can represent five seconds or five hours. It reconstructs sessions by grouping commits that sit close together in time and treating long quiet gaps as breaks, then estimates elapsed time from the shape of that activity.

Most "track time from git" advice skips the limitation that lands especially hard on a Vim workflow full of AI: git records output, not effort, and in 2026 those two have come apart. An agent generates a huge diff in seconds, so a large commit can represent almost no time, while a one-line fix can follow an hour of debugging across three tmux panes. The thing git can see, the size and timing of the diff, no longer maps cleanly to the thing you want, which is time spent. Treat git as a strong benchmark and a cross-check, never as an accurate clock. Tracking coding time from git goes deeper on getting the most out of the baseline without over-trusting it.

Route 4: telemetry from an editor-agnostic CLI (the accurate path)

If a plugin measures the buffer, a DIY logger measures the events you remembered to hook, and git infers time after the fact from output, telemetry measures the work while it happens across your whole terminal, which is the only way to get an honest number for a Vim workflow. Telemetry here means lightweight activity signals captured as you work: editing in Vim, yes, but also the shell splits, the tmux panes, and the agentic coding sessions running beside your buffer. Because it observes the work directly rather than the editor window alone, it catches the hour you spent in a build-and-debug loop and the agent run that produced a giant commit in two minutes, precisely the cases where a plugin, a DIY logger, and a git estimate all get it wrong.

This is what makes a Vim time total trustworthy, and there is a nice fit here that GUI-editor users do not get. You already live in the terminal, so an editor-agnostic CLI tracker is one more process in the environment you already run everything from. In practice this means the tracker sees the same surface you work on, instead of the narrow slice a buffer plugin can reach. The cost is that telemetry needs that small tracker running. That is the trade across the whole table: a little software watching, in exchange for hours you do not have to reconstruct or defend from memory. If you also spend time in a GUI editor, the same logic carries over, which is what VS Code time tracking and JetBrains time tracking walk through, and an editor-agnostic tracker is what lets one number span all of them.

How to pick a route for your situation

The right choice is rarely one route, it is usually a small stack, and it depends on why you are tracking at all. Most Vim developers land in one of a few situations, so match yourself to the closest.

If you want a sense of your editing habits with the least effort, vim-wakatime is fine, as long as you remember it is undercounting every pane that is not the buffer. If you love tinkering and only want data for yourself, a DIY autocmd logger or a self-hosted watcher scratches that itch, though you should not treat its totals as authoritative. If you build heavily with AI through a CLI agent, an editor-only tracker will undercount you badly, because so much happens in the shell and in agent sessions the plugin never sees, and git will misread the diffs, so telemetry is doing the real work. And if you want a rough number with zero setup, the git baseline is a reasonable starting point as long as you treat it as approximate and expect it to drift the more you lean on AI. The pattern across all of these: the more your hours need to survive someone else's scrutiny, the more you want measured activity rather than a partial or self-reported figure.

Common mistakes

A few errors show up constantly with Vim tracking, and they are easy to avoid once named. The most common is assuming the plugin's total is your real coding time, when it is only your in-buffer time, so a terminal-heavy day looks lazy on the chart. The second is over-investing in a hand-rolled logger and then quietly trusting numbers that were never validated, because the setup felt authoritative once it ran. The third is trusting commit volume as a proxy for effort, which was shaky before AI and is now wrong. The fourth, and the one that quietly matters most, is treating any of these numbers as proof when they are really claims. A plugin heatmap, a homemade log, or a padded commit graph proves nothing to a client or an employer on its own. The fix in every case is the same move: measure the work as it happens across the whole terminal, and keep the record, rather than reconstruct a partial view later and ask people to take your word.

Where DevClocked fits

Full disclosure: I build DevClocked, so treat this as the honest placement, not a verdict. DevClocked leads with leverage and output, measuring what you and your AI coding agents shipped, not just keystrokes in one buffer. The mechanism is the combination this guide keeps pointing at: a git baseline that needs no editor plugin, plus telemetry from an editor-agnostic CLI that covers the shell splits and agent sessions Vim plugins miss, with a model that learns the relationship between your commits and your measured activity so the estimate calibrates over time. For a terminal-native workflow this is a natural fit, because the CLI lives where you already work.

Be honest about when it is not the answer. If all you want is a per-language heatmap of your editing and your day really does live inside the buffer, vim-wakatime is less to think about and does that job well. If you enjoy owning your stack and only need local numbers for yourself, a self-hosted watcher keeps everything on your machine. If you refuse to run any tracker at all, you are left with the git baseline alone, and you should treat it as approximate. DevClocked earns its place when your work is code, a real share of it happens in the terminal and in agents rather than the buffer, and you want an accurate measure that doubles as a record you can stand behind. A developer dashboard is where those hours turn into something you can read and show.

Related Guides

• Developer time tracking: the complete guide: the four methods to track coding time and how to pick, in depth.
• Coding time tracker without an IDE plugin: what "no plugin" really means and the editor-agnostic option.
• VS Code time tracking: the same routes and trade-offs for the most common GUI editor.
• JetBrains time tracking: the built-in timer, plugins, git, and telemetry for IntelliJ and its IDEs.
• Track coding time from git: how the git baseline works and why it is a benchmark, not a clock.
• Best WakaTime alternatives: the ranked comparison if the plugin route is not covering your work.
• Developer dashboard: turning tracked hours into something you can read and show.