Attribute nested Cursor and Kimi CLI token usage once either exposes a durable session store

[atomantic]

Problem / Goal

#5831 closed the nested-CLI token-attribution hole for Grok and Antigravity. Cursor and Kimi are still in it: transcriptFamily() returns null for both, so every nested --review-with cursor / kimi pass is recorded in data/usage.json as a chars/4 estimate against the parent provider's bucket, not their own.

#5831 gated them explicitly — "include them in the sibling-family scan only if a durable cwd-keyed session store is found during implementation". While implementing Grok/Antigravity, no such store was found for either CLI, so they were deliberately left out.

Why this is blocked rather than claimable

The work is a mechanical extension of the readers that #5831 landed — but only once there is something on disk to read. Neither CLI is currently known to persist a cwd-keyed, per-session transcript the way ~/.grok/sessions/<urlencoded-cwd>/ or ~/.claude/projects/<cwd-slug>/ do. Until one exists, there is no data source to attribute from, and estimating harder would not improve the numbers.

Acceptance (when unblocked)

• Confirm whether current Cursor / Kimi CLI versions write a durable, cwd-keyed session store containing per-turn token counts (or at least message text).
• If yes: add a reader alongside the Grok/Antigravity ones and extend transcriptFamily() so nested runs are attributed to cursor / kimi in data/usage.json.
• If the store carries cumulative-per-session totals, reuse the delta/high-water handling Attribute nested Grok and Antigravity review-CLI token usage in cost reports #5831 introduced rather than summing snapshots.
• If no store exists: record that finding here and close, rather than leaving this open indefinitely.

Re-check trigger

Revisit on a Cursor or Kimi CLI upgrade, or whenever either is added/promoted as a --review-with reviewer.

Refs #5831

[atomantic]

Investigated both CLIs on a machine that has them installed (Kimi Code CLI 0.32.0 was already present; Cursor CLI 2026.09.02 was installed fresh for this investigation via the official cursor.com/install script). Findings below.

Kimi CLI — durable, cwd-keyed store: CONFIRMED

• ~/.kimi-code/workspaces.json maps a wd_ps_<hash> workspace id to { root: <cwd>, name, created_at, last_opened_at }. This is an indirection, not a direct slug/encode like Grok's encodeURIComponent(cwd) — the cwd has to be resolved through this file first to find the workspace id.
• Per-session data lives at ~/.kimi-code/sessions/<workspaceId>/<sessionId>/:
  • state.json — { createdAt, updatedAt, workDir, agents: { main: {...} } }
  • agents/<agentId>/wire.jsonl — the durable transcript. Confirmed present on disk: a real (if turn-less — it dates to initial CLI setup and was never used for a real conversation) session shows one JSON record per line, type-discriminated (metadata, config.update, tools.set_active_tools observed).
• Static analysis of the kimi binary (via strings) confirms per-turn usage IS tracked and persisted: bundle doc-comments read "step usages reported so far; folded into the turn header at turn.ended", with an internal formula inputTokens = inputOther + inputCacheCreation, cachedTokens = inputCacheRead, outputTokens = output. The bundle also explicitly documents wire.jsonl as the durable "History source" (as opposed to live UI state), with a dedicated fold/replay routine (reduceWireRecords) built to reconstruct session history from it.

Cursor CLI (cursor-agent) — durable, cwd-keyed store: CONFIRMED

• ~/.cursor/projects/<slug>, where slug = the cwd with every non-alphanumeric character collapsed to -. Confirmed live: running cursor-agent create-chat in this repo's claim worktree created ~/.cursor/projects/Users-<redacted>-github-com-atomantic-PortOS-data-cos-<hash>/.
• The CLI ships agent transcript <id> ("Fetch a cloud agent's conversation transcript as JSONL — writes to disk under ~/.cursor/projects by default"), and agent ls / agent resume / --continue / --resume [chatId] all operate on locally-tracked chat sessions.
• Bundle strings confirm real per-turn token tracking, with field names including input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, num_prompt_tokens, num_completion_tokens.

What's still open, and why no reader is being shipped yet

Neither CLI has ever completed a real (LLM-backed) turn on this machine — Kimi has no model configured, and Cursor requires agent login (a browser-based device-code flow) or a CURSOR_API_KEY, neither available to this unattended run. So while both stores are conclusively confirmed to exist and be cwd-keyed (the specific thing this issue was blocked on), there is no real populated transcript for either to validate exact field names against. Every other reader in providerTranscriptUsage.js was clearly built and tuned against real captured sessions — the Grok parser's docstring cites concrete numbers like "44 of 46 multi-turn sessions" and "373 real turns, 0 counterexamples". Every reader in that file degrades gracefully to null on a schema mismatch (never throws, never misattributes — worst case is "no change from today"), so shipping a guessed parser isn't a correctness risk, but it is a real risk of shipping dead code that silently never fires, with no way to tell the difference without a live sample.

Recommendation for whoever picks this up with working credentials: log in to either CLI (cursor-agent login, or configure a Kimi model + run one kimi -p "..." prompt), then read back the resulting wire.jsonl / .cursor/projects/<slug>/*.jsonl to pin the exact field names, and follow the existing Antigravity/Grok reader pattern in server/lib/providerTranscriptUsage.js + server/services/usageReconciler.js (add TRANSCRIPT_FAMILIES entries, extend transcriptFamily(), wire a case into readMeasuredUsage). The paths and slugging schemes above are already verified — that part doesn't need to be redone.

Moving this to needs-input: the remaining blocker is credentials this run doesn't have, not an open design question.