[bug]: claude-mem's gateway (GLM) usage silently stops being counted — claude-mem 13.12.4 spawns the CLI with --no-session-persistence

[pitimon]

What happened?

A previously-tracked source went to zero and nothing reported it. claude-mem is still making
Claude-CLI calls against a third-party Anthropic-compatible gateway (glm-5-turbo) all day, but as of
2026-07-28 ~18:00 (+07) TokenTracker counts zero of them. tokentracker doctor stays green.

Root cause is external to TokenTracker — claude-mem v13.12.4 started spawning its Claude Code CLI
child with --no-session-persistence, so no session .jsonl is written anywhere. TokenTracker's
only ingest surfaces are ~/.claude/projects/** and ~/.codex/sessions/**, so the data simply stops
existing. I'm filing it here anyway because (a) that source was 84% of my tracked Claude Code files,
and (b) the failure mode is silent — which is the part TokenTracker can fix.

The seam

Last observer-session transcript written	2026-07-28 18:00 (+07)
Last glm-5-turbo bucket in queue.jsonl	hour_start = 2026-07-28T10:30:00.000Z (= 17:30 +07)
claude-mem v13.12.4 plugin files installed	2026-07-28 18:00 / .install-version 18:25
GLM calls still happening after that	yes — see below

Transcript files per day in ~/.claude/projects/<slug of ~/.claude-mem/observer-sessions>/:

2026-07-25   128
2026-07-26    11
2026-07-27     8
2026-07-28    52     <-- stops at 18:00
2026-07-29     0
2026-07-30     0

…while claude-mem's own database shows the work never stopped
(select date(created_at), count(*) from observations where generated_by_model='glm-5-turbo', shifted to +07):

2026-07-28   714
2026-07-29   252     <-- 0 tokens recorded by TokenTracker
2026-07-30    77     <-- partial day, 0 tokens recorded

Volume now invisible

Daily glm-5-turbo totals TokenTracker did capture, from ~/.tokentracker/tracker/queue.jsonl
(billable_total_tokens, bucketed to +07):

2026-07-25    80,624,877
2026-07-26   157,549,828
2026-07-27    68,610,858
2026-07-28   102,386,382
2026-07-29             0
2026-07-30             0

Rough estimate of the gap: Jul-28 ran ≈143k billable tokens per observation (102.4M / 714). Applying
that ratio to the 329 observations since the seam ⇒ ~47M billable tokens untracked in under two days.
Estimate, not a measurement — the real number is only knowable at the gateway now.

Root cause evidence

The live CLI child of the claude-mem worker (ps -o command=, secrets omitted):

claude --output-format stream-json --verbose --input-format stream-json
       --model glm-5-turbo
       --permission-prompt-tool stdio
       --disallowedTools Bash,Read,Write,Edit,Grep,Glob,WebFetch,WebSearch,Task,NotebookEdit,AskUserQuestion,TodoWrite
       --setting-sources= --strict-mcp-config --permission-mode dontAsk
       --no-session-persistence

Claude Code's own help text for that flag: "use --no-session-persistence to disable transcript writes
entirely." In claude-mem's bundle the flag comes from persistSession: false set in code — there is no
CLAUDE_MEM_* setting that turns it back on.

Ruled out: the Claude Code CLI itself. ~/.local/bin/claude has been pinned to 2.1.220 since
2026-07-25, and transcripts kept appearing 07-25 → 07-28. The only thing that changed at the seam is
claude-mem 13.11.0 → 13.12.4.

Verified: no drop-in replacement source exists today

I looked for somewhere else to read this usage from before filing:

• claude-mem.db → observations.discovery_tokens is 0 for every recent row; sdk_sessions has
  no token columns at all (id, content_session_id, memory_session_id, project, platform_source, user_prompt, started_at*, completed_at*, status, worker_port, prompt_counter, custom_title).
• claude-mem worker HTTP API (:37701) exposes ~39 endpoints; none carry usage/token data.
  /api/stats returns only {worker:{version,uptime,activeSessions,sseClients,port}, database:{path,size,observations,sessions,summaries,firstObservationAt}}.
• No .jsonl anywhere under $HOME (outside TokenTracker's own queue) contains a "model":"glm…"
  record after the seam.

So the token data is genuinely gone at the source. Nothing for TokenTracker to parse.

Why I think this still belongs here

1. It fails silently, and silence looks identical to "you didn't use it". No error, no gap marker,
   no dashboard warning. tokentracker doctor reports ok 9 | warn 1 | fail 0 | critical 0 — the one
   WARN is an unrelated queue.row_invariant (2 rows in 6,343).
2. It's a class, not a one-off. --no-session-persistence is a public Claude Code flag. Any
   SDK/CLI consumer can opt out of transcripts at any time and become invisible. "Transcripts exist"
   is an assumption TokenTracker currently treats as guaranteed.
3. The blast radius here was large: cursors.json tracks 14,630 files — 14,048 under
   ~/.claude/projects, 582 under ~/.codex/sessions — and 12,314 of them were claude-mem
   observer sessions. Roughly 84% of the Claude Code ingest surface stopped producing new data and
   nothing noticed.

Steps to reproduce

1. Point a Claude Code consumer at a third-party Anthropic-compatible gateway — for claude-mem, put
   ANTHROPIC_BASE_URL + ANTHROPIC_AUTH_TOKEN in ~/.claude-mem/.env and set
   CLAUDE_MEM_MODEL=glm-5-turbo, CLAUDE_MEM_PROVIDER=claude in ~/.claude-mem/settings.json.
2. On claude-mem ≤ 13.11.0, use Claude Code normally → transcripts appear under
   ~/.claude/projects/<observer-sessions slug>/ and TokenTracker counts glm-5-turbo usage.
3. Upgrade claude-mem to 13.12.4 and keep working.
4. Confirm the calls are still happening:
   sqlite3 ~/.claude-mem/claude-mem.db "select generated_by_model, count(*) from observations where created_at > '<upgrade time>' group by 1"
   → glm-5-turbo | N with N > 0.
5. Confirm the child is spawned without persistence:
   pgrep -lfP $(pgrep -f 'worker-service.cjs --daemon') → argv contains --no-session-persistence.
6. Check TokenTracker → no new glm-5-turbo buckets after the upgrade timestamp; doctor still green.

Expected behavior

TokenTracker shouldn't be able to silently lose a source. At minimum I'd expect a visible
"source went quiet" signal; ideally a way to keep accounting for gateway spend that no longer
lands in a transcript.

Proposed fixes (ranked, happy to PR any of these)

1. Source-staleness detection — cheapest, most general, would have caught this the same evening.
   Keep a per-source (and optionally per-model) last_seen. If a source that produced ≥ N tokens/day
   for K consecutive days drops to zero for more than X hours, emit a WARN in doctor and a banner
   on the dashboard / menu-bar app. Thresholds configurable; default something forgiving like
   "was active 3 of the last 7 days, silent > 24h".
2. Document the transcript assumption — a short note that ingest depends on session .jsonl
   files, that --no-session-persistence (and any SDK caller passing persistSession: false)
   defeats it, and how to spot it. Plus a doctor check that greps live claude processes for the
   flag would be a nice concrete touch.
3. Optional gateway reconciliation — config for an Anthropic-compatible gateway (base URL +
   usage endpoint + token) so third-party spend can be pulled independently of transcripts. This is
   the only path that gives accurate numbers for the current claude-mem behavior, rather than just
   flagging the hole.
4. Upstream ask (I'll file separately with claude-mem) — either expose per-session token usage on
   the worker's /api/stats, or make persistSession a CLAUDE_MEM_* setting so users who track
   spend can opt back in. If claude-mem grows a usage endpoint, TokenTracker could add it as a
   first-class source.

Environment

• TokenTracker version: @ipv9/tokentracker-cli 0.39.44 (running from ~/.tokentracker/tracker/app, LaunchAgent dashboard)
• Node.js: v26.0.0
• OS: macOS 26.5.2 (Apple Silicon)
• Claude Code CLI: 2.1.220 (unchanged since 2026-07-25)
• claude-mem: 13.12.4 (was 13.11.0 until 2026-07-28 ~18:00 +07); worker healthy on 127.0.0.1:37701

tokentracker doctor output

Doctor report

- [OK] runtime.dashboard_url - dashboard_url unset
- [OK] runtime.http_timeout_ms - http timeout resolved
- [OK] runtime.debug - debug disabled
- [OK] runtime.node_version - Node.js v26.0.0 satisfies >=20
- [OK] browser.opener - open available
- [OK] fs.tracker_dir - tracker dir readable
- [OK] fs.config_json - config.json readable
- [OK] cli.entrypoint - cli entrypoint readable
- [WARN] queue.row_invariant - 2 row problem(s) in 6343 line(s)
- [OK] notify.configured - notify configured

Summary: ok 9 | warn 1 | fail 0 | critical 0

Note the report is green while an 84%-of-files source is producing nothing — that's the gap
proposal #1 is aimed at. (The queue.row_invariant WARN is unrelated and pre-existing.)

[pitimon]

Correction — four errors in the original report, one of which breaks proposal #1

An independent review pass over this issue and its proposed fixes caught the following. All
figures below were re-derived from the same live ~/.tokentracker/tracker/queue.jsonl.

1. The token volumes were inflated — I summed raw append lines

queue.jsonl is append-only and readers take the latest entry per (source, model, hour_start)
(CLAUDE.md, "Queue entry"; planCompaction in src/lib/queue-compact.js:71-105 implements exactly
that). My daily totals summed every raw line, including superseded ones, so any bucket that was
re-appended got counted more than once. Corrected (billable_total_tokens, deduped latest-per-key,
bucketed to +07):

date	published (wrong)	corrected
2026-07-25	80,624,877	80,624,877
2026-07-26	157,549,828	22,888,219
2026-07-27	68,610,858	18,501,870
2026-07-28	102,386,382	26,292,817
2026-07-29	0	0
2026-07-30	0	0

Jul-25 and earlier match because those buckets were never re-appended. The live file is currently
6,371 lines / 5,756 unique keys.

2. The "~47M billable tokens untracked" estimate is withdrawn

It was computed from the inflated Jul-28 figure, and the tokens-per-observation ratio it relied on
was weak to begin with. I am not replacing it with a corrected estimate: the volume that went
untracked is unknown from TokenTracker's side — only the gateway can say. Treating it as unknown
is the honest statement.

3. The "84%" used the wrong denominator

cursors.json tracks 14,630 files: 14,048 under ~/.claude/projects and 582 under
~/.codex/sessions. 12,314 of them are claude-mem observer sessions. I divided by the all-source
total but labelled it "the Claude Code ingest surface" — against the Claude-only denominator it is
12,314 / 14,048 ≈ 88%. Also worth stating plainly: file share is not usage share; a file
count says nothing about how many tokens those files carried.

4. "TokenTracker's only ingest surfaces are ~/.claude/projects/** and ~/.codex/sessions/**"

Imprecise. ~/.codex/sessions is the Codex source, unrelated to this traffic, and the repo has
~24 parsers over many roots (parse*Incremental in src/lib/rollout.js). The accurate claim is:
~/.claude/projects is the only ingest surface for these Claude-CLI calls, and that is the one
that went empty.

---

5. The important one: proposal #1 as written would NOT have caught this incident

Proposal #1 was "source-staleness detection". Every Claude model — including the ones routed to a
third-party gateway — is aggregated under source=claude (src/commands/sync.js:287 passes the
literal). So on this machine, right now:

last seen per SOURCE
  claude    2026-07-29T23:00:00Z   silent   0.4h     <-- main session, still active
  codex     2026-07-29T23:00:00Z   silent   0.4h
  hermes    2026-06-23T15:30:00Z   silent 872h       (one bucket ever, correctly below threshold)

last seen per (SOURCE, MODEL) under claude
  claude-opus-5              silent   0.4h
  claude-sonnet-5            silent  23.9h
  glm-4.7                    silent  36.9h   <-- stopped
  glm-5-turbo                silent  36.9h   <-- stopped, the reported incident
  claude-fable-5             silent  46.4h
  claude-haiku-4-5           silent 119.9h

A source-level detector sees claude active 0.4h ago and emits nothing. The proposal misses the
exact failure it was written for.

Dropping to (source, model) granularity does detect it, but is noisy. Replaying the proposed rule
(active ≥3 distinct days in a 14-day window, silent >24h) against this machine's real queue:

stream	active days	silent	real defect?
claude/glm-5-turbo	13	37h	yes
claude/glm-4.7	8	37h	yes — same gateway, identical stop bucket
claude/claude-opus-4-8	9	121h	no — model retired by the user
claude/claude-fable-5	7	46h	no — used occasionally
codex/gpt-5.6-luna	4	31h	no — used occasionally

2 true / 3 false. One detail from that table looks more promising than the threshold itself: the two
true positives stop at the identical hour_start bucket, while the model-switch cases are
scattered. Correlated stop-time across sibling streams inside one source is a systemic signature in
a way that a single stream going quiet is not — but that needs validating on more than one machine
before it is worth shipping.

Revised recommendation

• Proposal Fix local dashboard cloud side effects #2 (detect a running Claude CLI with --no-session-persistence) is promoted to the
  primary fix. It is precise, needs no history, no thresholds, and would have fired the same
  evening. Constraints identified in review: return a count and a coarse reason only — never PIDs,
  argv, or environment values (CONTRIBUTING.md privacy rule; the local read API is
  unauthenticated); guard for platforms without /bin/ps; cache with a short TTL rather than
  spawning a process per dashboard request. Note parseProcessLine (src/lib/usage-limits.js:1335)
  is not currently exported and would need to be, or moved to a shared module.
• Proposal Fix local dashboard navigation, cloud side effects, and IP check CORS noise #1 is not ready. It needs (source, model) granularity plus a discriminator better
  than a silence threshold, and a way for a user to retire a stream. Parking it rather than shipping
  a detector with 60% false positives on the only machine it has been tested against.
• Two further review findings that apply to whatever ships: activeDays must be grouped in the
  user's timezone, not UTC (a +07 user's day splits across two UTC dates); and
  repairClaudeQueueFromGroundTruth (src/commands/sync.js:1929) can rewrite queue.jsonl and
  drop historical hours, so any history-derived rule needs either a monotonic high-water mark or an
  explicit "best-effort" label plus a repair regression test.

[pitimon]

PR #129 is a partial fix for this — please do not close this issue when it merges

#129 makes the failure visible while it is happening: tokentracker doctor and the dashboard now
report Claude CLI processes running with --no-session-persistence. On this machine that check
fires right now —

WARN ingest.transcript_suppressed - 1 Claude CLI process running with --no-session-persistence (glm-5-turbo)

— so the condition reported here is live and is finally observable.

What it does not do

It reads the process list. It answers "is something running right now that I cannot see". The
shape reported in this issue is the other one: a source that already went to zero, noticed two
days later. If the suppressed process has exited by the time you look, #129 says nothing, and the
gap in the queue still looks like a quiet day.

The ranked proposal #1 in this issue — source-staleness detection — was tried and deliberately
parked, and the reasoning is in #129's description: every Claude model aggregates under
source=claude, so at source granularity the check read "active 0.4h ago" while the affected model
had been silent 37h. It would have missed this incident. At (source, model) granularity it fires,
but produced 3 false positives against 2 true ones on the one machine it was tested on.

That reasoning is sound and I am not arguing with the decision to park it. The consequence is just
that this issue's reported failure mode remains open, and closing it on #129's merge would
record a fix that was not made.

Suggestion

Link #129 as partial, keep this open for the silence/staleness half, and close it when a user who
comes back to a dashboard after two days is told that something stopped.

Follow-ups filed from #129's review

Relevant to this issue: #130 — degraded is pinned true by any unrelated warn, so the
machine-readable half of "the report looked green" is not yet usable as an alert. Also #131
(dashboard only checks on mount), #132, #133, #134, #135.

[pitimon]

Phase 3 triage: Handoff / known accepted gap

#129 provides precise live-process detection while --no-session-persistence is active, and #131 is being addressed separately so the dashboard refreshes that signal after mount. The historical “source already went quiet” case remains unsolved.

No source/model staleness heuristic will be shipped in this phase: the measured candidate produced more false positives than true positives and lacks a reliable retirement signal. The root data-loss control belongs upstream in claude-mem (persist transcripts or expose measured token usage).

Keeping this issue open as a known accepted gap/handoff. It is not a 0.40.0 release blocker. Promote back to a TokenTracker fix candidate only when there is either an upstream usage endpoint, a user-controlled stream-retirement contract, or multi-machine evidence for a low-noise detector.

[pitimon]

2026-08-08 review: current doctor already detects active --no-session-persistence processes without inspecting prompts or secrets. The stopped-source case still lacks an independently auditable, low-false-positive signal: absent transcripts alone cannot distinguish inactivity, cleanup, config changes, or missing source evidence. No heuristic added; keeping #128 open pending an upstream usage endpoint/transcript persistence control or multi-machine evidence.