I asked Claude Code to refactor a service last Tuesday. The plan was clear, the prompt was good, and I told myself I'd watch it work and review the diff in 15 minutes.
I looked at the strip an hour later. Claude Code had 18 minutes of foreground time. Twitter (well, X) had 27 minutes. Slack had 11. The actual code review happened in the last 4 minutes, in a state of mild panic, because I'd promised the diff before lunch.
This is the developer time-tracker problem in one paragraph. The AI does the work. You're supposed to supervise. In practice, "supervise" means "watch a progress indicator for 2 minutes, get bored, start scrolling, lose 40 minutes, return to find the work done and unreviewed." A good tracker tells you this happened. A great tracker tells you it happens every Tuesday.
Most existing trackers don't categorize the developer workflow, so they can't tell you this. They see "Chrome" and "Slack" and "your editor" as flat buckets. That misses the actual shape of how a developer day works in 2026.
What the developer day looks like now
The composition of a developer's screen time has changed a lot in the last two years. A typical day for me, by app, looks roughly like this:
Ghostty — 4h 04m (terminal — Claude Code lives here too)
Octoweb — 1h 34m (browser — docs, GitHub, Hacker News)
Break — 41m (Timex break overlay)
Firefox Dev Ed — 39m (the work browser)
Slack — 27m
Chrome — 27m (work meetings, Notion, AI vendor consoles)
loginwindow — 12m (the lock screen — yes, we track it)
Spark Desktop — 6m (email)
That's a real Tuesday from our internal logs. The shape is roughly: 60% terminal/IDE work, 25% browser-as-tool, 10% communication, 5% the lock screen between sessions.
What's interesting isn't the totals. It's the subdivision inside the terminal time. Of those 4 hours in Ghostty, how much was Claude Code asking questions and waiting for answers? How much was me typing actual commands? How much was me reading output? An honest developer tracker has to be able to tell those apart.
How Timex sees terminal-based AI tools
Ghostty (and iTerm2, Terminal.app, Warp, Alacritty — same idea) publishes its window title to macOS in a useful way. Most modern terminals reflect the current shell prompt or the running command in the title bar. Claude Code, when it's the active process, sets the title to something like:
~/Work/dev/muvon/timex — claude-code (Sonnet)
That's the row Timex stores. The window title is the discriminator between "I'm typing in a shell" and "Claude Code is running." Same app, different titles, very different work.
A SQL query against the local SQLite database makes this concrete:
-- Real coding (claude-code in title) vs everything-else terminal time, today
SELECT
CASE WHEN window_title LIKE '%claude-code%' THEN 'Claude Code'
WHEN window_title LIKE '%codex%' THEN 'Codex CLI'
WHEN window_title LIKE '%git%' THEN 'git'
ELSE 'shell' END AS bucket,
SUM(1) AS seconds
FROM activity_samples
WHERE date(ts, 'unixepoch', 'localtime') = date('now', 'localtime')
AND app_name = 'Ghostty'
GROUP BY bucket
ORDER BY seconds DESC;
You can run that query yourself against ~/Library/Application Support/io.muvon.timex/timex.sqlite. The output for me last Tuesday was:
Claude Code 8412 (2h 20m)
shell 5217 (1h 27m)
Codex CLI 408 (7m)
git 188 (3m)
Two hours and twenty minutes of Claude Code time. Of which I'd consciously been involved in maybe 40 minutes of meaningful review. That gap — between clock time spent on the AI tool and active engagement with the AI tool — is the thing most developers underestimate the size of.
Cursor, the IDE-as-AI case
Cursor shows up as its own app (Cursor), so it's easier to see at the app level. What's harder is breaking apart "Cursor with Composer running an agent" from "Cursor as a code editor." Both have window titles that reflect the current file.
For now, Timex sees Cursor as one bucket. The agent-vs-editor split isn't something the window title reliably exposes (Cursor doesn't update the title with the agent state). If you want to see that breakdown, you have to combine the Timex data with Cursor's own usage stats from their settings panel. We may add a Cursor-specific integration in v1.1 — but only if there's a clean public API to read from, which there isn't yet.
Codex CLI: same idea as Claude Code
OpenAI's Codex CLI follows the same pattern as Claude Code — runs inside a terminal, updates the title with the model and the working directory. The SQL query above filters for it directly.
If you're A/B-testing Claude Code against Codex CLI (which a lot of developers I know are doing right now), this is where the data gets useful. Take last week's tracked time, split by which tool was active, and you'll see something like:
Claude Code (Sonnet 4.7) — 6h 12m total, 4h actively engaged
Codex CLI — 3h 41m total, 2h 50m actively engaged
"Actively engaged" here means non-idle. The Codex ratio is usually higher in my data because Codex tends to ask more clarifying questions, which keeps you in the loop. Claude Code's longer auto-runs leave more room for you to drift to Twitter. For focused, well-scoped tasks, that's fine. For anything open-ended, it's a liability.
Octomind agent runs
Octomind is a different beast. When you kick off an agent run, it goes off and works in the background while you do something else. Octomind appears in Timex as the time you spent looking at its dashboard, not the time the agent was running on a server somewhere.
That's the correct behavior. If the agent's working autonomously, it's not consuming your attention. If you're staring at the dashboard waiting for it, that is your attention, and it shows up correctly.
The pattern that shows up over and over in my data: Octomind dashboard time correlates almost perfectly with anxiety. The runs I check on every five minutes are the runs where I don't fully trust the prompt. The runs I kick off and forget about are the runs that work. The data is teaching me when to walk away.
Browser tabs and the "research" myth
The browser tab tracker, when you grant Accessibility permission, captures the active tab title. For developers this is the most interesting feed of all.
Last Tuesday, my Octoweb (browser) time of 1h 34m broke down roughly:
github.com/muvon/... 45m
docs.anthropic.com 18m
news.ycombinator.com 12m
stackoverflow.com 11m
twitter.com (or whatever) 6m
docs.python.org 4m
... long tail ...
The thing I want to flag here: notice that Hacker News + Twitter + Reddit aren't the headline. The headline is GitHub and docs. The narrative I tell myself ("the day was distracted") doesn't match the data ("the day was mostly on task with some scrolling"). Without the tab-level data, both are equally plausible. With it, one of them is true.
The other thing I want to flag: I cropped the long tail. There's about 18 minutes in there that's pure context switching — Gmail for 30 seconds, then back to GitHub, then Notion for a minute, then back. That micro-cost is what most developers miss when estimating their own focus time. It's not the big tab on Twitter — it's the dozen 30-second checks.
The "what did I ship" SQL
If you only run one query against the Timex database, run this one:
-- Longest contiguous focused-on-real-coding block in the last 7 days
SELECT
date(ts, 'unixepoch', 'localtime') AS day,
app_name,
window_title,
COUNT(*) AS duration_seconds
FROM activity_samples
WHERE is_idle = 0
AND app_name IN ('Ghostty', 'Cursor', 'Xcode', 'Visual Studio Code', 'Zed')
AND ts > strftime('%s', 'now', '-7 days')
GROUP BY day, app_name, window_title
HAVING duration_seconds > 600
ORDER BY duration_seconds DESC
LIMIT 20;
That gives you the 20 longest >10-minute focused coding sessions of the last week, grouped by what you were actually working on (window title). The output is brutally honest. The week where I felt productive but the query came back with only 6 sessions over 10 minutes was the week I had to admit was actually a meeting-heavy week with the illusion of focus.
What developers actually want to know
My feeling is calibrated against the days I had pre-Claude Code, when "in the editor for 6 hours" meant "wrote code for 6 hours." That's why I keep going back to the data instead of trusting it. That's not how the workflow works anymore. "In the editor for 6 hours" might mean:
- 2 hours of supervised Claude Code that produced 700 lines
- 1 hour of unsupervised drift while Claude Code was running
- 1.5 hours of code review and edits
- 30 minutes of git wrangling
- 1 hour of context switching back into the work
The first and third are the parts that produce shipped code. The second is the part that needs to come down. The data shows me which is which. My feeling alone can't.
The honest limits
A few things this kind of tracker can't tell you:
It can't measure the quality of what was shipped. 4 hours of Claude Code and a clean PR is great. 4 hours of Claude Code and a PR that needs to be rewritten next sprint is a tax. The tracker only sees the time, not the outcome.
It can't see the work that happens in your head. The half hour walking around the apartment thinking about the architecture, before you sit down and write the right thing — that's not in the data. The data sees "loginwindow + idle." You'd be wrong to read that as "wasted."
It can't categorize without window-title cues. If your shell prompt doesn't show what tool is running, Timex sees "Ghostty" and that's it. The granularity is a function of the data your tools expose.
What it can do is give you the most accurate picture currently possible of how a developer day actually breaks down — including the parts you don't want to see, like the 27 minutes on Twitter while Claude Code was working.
If you're using any of Claude Code, Codex CLI, Cursor, or Octomind — and you'd like to see what your actual day looks like through these tools — grab the trial. The strip of color is honest in a way that's hard to argue with.