Summary
zed-wakatime does not pass --human-line-changes or --ai-line-changes to wakatime-cli, so for users who edit code in Zed the WakaTime dashboard reports 0 human lines even when the user is actively typing by hand. This makes the "Human vs AI lines" metric unusable for anyone whose primary editor is Zed, including the increasingly common Zed + Claude Code workflow.
Current behavior
The command wakatime-ls builds for each heartbeat (see wakatime-ls/src/main.rs) includes only:
--time --write --entity [--project-folder --plugin --language --lineno --cursorpos]
No --human-line-changes / --ai-line-changes are ever sent. As a result:
wakatime/claude-code-wakatime reports --ai-line-changes N on every Claude Code edit → AI line counter grows.zed-wakatime reports nothing about line deltas → human line counter stays at 0 forever.
On the dashboard this looks like 100% AI authorship even when the user is typing by hand in Zed.
Why this matters now
With Claude Code + Zed (and similar agentic flows) becoming common, the "how much did I write vs how much did the AI write" question is one of the main things users come to WakaTime for. Today that split is broken for Zed users.
The closest parallel implementation, vscode-wakatime, already has the heuristic for distinguishing AI-pasted code from human typing — see src/wakatime.ts (isPossibleAICodeInsert, isPossibleHumanCodeInsert, the delta > 50 in 60s filter, the isAICodeGenerating debounce).
Blocking dependency on Zed
Implementing this requires text-change events from Zed which the extension API does not currently expose:
wakatime-ls runs as a fake LSP, but Zed does not currently forward incremental textDocument/didChange payloads with text deltas to it in a form usable for line-delta counting.
Proposed path forward
- Confirm the limitation and link this issue to the Zed-side requests above so users have a single thread to follow.
- Once Zed exposes buffer change events (or LSP didChange with text deltas), port the
vscode-wakatime heuristics for AI-vs-human line classification into wakatime-ls.
- In the meantime, document the limitation in the README so users running Zed + Claude Code understand why "Human lines" is 0 on the dashboard and don't assume it's a misconfiguration.
Environment
Zed-wakatime/0.1.10wakatime-cli v2.13.1- Zed 1.1.8 (stable.269)
- macOS 15 (Darwin 25.5.0, arm64)
Related
claude-code-wakatime already sends --ai-line-changes on its own heartbeats, so the AI side of the metric is fully populated.- Adding human-side counts in
zed-wakatime would make the split symmetric.
Summary
zed-wakatimedoes not pass--human-line-changesor--ai-line-changestowakatime-cli, so for users who edit code in Zed the WakaTime dashboard reports 0 human lines even when the user is actively typing by hand. This makes the "Human vs AI lines" metric unusable for anyone whose primary editor is Zed, including the increasingly common Zed + Claude Code workflow.Current behavior
The command
wakatime-lsbuilds for each heartbeat (seewakatime-ls/src/main.rs) includes only:No
--human-line-changes/--ai-line-changesare ever sent. As a result:wakatime/claude-code-wakatimereports--ai-line-changes Non every Claude Code edit → AI line counter grows.zed-wakatimereports nothing about line deltas → human line counter stays at 0 forever.On the dashboard this looks like 100% AI authorship even when the user is typing by hand in Zed.
Why this matters now
With Claude Code + Zed (and similar agentic flows) becoming common, the "how much did I write vs how much did the AI write" question is one of the main things users come to WakaTime for. Today that split is broken for Zed users.
The closest parallel implementation,
vscode-wakatime, already has the heuristic for distinguishing AI-pasted code from human typing — seesrc/wakatime.ts(isPossibleAICodeInsert,isPossibleHumanCodeInsert, thedelta > 50 in 60sfilter, theisAICodeGeneratingdebounce).Blocking dependency on Zed
Implementing this requires text-change events from Zed which the extension API does not currently expose:
wakatime-lsruns as a fake LSP, but Zed does not currently forward incrementaltextDocument/didChangepayloads with text deltas to it in a form usable for line-delta counting.Proposed path forward
vscode-wakatimeheuristics for AI-vs-human line classification intowakatime-ls.Environment
Zed-wakatime/0.1.10wakatime-cli v2.13.1Related
claude-code-wakatimealready sends--ai-line-changeson its own heartbeats, so the AI side of the metric is fully populated.zed-wakatimewould make the split symmetric.