[BUG] Session transcripts re-materialised on every compaction — 5.71x write amplification measured (10.89x in heavy sessions); is this re-billed?

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 0 comments · opened Jul 29, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report
  • [x] I am using the latest version of Claude Code

What's Wrong?

Each compaction or resume causes the client to write a session's history into the transcript store again. The same logical record — identical uuid — appears many times in one file.

Measured across an entire store (67 top-level sessions, 3,146 files, 5.39 GB, 37 days of use):

| | |
|---|---|
| Records written | 1,454,196 |
| Distinct records (by uuid) | 254,772 |
| Write amplification | 5.71× |
| Sessions exhibiting it | 21 of 67 |
| Most copies of a single record | 30 |

It scales with compaction count, which identifies the mechanism:

| Compactions in session | Mean amplification |
|---|---|
| 1–10 | 1.28× |
| 11–50 | 2.77× |
| 51–150 | 5.76× |
| 150+ | 10.89× |

Control

Subagent transcripts (<session>/subagents/**) are written once and never resumed or compacted. Scanned separately across 3,079 files, every pattern shows exactly 1.00× — no repetition at all — while the same patterns in top-level sessions run 4.8×–14×. The amplification appears only where compaction and resume occur.

Repro

import json, collections, glob, os
for f in glob.glob(os.path.expanduser('~/.claude/projects/*/*.jsonl')):
    c = collections.Counter()
    for line in open(f, encoding='utf-8', errors='replace'):
        try: c[json.loads(line).get('uuid')] += 1
        except Exception: pass
    reps = {u: n for u, n in c.items() if u and n > 1}
    if reps:
        print(os.path.basename(f), 'max copies:', max(reps.values()))

The actual question

This measures client-side transcript re-writes, not billed API re-sends. I am not claiming they are the same number — I have no visibility into what is charged.

But a user has no way to determine whether history re-materialised eleven times is billed eleven times, because there is no breakdown of productive versus rework spend and no in-product route to billing. Given the volume of reports about unexpectedly fast quota consumption (#16157, #38335), this seems worth answering explicitly rather than leaving users to infer it.

Expected Behavior

  1. Confirmation of whether transcript re-materialisation corresponds to billed re-processing.
  2. A rework/retry line in usage reporting, so re-grounding after compaction is distinguishable from productive work.

Related

#81065 (compress transcripts on disk), #82144 (post-compaction re-injection cost ~4× the summary), #81843 (transcript writer corruption) — all adjacent; none measures the multiple or asks the billing question.

Environment

  • Claude Code CLI 2.1.220
  • VS Code extension 2.1.220
  • Linux (Debian)

View original on GitHub ↗