पिछले मंगलवार मैंने Claude Code से एक service refactor करने को कहा। Plan साफ़ था, prompt अच्छा था, और मैंने ख़ुद से कहा कि मैं इसे काम करते देखूँगा और 15 मिनट में diff review कर लूँगा।
एक घंटे बाद मैंने strip देखी। Claude Code के पास 18 मिनट foreground time था। Twitter (माने X) के पास 27 मिनट। Slack के पास 11। असली code review आख़िरी 4 मिनट में हुआ, हल्के panic की हालत में, क्योंकि मैंने lunch से पहले diff देने का वादा किया था।
यह रहा एक paragraph में पूरा developer time-tracker problem। AI काम करता है। तुम्हें supervise करना है। हक़ीक़त में "supervise" का मतलब है "2 मिनट progress indicator देखो, bore हो जाओ, scrolling शुरू करो, 40 मिनट गँवा दो, और लौटकर पाओ कि काम हो चुका है और unreviewed है।" एक अच्छा tracker तुम्हें बताता है कि ऐसा हुआ। एक बेहतरीन tracker तुम्हें बताता है कि ऐसा हर मंगलवार होता है।
ज़्यादातर मौजूदा trackers developer workflow को categorize नहीं करते, तो वे तुम्हें यह बता ही नहीं सकते। वे "Chrome", "Slack" और "तुम्हारे editor" को flat buckets की तरह देखते हैं। यह 2026 में एक developer का दिन असल में किस shape का होता है, उसे miss कर देता है।
अब एक developer का दिन कैसा दिखता है
पिछले दो साल में एक developer के screen time की composition काफ़ी बदल गई है। मेरे लिए एक typical दिन, app के हिसाब से, लगभग ऐसा दिखता है:
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)
यह हमारे internal logs से एक असली मंगलवार है। Shape लगभग ऐसा है: 60% terminal/IDE work, 25% browser-as-tool, 10% communication, 5% sessions के बीच का lock screen।
दिलचस्प चीज़ totals नहीं हैं। दिलचस्प है terminal time के अंदर की subdivision। Ghostty में उन 4 घंटों में से कितना Claude Code का सवाल पूछना और जवाब का इंतज़ार करना था? कितना मेरा असली commands type करना था? कितना मेरा output पढ़ना था? एक ईमानदार developer tracker को इन्हें अलग-अलग बता पाना चाहिए।
Timex terminal-based AI tools को कैसे देखता है
Ghostty (और iTerm2, Terminal.app, Warp, Alacritty — वही idea) अपना window title macOS को एक काम के तरीक़े से publish करता है। ज़्यादातर modern terminals title bar में current shell prompt या चल रहे command को reflect करते हैं। Claude Code, जब वह active process होता है, title को कुछ ऐसा set करता है:
~/Work/dev/muvon/timex — claude-code (Sonnet)
यही वह row है जो Timex store करता है। Window title ही वह discriminator है जो "मैं shell में type कर रहा हूँ" और "Claude Code चल रहा है" के बीच फ़र्क़ करता है। एक ही app, अलग titles, बहुत अलग काम।
Local SQLite database के against एक SQL query इसे ठोस बना देती है:
-- 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;
यह query तुम ख़ुद ~/Library/Application Support/io.muvon.timex/timex.sqlite के against चला सकते हो। पिछले मंगलवार मेरे लिए output था:
Claude Code 8412 (2h 20m)
shell 5217 (1h 27m)
Codex CLI 408 (7m)
git 188 (3m)
दो घंटे बीस मिनट का Claude Code time। जिसमें से मैं consciously शायद 40 मिनट meaningful review में शामिल रहा था। वह gap — AI tool पर बिताए clock time और AI tool के साथ active engagement के बीच — वही चीज़ है जिसके size को ज़्यादातर developers कम आँकते हैं।
Cursor, IDE-as-AI वाला मामला
Cursor अपने ही app (Cursor) के रूप में दिखता है, तो इसे app level पर देखना आसान है। मुश्किल है "Cursor जिसमें Composer एक agent चला रहा है" को "Cursor एक code editor के रूप में" से अलग करना। दोनों के window titles current file को reflect करते हैं।
अभी के लिए, Timex Cursor को एक bucket के रूप में देखता है। Agent-vs-editor split वह चीज़ नहीं है जिसे window title reliably expose करता हो (Cursor title को agent state के साथ update नहीं करता)। अगर तुम वह breakdown देखना चाहते हो, तो तुम्हें Timex data को Cursor के अपने usage stats (उनके settings panel से) के साथ combine करना होगा। हम v1.1 में एक Cursor-specific integration जोड़ सकते हैं — लेकिन सिर्फ़ तब अगर पढ़ने के लिए एक clean public API हो, जो अभी नहीं है।
Codex CLI: Claude Code वाला ही idea
OpenAI का Codex CLI वही pattern follow करता है जो Claude Code का है — एक terminal के अंदर चलता है, title को model और working directory के साथ update करता है। ऊपर वाली SQL query सीधे इसके लिए filter करती है।
अगर तुम Claude Code को Codex CLI के against A/B-test कर रहे हो (जो मेरे जानने वाले बहुत से developers अभी कर रहे हैं), तो यहीं data काम का बन जाता है। पिछले हफ़्ते का tracked time लो, इस हिसाब से split करो कि कौन-सा tool active था, और तुम्हें कुछ ऐसा दिखेगा:
Claude Code (Sonnet 4.7) — 6h 12m total, 4h actively engaged
Codex CLI — 3h 41m total, 2h 50m actively engaged
यहाँ "Actively engaged" का मतलब है non-idle। मेरे data में Codex का ratio आमतौर पर ज़्यादा होता है क्योंकि Codex ज़्यादा clarifying questions पूछता है, जो तुम्हें loop में बनाए रखता है। Claude Code के लंबे auto-runs तुम्हें Twitter की तरफ़ drift करने की ज़्यादा गुंजाइश देते हैं। Focused, well-scoped tasks के लिए, यह ठीक है। किसी भी open-ended चीज़ के लिए, यह एक liability है।
Octomind agent runs
Octomind एक अलग ही जानवर है। जब तुम एक agent run kick off करते हो, वह background में जाकर काम करता है जबकि तुम कुछ और करते हो। Octomind Timex में उतने time के रूप में दिखता है जितना तुमने उसका dashboard देखने में बिताया, न कि उतने time के रूप में जब agent कहीं किसी server पर चल रहा था।
यही सही behavior है। अगर agent autonomously काम कर रहा है, तो वह तुम्हारा ध्यान consume नहीं कर रहा। अगर तुम उसके इंतज़ार में dashboard को घूर रहे हो, तो वह तुम्हारा ध्यान है, और वह सही तरीक़े से दिखता है।
मेरे data में बार-बार दिखने वाला pattern: Octomind dashboard time लगभग perfectly anxiety के साथ correlate करता है। जिन runs को मैं हर पाँच मिनट पर check करता हूँ वे वही runs हैं जिनमें मुझे prompt पर पूरा भरोसा नहीं होता। जिन runs को मैं kick off करके भूल जाता हूँ वे वही runs हैं जो चल जाते हैं। Data मुझे सिखा रहा है कि कब walk away करना है।
Browser tabs और "research" वाला myth
Browser tab tracker, जब तुम Accessibility permission देते हो, active tab title capture करता है। Developers के लिए यह सबसे दिलचस्प feed है।
पिछले मंगलवार, मेरा Octoweb (browser) time 1h 34m लगभग ऐसे बँटा:
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 ...
यहाँ जो चीज़ मैं flag करना चाहता हूँ: ग़ौर करो कि Hacker News + Twitter + Reddit headline नहीं हैं। Headline GitHub और docs हैं। जो narrative मैं ख़ुद से कहता हूँ ("दिन distracted था") वह data से मेल नहीं खाता ("दिन ज़्यादातर on task था, कुछ scrolling के साथ")। Tab-level data के बिना, दोनों बराबर plausible हैं। उसके साथ, इनमें से एक सच है।
दूसरी चीज़ जो मैं flag करना चाहता हूँ: मैंने long tail crop कर दी। उसमें लगभग 18 मिनट हैं जो pure context switching है — 30 सेकंड Gmail, फिर वापस GitHub, फिर एक मिनट Notion, फिर वापस। यही micro-cost है जिसे ज़्यादातर developers अपना focus time आँकते वक़्त miss कर देते हैं। यह Twitter पर खुला बड़ा tab नहीं है — यह दर्जन भर 30-सेकंड के checks हैं।
"मैंने क्या ship किया" वाली SQL
अगर तुम Timex database के against सिर्फ़ एक query चलाओ, तो यह चलाओ:
-- 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;
यह तुम्हें पिछले हफ़्ते के 20 सबसे लंबे >10-मिनट के focused coding sessions देती है, इस हिसाब से grouped कि तुम असल में किस पर काम कर रहे थे (window title)। Output बेरहमी से ईमानदार है। जिस हफ़्ते मुझे productive महसूस हुआ लेकिन query सिर्फ़ 6 sessions 10 मिनट से ऊपर वाले लौटा लाई, वही हफ़्ता मुझे मानना पड़ा कि असल में focus के illusion वाला एक meeting-heavy हफ़्ता था।
Developers असल में क्या जानना चाहते हैं
मेरा feel उन दिनों के हिसाब से calibrated है जो pre-Claude Code थे, जब "6 घंटे editor में" का मतलब था "6 घंटे code लिखा"। इसीलिए मैं feel पर भरोसा करने के बजाय बार-बार data की तरफ़ लौटता हूँ। अब workflow ऐसे नहीं चलता। "6 घंटे editor में" का मतलब हो सकता है:
- 2 घंटे supervised Claude Code जिसने 700 lines बनाईं
- 1 घंटा unsupervised drift जबकि Claude Code चल रहा था
- 1.5 घंटे code review और edits
- 30 मिनट git wrangling
- 1 घंटा work में वापस context switching
पहला और तीसरा वे हिस्से हैं जो shipped code पैदा करते हैं। दूसरा वह हिस्सा है जिसे नीचे आना चाहिए। Data मुझे दिखाता है कि कौन-सा कौन-सा है। अकेला मेरा feel नहीं दिखा सकता।
ईमानदार limits
कुछ चीज़ें जो इस तरह का tracker तुम्हें नहीं बता सकता:
यह measure नहीं कर सकता कि जो ship हुआ उसकी quality क्या थी। 4 घंटे Claude Code और एक clean PR शानदार है। 4 घंटे Claude Code और एक PR जिसे अगले sprint में दोबारा लिखना पड़े, वह एक tax है। Tracker सिर्फ़ time देखता है, outcome नहीं।
यह वह काम नहीं देख सकता जो तुम्हारे दिमाग़ में होता है। वह आधा घंटा apartment में घूमते हुए architecture के बारे में सोचना, इससे पहले कि तुम बैठकर सही चीज़ लिखो — वह data में नहीं है। Data "loginwindow + idle" देखता है। इसे "बर्बाद" पढ़ना ग़लत होगा।
यह window-title cues के बिना categorize नहीं कर सकता। अगर तुम्हारा shell prompt नहीं दिखाता कि कौन-सा tool चल रहा है, तो Timex "Ghostty" देखता है और बस इतना ही। Granularity उस data का function है जो तुम्हारे tools expose करते हैं।
जो यह कर सकता है वह है तुम्हें अभी मुमकिन सबसे accurate picture देना कि एक developer का दिन असल में कैसे बँटता है — उन हिस्सों समेत जो तुम देखना नहीं चाहते, जैसे वे 27 मिनट Twitter पर जबकि Claude Code काम कर रहा था।
अगर तुम Claude Code, Codex CLI, Cursor, या Octomind में से कुछ भी इस्तेमाल कर रहे हो — और देखना चाहते हो कि इन tools के ज़रिए तुम्हारा असली दिन कैसा दिखता है — trial ले लो। रंगों की वह strip एक ऐसे तरीक़े से ईमानदार है जिससे बहस करना मुश्किल है।