Session slimming: measured waste per source, and a proposed S4 bench gate

[thedavidweng]

I spent a couple of days measuring where the ~15 GB of agent session data on my Mac actually goes, across the sources this app already reads plus a couple it doesn't. Most of it turns out to be losslessly removable. This is a proposal to surface that — and eventually act on it — with the measurements behind it.

What the waste looks like

All measured on one machine, all reproducible:

Source	Shape of the waste	Measured	Lossless rule
OpenCode	event table stores a full message snapshot per streaming update	17,940 message.updated.1 rows for 4,639 distinct messages; 378 MB where keeping the newest per message is 16 MB	keep newest snapshot per message — see #33356, where others report 13.7 GB / 31 GiB / 50 GB stores
Codex	logs_2.sqlite freelist never reclaimed	519 MB file, 470 MB (90.6%) freelist, logs table only 43 MB	PRAGMA incremental_vacuum — auto_vacuum is already INCREMENTAL but never run (openai/codex#35823)
Codex	old store path left behind after a migration	~/.codex/sqlite/logs_2.sqlite, 167 MB, last written 2026-06-15	detect superseded store locations
Hermes	one-shot pre-update snapshot	state-snapshots/20260717-…-pre-update, 1,008 MB	flag one-shot upgrade backups — this one contains .env and auth.json, so it can't be silently removed
Grok (not a supported source)	every tool_call_update carries the whole accumulated output instead of a delta, stored twice per record	one session file 2,287 MB, of which 1,019 MB is the duplicated field alone; collapsed to 350 MB	fold each toolCallId to its final event

On the Grok one: a blanket "keep the last event per tool call" is not safe. I checked, and the prefix property only holds for 66% of tool-call groups. One group with 8,359 events and 256 MB looked identical to the pathological ones but was carrying genuine deltas from a render log. Any collapse that ships has to prove the property per group and default to dry-run.

A blind spot in Session Bench

S1/S2/S3 measure format leanness on a controlled probe and on corpus composition. OpenCode passes both gates it was scored on — yet 96% of its event table is superseded snapshots and people are hitting 50 GB stores.

Neither gate can see it. The redundant snapshots live under content keys, so S2 counts them as real work product; each individual record is under 25 KB, so S3 passes. What actually fills disks is how many times the same bytes get re-stored across a session's lifetime, which is orthogonal to both. Hermes passes S2 for the same reason.

Hence a possible fourth Signal gate — S4 · Superseded share: the fraction of stored bytes a lossless collapse would remove, measured on real corpus, with something like a ≤ 20% floor. scripts/session_bench/measure.py and evaluate.py already provide the harness, and the numbers above could seed the first pass. It measures what users feel rather than format elegance, which feels in keeping with the rest of the bench.

Two things in the archive path that would block reclamation

If reclamation ever reuses SessionArchiveManager — copy out, verify, then remove upstream — two current behaviours are in the way. Both are correct for what the archive does today:

1. hashIfSmall() caps integrity hashing at 128 KB (sizeBytes <= 128 * 1024, "Hash only small files to keep sync lightweight"). Fine for sync, but it leaves large archives unverified — and large sessions are the only ones worth reclaiming. The cap would need lifting for sessions explicitly marked for reclamation.

2. trashItem is wired to the archive, not upstream. It sits in deleteArchive() and removes sessionRoot under Application Support. The reversible-delete pattern is established; it just points the other way.

Risks

• Trust posture. Today the app is effectively read-only on upstream session data. Once it can delete, a bug's blast radius goes from "displayed wrong" to "history gone". Non-negotiables would be dry-run default, Trash rather than unlink, and a verified archive before anything upstream is touched.
• Concurrency is real, not theoretical. Doing this by hand I hit a live process holding a session file and had to skip it. Anything that reclaims needs liveness detection first — "Live sessions only" filter hides running Claude Desktop chats #53 suggests there's already some notion of live sessions to build on.
• SQLite is much riskier than JSONL. A JSONL rewrite is temp-file-plus-atomic-replace. OpenCode and Hermes are live databases where DELETE + VACUUM can contend with another process. There's good prior art in #33356: read-only VACUUM INTO a temp file, parity-check row counts across message / part / session / event / todo, then swap.
• "Lossless" needs defining in the UI. Folding intermediate events preserves every byte of output but drops the per-event timestamps — lossless for replaying final state, lossy for "how long did each phase of this command take". Worth saying which.

Suggested sequencing

1. A storage rollup in Analytics. Read-only and useful on its own. Mostly aggregation, since Session.fileSizeBytes is already a first-class field with a sort column — though the Codex and Claude paths don't appear among the indexers that populate it, so coverage may need a look first.
2. S4 in the bench. Smallest scope, existing harness, and it pins down the definition of "superseded bytes" that the product side would reuse.
3. Per-source diagnosis. Report reclaimable bytes per session and name the rule that produced the number. Still read-only.
4. Reclamation, narrowest form first. Only "archived and hash-verified → move upstream to Trash". No format-internal surgery, pure file-level. In-place collapse — especially against SQLite — deserves its own thread later.

Happy to contribute measurements, fixtures, or a PR for whichever slice is actually wanted, and equally happy to be told parts of this are out of scope. If a more useful starting point is adding Grok as a source instead — it's absent today and it's the worst offender I measured — I'd be glad to start there.

[jazzyalex]

Thanks — this is the most careful measurement anyone has brought here. I checked every claim that touches this repo before answering, so this is long; the short version is at the bottom.

Your measurements

• OpenCode / Codex freelist / Codex stale store / Hermes snapshot — all consistent with what I see, and both upstream issues (anomalyco/opencode#33356, openai/codex#35823) are open and say what you say. These four are upstream bugs; the most useful thing this repo can do is measure them loudly. More on that under S4.
• Hermes pre-update snapshot — agreed it can never be auto-removed: it holds .env and auth.json. The most the app should ever do there is show it with the reason it's not touching it.
• Grok — the 66% prefix-property finding is the most important number in the post, and it's why I won't accept any "keep last event per tool call" rule anywhere, including as a bench definition. A collapse that must be proven per group isn't a format property; it's a per-file audit. Also: Grok is a supported source now — your own feat(grok): add Grok CLI as a session source #55 — so the "start with Grok instead" branch is already done.

Your reading of the bench

Correct. S2 counts anything under a content key, S3 caps the individual record at 25 KB, and superseded snapshots are small and content-keyed. OpenCode and Hermes pass both honestly by the rubric and still fill disks. That is a rubric gap, not a scoring error, so it goes through a version bump and the corrections log rather than a quiet re-score.

Your two archive-path findings

Both verified: hashIfSmall() returns nil above 128 KB (SessionArchiveManager.swift#L852), and the only trashItem call removes sessionRoot inside deleteArchive(). Accurate — but see below, neither needs to change.

One correction

Session.fileSizeBytes is populated for Codex and Claude. It's set in the parsers, not the indexers you grepped: SessionIndexer.swift around L2100/L2174 for Codex, ClaudeSessionParser.swift L133 for Claude. Every source fills it, so an Analytics rollup is pure aggregation — no coverage work first.

Your risks, one by one

• Trust posture — this is the decider. Agent Sessions reads other tools' data and never writes to it, and that single fact is most of why people let it near their history. "Dry-run default + Trash + verified archive" makes reclamation safe; it doesn't make it this app's job. I'm not taking reclamation in any form — not in-place collapse, not SQLite surgery, and not the narrowest "archived + hash-verified → upstream to Trash" either, because the trust contract is app-wide, not per-feature.
• Concurrency — you're right that liveness exists ("Live sessions only" filter hides running Claude Desktop chats #53, and the Devin work just added a fail-closed rule for partially-written stores). It's built for reading safely; I'd rather not turn it into a precondition for deleting.
• SQLite — agreed on all points, which is exactly why the VACUUM INTO + parity-check work belongs in opencode/codex where the store is owned and the write lock is theirs. Your numbers are the ammunition for those issues.
• "Lossless" in the UI — the distinction you draw (final-state-lossless vs timestamp-lossy) is the right one, and it's the reason S4's evidence string has to name the rule, not just the percentage.

What I'd take, in order

1. S4 · Superseded share in Session Bench — PR welcome. New gate in scripts/session_bench/measure.py + evaluate.py, measured on real corpus, evidence string names the collapse rule per source, bench version bumps, corrections-log entry, tests alongside test_evaluate.py. Constraint: only rules that are provably lossless for the whole source qualify (OpenCode newest-snapshot-per-message, Codex freelist yes; Grok tool-call folding no, per your own finding — it should score not_run with that reason). Seed it with your numbers.
2. Storage rollup in Analytics — read-only, separate PR after S4 lands, so the product side reuses the bench definition instead of inventing a second one. Bytes per source, largest sessions, and where S4 applies, "N MB reclaimable by rule X — upstream issue Y". Flagged-but-untouchable items (the Hermes snapshot) shown with the reason.

Not taking: steps 3→4 as reclamation, the hash-cap lift (only needed for reclamation), and any format-internal rewrite.

If that sequencing works for you, open the S4 PR against main, bench scripts + docs only, so it lands fast. Happy to sanity-check measurements or fixtures in this thread first.