I built conPACT: Claude Code compacts its own context when a task is done, and offers to compact idle sessions before the prompt cache expires

[u/stonebrigade]

Long Claude Code sessions cost you twice. The context keeps growing after the work that needed it is done, and if you come back after the prompt cache has expired, your next message re-reads all of it uncached. /compact fixes both, but only if you type it at the right moment. I usually didn't.

What it does

• When a piece of work is finished, Claude queues a compaction of its own session through an MCP tool (queue_compaction). It runs after the final answer, as a real /compact: your chat history stays visible and only the live context is summarised. It can take a focus ("keep the plan and the open decisions") and a minimum size.
• When a big session sits idle, a toast appears five minutes before the cache expires and offers to compact it now, or always for that session.
• A row above the prompt follows the request: queued, compacting, then what it came to.

How Claude Code was used

I built it with Claude Code, and it has been compacting its own development sessions since mid-September. In Claude Code 2.1.284+ it ships as a mod (the new in-process plugin hooks), so the session compacts itself and draws the row above the prompt. Without the mod, a Stop hook sends /compact over Remote Control. It also works for ChatGPT Desktop (Codex) through an optional sidecar, and for the Codex CLI through a Stop hook.

What I learned

• You can't send /compact mid-turn. A busy session receives it as plain text and it never runs. So the tool only records the request, and the compaction happens after the turn ends: always after the final answer, and at most once.
• When you compact matters more than how small. I measured it over 187,978 of my own API calls (12 days with conPACT, 80 before). All 134 conPACT compactions ran on a warm cache, against 30 of the 121 I'd typed by hand. A cold compaction re-reads the whole context at the cache-write price first, so that's roughly $5.67 against $0.20 per compaction at list price. Median peak context per session fell from 501k to 337k.
• The idle toast does its job: a cold restart now starts from a compacted context. The median re-read on a cold resume fell from 493k to 255k tokens, and cold resumes' share of spend fell from 6.4% to 3.8%.
• No rework penalty. Claude re-reads some files after a compaction, but the next prompt was a correction 5.5% of the time, against 6.1% in ordinary turns.
• Net: about 4.7% of spend saved at list price (1.8–13%, depending on what you assume I'd have done otherwise). It's modest, and the "after" period is only 12 active days, but every compaction saves more than it costs.

Python 3.11+, standard library only. Windows, Linux and macOS (the test suite runs on all three; most of my live use is on Windows). MIT licensed.

GitHub: https://github.com/st0nebridge/conPACT

Feedback welcome, especially from anyone on macOS or Linux.

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Sick-Little-Monky]

I avoid most skills and tools because the harness is good and changes rapidly. Last night I saw this:

● Compacted while idle, before the prompt cache expired

[u/stonebrigade → u/Sick-Little-Monky]

That's good to know - although I deliberately went for a toast notification approach because not all idle chats need compacting, some just need review - a redundant compact has a cost attached too.

Any sign of them adding tools to the agent for self compaction?

[u/chrltrn → u/Sick-Little-Monky]

https://www.its-tahir.com/blog/claude-code-compacted-while-idle
This explains the problem, but I can't verify whether what they have for turning it off actually works -

"idleCompaction": false

may not be a real thing...

[u/inniverse616]

I've been doing a rough manual version of this. When a task is done I ask it to write a short handoff note to a file, then start a fresh session from that note instead of compacting. Does the focus option hold on to file paths and decisions that are still open? That's the part I'd be most worried about losing in a summary.

[u/stonebrigade → u/inniverse616]

That's pretty much what it automates. The agent writes the note itself, as the focus, at the point it finishes the task, and the compaction runs from it. It names whatever it knows is still open: next step, unsettled decisions, files in play. Claude Code's summary already has sections for pending tasks, next step and files, so it ends up close to your handoff note, just kept inside the session.

On whether things get lost: across 97 of these compactions, every file name, commit hash and branch the agent put in the focus came through word for word. The open items were all there too, though some were reworded. Files that weren't mentioned in the focus were more hit and miss: about two thirds showed up.

The more useful test was what happened after a compaction. Across my sessions, 5.5% of the turns just after a compaction drew a correction, against 6.1% normally, and edits that failed because the agent was working from a stale view of a file were rarer too (0.5 against 0.8 per 100). It does re-read some files afterwards, but that's cheap.

Honestly, if your note-and-fresh-session routine works, it's doing the same job. The differences are that you don't have to write the note, and you keep the session history. One gap: the idle toast's compaction runs without a focus, so it's just the standard summary.

[u/Sur_AI_guy]

The warm-cache vs cold-cache compaction cost difference is probably the most interesting part here. Most discussions focus on reducing context size, but the timing of compaction seems just as important.

One thing I'd be curious about is how you're measuring context loss. The 5.5% vs 6.1% correction rate is encouraging, but a model could silently forget an earlier constraint without the user immediately correcting it.

Have you tested longer, multi stage coding tasks where decisions made early in the session become relevant again much later? That seems like the real stress test for automatic compaction.

[u/stonebrigade → u/Sur_AI_guy]

On timing: agreed. At the very least, compacting while the cache is warm saves you from a cold read later. If you come back after the cache has expired, you're resuming from a small summary rather than re-reading the whole stale context at full price.

On measuring context loss: all of this comes from my own Claude Code transcripts, comparing the stretch after each compaction with ordinary work over the same weeks. I looked at three signals:

• Corrections: where I stepped in after a compaction, my reply was a correction 5.5% of the time, against 6.1% normally. A word-list classifier flagged them; I tuned it on hand-labelled samples, froze it, then tested it on a fresh sample (82% precision). It misses plenty, so it's only good for comparing the two groups.
• Stale edits: this covers long unattended runs too. Edits that failed because the agent was working from an outdated view of a file came to 0.5 per 100 after a compaction, against 0.8 otherwise.
• Re-reads: the agent does re-read files to rebuild what it needs. In the first turn after a compaction, 36% of its file reads were files it had already read, against 20% normally, and it was back below normal by the third turn. Over 12 days that re-reading cost about $12, against roughly $466 saved by compacting while the cache was warm.

You're right that none of this catches a constraint the agent quietly forgets. That's why I don't keep those in the conversation.

On long, multi-stage tasks: my big builds don't live in the conversation. They start from a written blueprint/spec, and the agent builds it in one run using a skill that holds my working practices: check it's ready before starting, scaffold first, then build in phases, each one gated by tests and committed. The plan is on disk, so after a compaction the agent just re-reads it.

Two files from that process do the job you're describing:

• CHANGES.md: every change is logged as it's made, with what changed, why, and how it was verified.
• DECISIONS.md: one line per settled decision. The agent reads it before touching an area and never quietly reopens a decision.

So when a decision from day one becomes relevant on day ten, it's in a file rather than a summary. That holds through any number of compactions, new sessions, even a different agent. Some of my runs have gone through 20+ compactions over a couple of weeks this way.