Auto-compaction takes 2-7 min, fires 89x in one session, and kills the thread - 3h49m of wall clock lost to compacting alone

What happened

My thread fucking died trying to compact. Again. And I want my tokens back for it.

This is not a vibes complaint. I pulled the numbers out of my own session transcripts and compaction is eating entire working days.

The data

From ~/.claude/projects/<project>/<session>.jsonl, counting only lines with "subtype":"compact_boundary" and reading compactMetadata.durationMs:

Session 7d178f49 — 243,821,341 bytes, 63,881 lines, spans 2026-06-06 → 2026-09-15

| metric | value |
|---|---|
| compactions in ONE session | 89 (86 auto, 3 manual) |
| min compaction duration | 106.1s |
| median compaction duration | 137.4s |
| max single compaction | 435.0s (7m 15s) |
| total wall clock spent compacting | 228.9 minutes (3h 49m) |
| preTokens median / max | 169,155 / 1,001,208 |

And it is not a one-off. Two other sessions on the same machine:

| session | size | compactions | total compact time | worst single |
|---|---|---|---|---|
| cdaefb98 | 84.5 MB | 49 | 149.6 min | 339.2s |
| 8b3ac8ef | 416.5 MB | 27 | 42.4 min | 188.6s |

Across three sessions: 165 compactions, ~7 hours of wall clock spent doing nothing but compacting.

Why this is a billing problem, not just a UX problem

Every single one of those 89 compactions re-reads and re-summarizes the conversation. I pay for that. Then the thread dies mid-compact and I lose the context I just paid to have summarized — so I pay again to rebuild it. I am being charged twice for the privilege of losing my own work.

A median of 137 seconds is already unusable. 435 seconds is a coffee break. Doing it 89 times in one session means compaction is not an edge case in my workflow, it is my workflow, and it's fucking broken.

What I think is actually wrong

• Auto-compact triggers at ~168K preTokens over and over instead of doing something durable, so long sessions just grind in a loop.
• Compaction cost appears to scale with the whole transcript, and these transcripts hit 243MB and 416MB. Nothing that reads a 243MB JSONL on every compact is going to finish fast.
• There is no crash recovery. When it dies mid-compact, the work is gone. There's no resume, no partial summary saved, nothing.

What I want

1. Fix it. Compaction should not take 2–7 minutes, and it absolutely should not be able to kill the thread it's supposed to be saving.
2. Make it crash-safe — if compaction fails, fall back to the pre-compact state instead of nuking the session.
3. Refund the tokens. I want the tokens back that got burned on compactions that died and on re-summarizing the same conversation 89 times. I'm paying for a feature that is actively destroying my work.

Environment

• Claude Code on Windows 11 Home 10.0.26200
• Sessions above are real, on-disk, and I can provide compactMetadata dumps if you want them.

Sorry for the language but I'm several hours and a lot of money into this and "compaction killed my thread" has happened more than once. Fix the fucking compactor.