The most common question I get from developers who start tracking their time is: "I thought I coded for six hours today. Where did it go?"
The answer is almost always the same. You opened VS Code at 9 AM and closed it at 5 PM. But between those two timestamps were three standups, a code review, two Slack threads that ran long, lunch, and the 20-minute lag every time you switched contexts. Active coding time was somewhere between two and four hours. The rest was everything else.
VS Code time tracking solves the first part of that problem. It tells you how much of your editor time was genuinely active — keystrokes, file saves, code edits — versus VS Code sitting open in the background while you did something else. Here is how it works, what tools do it well, and what to do with the data.
How VS Code Time Tracking Works
The mechanism behind automatic editor tracking is the heartbeat. Every time you make a keystroke, save a file, or switch between files in VS Code, the tracker records a heartbeat: a small event with a timestamp, the file you were working in, the project directory, and the language detected from the file extension.
At the end of a session, the tracker aggregates those heartbeats into active time. If heartbeats come in at least once every two minutes, the interval between them counts as active coding. A gap longer than two minutes is treated as idle. You stopped typing, maybe switched to a browser, maybe stepped away. The timer pauses.
This is meaningfully different from "VS Code was open." A lot of tools, including macOS Screen Time and many general time trackers, measure window focus time. VS Code focused = coding. But VS Code focused while you stared at a diff for 15 minutes without touching the keyboard is not the same as VS Code focused while you were actively writing code. Heartbeats distinguish between them.
WakaTime: The Standard
WakaTime is the established solution for VS Code time tracking. The setup takes about 90 seconds: install the extension, paste your API key, and it starts recording immediately. No manual timers. No start/stop.
What you get:
- Coding time broken down by project, language, file, and branch
- A daily goal tracker with a configurable target (8 hours, 4 hours, whatever)
- A leaderboard if you want to compare yourself against other WakaTime users
- Integrations with Wakatime's API for pulling data into your own dashboards
WakaTime's free tier gives you the last 14 days of data. The pro plan ($9/month or $72/year) gives you full history, team features, and API access.
The limitation is the boundary of the editor. WakaTime records exactly what happens inside VS Code. The moment you switch to a browser, join a Zoom call, or write a doc in Notion, WakaTime pauses. It does not know you spent 45 minutes on a code review in GitHub. It does not know your three-hour morning included a two-hour meeting. It gives you accurate editor time, which is a valuable signal. But it gives you only that signal.
xeve's VS Code Extension
xeve has a VS Code extension that works on the same heartbeat principle. Install the extension from the marketplace, log in with your xeve account, and it starts sending heartbeats. You get coding time by project, language, and file, with the same two-minute idle detection.
The difference is what happens to that data. xeve combines VS Code heartbeats with system-level app tracking from the native Mac or Windows tracker. So when I look at a Monday in my dashboard, I see that I was in VS Code for four hours and seventeen minutes, actively coding. I also see that I spent 38 minutes in Slack, 52 minutes in Safari (broken down by domain), 18 minutes in Figma, and that there were two periods where nothing was active for more than 15 minutes, which were probably meetings.
That combination is what tells me where a day actually went. The VS Code extension answers "how much did I code." The system tracker answers "what else did I do." Together they give you a complete picture of an eight-hour day that 90% of people could not reconstruct from memory.
xeve also connects to GitHub, so VS Code coding time is correlated with actual commit and PR activity. High coding hours that produce no GitHub output are a signal — you were debugging something, or exploring, or stuck. High commit output on low editor hours sometimes means you were mostly reviewing and merging agent work.
Claude Code and Terminal Time
One thing neither WakaTime nor any editor extension tracks: the time you spend using Claude Code or working in the terminal.
When you are using Claude Code to write or review code, you are not necessarily typing in VS Code. You might be reading Claude's output, editing files it produced, running tests, directing the agent through a long session. That is coding work. It just does not show up in VS Code heartbeats because VS Code is not the active window.
xeve includes a Claude Code hook that tracks active sessions with the AI coding tool, and the system tracker captures terminal time separately. This matters more than it used to. In 2025, many developers spend as much productive time with Claude Code or Cursor as they do writing code directly in an editor. A tracker that only sees VS Code is increasingly undercounting real work.
What the Numbers Actually Show
After three months of tracking:
My VS Code active coding time averaged 2h 47m per day. My total productive screen time (VS Code + terminal + Claude Code + GitHub) averaged 5h 12m. My perceived coding time — what I would have said if you asked me at the end of the day — was closer to six hours.
The gap is consistent with what xeve's data shows across users. Active editor time is typically 40-60% of productive screen time. The rest is communication tools, code review, documentation, and increasingly AI coding tools that live outside the traditional editor.
None of this makes the 2h 47m figure discouraging. Knowing that it is accurate and consistent is useful in ways that gut estimates are not. When I have a day where VS Code time drops to under two hours, I now know it immediately rather than discovering it during a retrospective three weeks later. When a new project or a new AI workflow changes that split, I see it in the data.
Setting Up VS Code Time Tracking
For WakaTime: install the "WakaTime" extension in VS Code, create an account at wakatime.com, and paste your API key when prompted. Data starts appearing in your dashboard within minutes.
For xeve: install the "xeve" extension from the VS Code marketplace, sign in with your account, and the extension connects automatically. Coding data appears in your xeve dashboard under the Coding section alongside your system-level app data.
Both work on macOS and Windows. Both require no configuration beyond authentication.
The practical difference: if your goal is measuring coding time in isolation — for billing, for a coding habit, for personal curiosity about your editor sessions — WakaTime is simple and focused. If you want to understand your full workday — what you actually do across every app, how coding time relates to meetings and communication, how your VS Code sessions map to actual output — you need the system-level picture alongside the editor data.
The One-Number Summary
Knowing your VS Code coding time is more useful than not knowing it. The average developer significantly overestimates their active coding time, and having accurate numbers changes how you think about your day and your capacity.
But VS Code time is one number in a picture that takes more numbers to describe. The developers who get the most out of tracking are the ones who can see how editor time fits into the rest of the day — not just that they coded for three hours, but that those three hours came after a two-hour morning of meetings, that the afternoon block was longer and higher-output, and that Tuesdays consistently look different from Thursdays. That context is what turns a number into something you can act on.