Feedback wanted: local coding-agent resource impact telemetry

[VasiHemanth]

Why this exists

Recent reports of coding-agent CPU, memory, OOM, and even macOS panic symptoms make it hard to answer a basic question with evidence: what was this specific agent doing to this specific machine over time?

I have started an early local-only System Impact preview in TokenTelemetry. The goal is to help a person compare versions and sessions on their own hardware, without sending their process or resource data anywhere.

Preview branch

The implementation is on feat/resource-impact-telemetry. The Rust tray companion remains separately on feat/tray-companion.

The current preview:

• detects supported local coding-agent process families, including Claude Code, Codex, Gemini, Cursor, Copilot, Cline, OpenCode, Pi, and others;
• shows detected agent RSS beside host memory and macOS wired memory when available;
• keeps aggregate samples in a local SQLite database;
• draws a personal baseline from the same machine so it can say learning, normal, unusual, or extreme; and
• makes no new outbound network calls and does not write into agent directories.

Important limitations before anyone relies on it

This is an on-demand local snapshot, not yet the durable native collector described in the architecture. I want the community to see the direction early, but the limits matter:

• It records only while TokenTelemetry is running and the resource endpoint is polled. A panic, reboot, or session that happened while it was off cannot be reconstructed.
• Today it is a backend sampler, not the planned single-owner native Rust tt-collector; it still needs firm CPU, RSS, write-volume, retention, and backoff budgets of its own.
• Docker, Podman, and hosted deployments see their own container, pod, or remote host, not necessarily the laptop where the user launched the agent. Docker Desktop on macOS and Windows cannot expose native host wired memory this way. Any future UI must make scope explicit: host, container, pod, or remote host.
• The present agent detection is intentionally an early estimate. Reliable PID-to-session, turn, tool-call, and MCP-server attribution needs executable identity, process start time, process tree, and read-only session-log joins.
• A short run is not a trustworthy baseline. A meaningful comparison must account for machine hardware, OS, memory limits, agent version, concurrent workload, and time coverage.
• Correlation is not proof of causation, especially for wired kernel memory or panics. The tool should preserve evidence and confidence, not make claims it cannot support.

Feedback I would value

1. Which coding agents and versions should be included first?
2. On macOS, Linux, Windows, Docker, Podman, or Kubernetes, what scope would be useful and trustworthy for you?
3. What would make a baseline comparison credible on your own machine?
4. Which self-overhead limits would make you comfortable leaving a local collector enabled?
5. If you have a reproducible memory, FD, port, OOM, or panic pattern, which safe-to-share details would make a replay fixture representative?

Community context

This work follows the discussion around coding-agent resource usage. I also posted a reply in the Boris Cherny X thread, but I do not have a stable link for that reply. The related Threads post is here: Threads discussion.

The next engineering step is to validate the Rust collector and tray lifecycle behind these constraints, before describing this as production-grade resource telemetry.

[bobleer]

I would key the baseline by process tree, agent version, and tool profile, not just machine. Browser helpers, MCP servers, and language servers can dominate RSS while the root agent looks innocent. Recording the collector’s own CPU/RSS with every sample also gives you a hard discard rule instead of a vague overhead promise.

[Pauliehedron]

Reply — resource impact telemetry

Two preview decisions look worth keeping: the sampler is pure Python with a
per-OS split (_macos_memory() via vm_stat, _linux_memory() via
/proc/meminfo), and it stores aggregates only — no PIDs, command lines, or
paths.

Host context — external rootless CLIs

A shape for this already exists upstream: llama-swap #814 → PR #816
(mactop --headless --format json + ioreg fallback — external processes, no
native/cgo).

Need	Tool	Notes
Machine profile + live host state	fastfetch --format json	CPU, GPU (core usage, unified memory used/total), memory, swap, OS, kernel, uptime — verified macOS, fastfetch 2.67.1
Wired memory + pageins	vm_stat	Already in the preview
Linux host state	/proc/meminfo	Already in the preview

The machine profile is one baseline key; process-tree / agent-version /
tool-profile (the comment above) is the other.

Process attribution — light steady state, event-triggered capture

light tick (host counters, aggregate RSS)
  → ring (last N min)
  → event signal (crash / OOM / pressure)
  → one psutil pass (process tree, GPU, own footprint)
  → persist ring + snapshot

Properties:

• Light tick: no process iteration — host counters + one aggregate RSS sum.
• Event pass: psutil on macOS / Linux / Windows — RSS, ppid, cmdline, start
  time; parent walks reach MCP and language servers that dominate RSS.
• Event records can carry PID + timestamp keys for read-only session-log joins
  (session / turn / tool-call / MCP); light ticks stay aggregates-only.
• Write path schema-free; read contract lives in the query layer (below).

Overhead — measured (macOS, M1 Max, ~460 processes, 200-run avg)

Component	Per run	One core @ 5s
vm_stat	~3 ms	~0.05%
ps rss+comm+args (current _agent_processes)	~49 ms	~1.0%
ps rss+comm	~35 ms	~0.7%
ps rss	~18 ms	~0.35%

In the measured table, the args field dominates the scan cost. Suggested
shape: host counters every tick, the aggregate scan on a slower cadence or
lighter fields, full fidelity at events. The sampler records its own CPU/RSS
per tick, auto-disables over budget, re-enables with backoff; a per-OS
benchmark would set the budget.

Storage — flat on write, SQL on read

Layer	Form	Role
Write	JSONL, single writer	Raw feed — light ticks + event records; rotate by size or days, keep N files; torn tail fine; crash fixture is human-readable
Read	DuckDB over the JSONL	Schema lives here — views, baseline analytics (percentile / MAD), dashboard series; stable for any writer

A possible storage shape, from the #49 thread (raw feed + curated view): flat
JSONL keeps the write simple, DuckDB supplies the SQL shape on top.

Your questions — suggested starting points

#	Question	Suggested answer
1	Which agents first	Start with agents that have parseable session-log formats; add version + process-tree join with psutil
2	Scope by platform	Label host vs container; cgroup v2 (memory.current / memory.max) when containerized; wired via vm_stat; Windows via psutil
3	Credible baseline	Machine profile + process-tree / version / tool profile + same-agent-count window; an explicit percentile rule; consider suppressing labels below a minimum sample count
4	Overhead limits	Host counters every tick; psutil only at events; auto-disable with backoff
5	Replay fixtures	Fixture = N minutes of light ticks + event snapshot; process count, FD, swap fields around the failure; no prompts or paths

Related

• External power-cost config for local/subscription models #49 — llama-swap #814 (macOS userspace hardware) + DuckDB read-layer pattern
  (owner chose in-TT read there; this applies it at the read layer only)
• llama-swap #814 → PR #816 — external rootless CLI shape, merged 2026-06-04

Idea drafted with assistance from Ensemble (ENSEMBLE Framework protocol on Codex CLI). Accountable human: @Pauliehedron, Conductor.