What "usage" means here
If you have ever finished a heavy Claude Code session and wondered whether that was two hours of real progress or two hours of watching an agent churn, you have already hit the ambiguity in the word "usage." It splits into three different questions, and the tool you choose only answers one of them well. Getting this straight first saves you from tracking the wrong thing precisely.
Quick Answer
To track Claude Code usage, pick the layer that matches your question: token and cost logs answer "what did the agent spend," session timing answers "how long was I in an agent loop," and shipped-output tracking answers "what did those sessions produce." Most people reach for token counts because Claude Code surfaces them, but tokens are the input side and tell you nothing about whether the work was kept. It works best to combine a session-time signal from an editor-agnostic CLI tracker with a git baseline, so the terminal sessions where Claude Code lives get counted as real work and tied to what shipped. Below: the three tracking layers, a comparison of the tools that cover them, and the mistakes that make Claude Code usage numbers meaningless.
The first question is cost: how many tokens did the agent consume and what did that run you. The second is time: how much of your working day happened inside an agent loop in the terminal rather than in your editor. The third, and the one that matters for productivity, is output: what those sessions shipped that survived. In practice these three drift apart fast. A cheap session can ship a hardened integration, and an expensive one can end with everything reverted. Track only one layer and you will confidently answer a question you did not mean to ask.
There is a structural reason this is harder for Claude Code than for a normal editor. Claude Code runs in the terminal as an agent, so the per-editor plugins that most time trackers depend on never see it. This is usually the point where developers assume the work is untrackable and fall back to guessing. It is trackable, but you have to instrument the terminal and the git history rather than the editor pane.
The three layers, and what each one sees
Before the table, the thing to hold onto is that these layers stack rather than compete. You can track all three, and the interesting number is the relationship between them. Here is what each covers and where it goes blind.
| Layer | What it measures | Good for | Blind spot |
|---|---|---|---|
| Token and cost logs (built-in, or a tool like Tokscale) | Tokens generated and dollars spent per agent session | Budget control, spotting runaway sessions | Says nothing about time, kept work, or the human share |
| Session time (editor-agnostic CLI tracker) | Real minutes spent in terminal and agent loops | Counting agent work as work, honest time totals | Does not know if the session shipped anything |
| Shipped output (git baseline + telemetry) | What the sessions produced and whether it survived | Productivity, leverage, defensible attribution | Needs a baseline plus instrumentation, not one number |
Layer one, cost. Claude Code reports token usage inside the session, and that is the fastest signal to reach for. For pure budget questions, a dedicated agent-cost tracker built for this does the job cleanly and DevClocked would be overkill. The trap is treating cost as a productivity proxy. High token burn very often correlates with thrashing, the agent and you circling the same problem, which means the sessions that cost the most are frequently the ones you should worry about, not celebrate.
Layer two, time. Because Claude Code lives in the terminal, the way to capture its time is an editor-agnostic CLI tracker that watches activity events across the shell and agent sessions rather than hooking into one editor. This is the layer most people skip, and skipping it is why so many "coding hours" dashboards undercount anyone who has moved real work into agents. If your day is increasingly Claude Code and Codex in a terminal, an editor-only tracker will quietly report that you barely worked. A coding time tracker that does not need an IDE plugin is the piece that fixes this.
Layer three, output. The only layer that answers the productivity question crosses your git history with that session telemetry. A git baseline gives you the shape of what landed, the telemetry gives you the real effort behind it, and a model learns the relationship between the two over time so the result is calibrated rather than assumed. This is the difference between "the agent ran for ninety minutes" and "the agent ran for ninety minutes and here is the feature that shipped and stuck." It is also the only layer that lets you separate what you drove from what you delegated, which is the real subject of AI versus human code attribution.
How to set this up
Most developers want this running in an afternoon, not a project. Here is the honest sequence, from the cheapest signal to the most defensible.
- Read the built-in numbers first. Claude Code already shows token usage per session. Glance at it, note your rough per-session cost, and use it as a budget guardrail. That is all it is good for, so do not build a productivity story on it.
- Add a git baseline. Your commit history already exists and needs nothing installed, so it is the fastest way to see the shape of what landed from your agent sessions. Treat it as a benchmark, never as a clock. In the agent era a huge Claude Code commit can represent thirty seconds of accepting a diff, and a one-line change can follow an hour of you correcting the agent, so tracking coding time from git alone will misread agent-heavy work. It is the frame, not the answer.
- Instrument the terminal with a CLI tracker. This is the step that makes Claude Code visible as real work. An editor-agnostic CLI captures the actual activity in your terminal and agent loops, so time spent steering Claude Code stops vanishing from your totals. You will often see your recorded hours jump the first week because the agent work was always there and finally got counted.
- Tie sessions to shipped output. Once the baseline and telemetry run together, the model calibrates time against what shipped, and you get output per unit of effort rather than raw volume. This is where usage tracking turns into something you can defend to a client or a lead, because the number is anchored to work that survived, not to tokens spent.
Almost always, people stop after step one and wonder why their "usage" data feels hollow. It feels hollow because token counts are the least meaningful of the three layers wearing the most official-looking badge.
Where DevClocked fits
If your only question is agent spend, use a tool built for that. A dedicated cost tracker like Tokscale answers "what did my Claude Code sessions cost" directly, and if that is genuinely all you need, reaching for a full profile is the wrong move. Equally, if you just want a one-time gut check on how AI-heavy a repo has gotten, a diff-churn scan against your git history gets you there with no setup. Full disclosure: I build DevClocked, and I would rather tell you where it is not the tool than pretend it is the answer to every version of this question.
DevClocked earns its place when the question is time and output rather than cost. It combines a git baseline with lightweight telemetry from an editor extension and an editor-agnostic CLI that sees terminal and agent sessions across Claude Code, Cursor, and Codex, then learns the relationship between commit history and observed activity to produce calibrated time. That rolls up into a Leverage Score, output per unit of real effort, and Work Blocks that show where the day went. The point is not a prettier token chart, but that your Claude Code sessions become part of a record that proves what you shipped, audited to source, instead of a spend figure you cannot connect to anything that shipped. That connection is the whole game: usage is a claim about activity, and shipped, attributed output is the proof underneath it.
Common mistakes when tracking Claude Code usage
The most common mistake is treating tokens as productivity. Token spend is a real operations number and a useless productivity one, because it measures how much the model generated, not how much you kept. Rewarding high token counts rewards the exact thrashing sessions you want to catch. This is the same trap covered in measuring the ROI of AI coding assistants, where cost gets mistaken for return.
The second is letting agent work go uncounted. If your tracker only sees the editor, every hour you spend steering Claude Code in a terminal reads as idle, and your productivity data quietly lies in the pessimistic direction. This is the flip side of the volume problem and just as distorting.
The third is equating a big agent diff with a big effort. Claude Code can emit a thousand lines in one pass, and counting that as a thousand lines of your work is how commit volume stops mapping to real work entirely. The size of the diff tells you what the agent typed, not what you did.
