CPR: a persistent memory plugin for Claude Code sessions

What the plugin is, in the README's own terms

CPR is a Claude Code plugin. It adds three slash commands and two hooks, and the name stands for Compress, Preserve and Resume.

The five pieces are listed in a table, and the division between them is the design.

- `/cpr:compress` writes a structured, searchable session log, and a script appends the raw transcript - `/cpr:preserve` updates CLAUDE.md with the learnings every future session should start with - `/cpr:resume` loads recent session summaries and searches past sessions by topic - the PreCompact hook saves the raw transcript before every compaction, manual or automatic - the SessionStart hook hands the model a short memory brief when a session starts or compacts

Two properties follow from that split, and they are the ones to understand before installing anything. The skills are where the curated summaries come from, and they are the part you invoke deliberately. The hooks are the safety net for the sessions you forget to save, and they run without you asking.

The engineering constraints are unusually mild for a plugin. The README states there is no build step, no dependencies beyond Python 3.10, and that every file is plain markdown or a small script you can read. The top level of the repository matches that claim, with a .claude-plugin/ directory for the plugin manifest, skills/ for the three commands, hooks/ for the two hooks, scripts/ for the Python, docs/, tests/, examples/ and videos/, plus an llms.txt file at the root.

The project is MIT licensed, the default branch is main, and the last push to the repository was on 2026-09-09.

The problem it addresses, and the one it does not

The problem section starts with a flat statement: Claude Code has no memory of the work between sessions. When you close a conversation, the decisions, the fixes, the paths and the reasons go with it.

The table of compounding problems is worth reading, because it separates the complaints that are actually the same complaint.

Compaction flattens details, so when the context window fills up, history is summarised and specific values, file paths and nuanced decisions get lost. Long sessions lose early context, with the critical decision from the first ten minutes gone by hour two. A new session is a blank slate, so you re-explain your project, re-discover paths and re-make decisions every time. Past work is unsearchable, so there is no way to look up what you discussed three sessions ago. And CLAUDE.md and auto memory are not enough, because they hold instructions and preferences rather than the state of the work, the errors, or the solutions.

That last row is the one that matters for evaluating CPR, because it explains the positioning in the next section. CPR is not proposing to replace CLAUDE.md or Claude Code's own auto memory. It is proposing to sit beside them.

The Is CPR For Me section is unusually clear about the exclusion, and the exclusion is the reason to read it. It is for you if you work on the same project across several Claude Code sessions and find yourself re-explaining what happened last time, or if you want the full conversation kept on disk and searchable by topic rather than flattened into a compaction summary. It is not for you if your sessions are one-off fixes or throwaway scripts, because there is no next session to pay the save back.

That last clause is the honest framing of the whole project. The value of a memory is proportional to how often you come back to it.

How the three memory stores differ

The comparison table between CLAUDE.md, auto memory and CPR session logs is the clearest statement of the design, and each column answers a different question.

CLAUDE.md holds instructions and conventions, and is written by you and by `/cpr:preserve`. It is shared with the team, via git, and it is not searchable by topic.

Auto memory holds preferences and corrections, and is written by Claude Code itself. It is not shared with the team, because it is machine-local, and it is not searchable by topic either.

CPR session logs hold decisions, fixes, errors, pending work and the full transcript, and they are written by `/cpr:compress` and by the hooks. They are shared with the team if you commit the CC-Session-Logs/ directory, and they are searchable by topic with `/cpr:resume <topic>`.

So the three stores are not three versions of the same thing. One is what you want the assistant to know every time, one is what the assistant has learned about how you like to work, and one is what happened. The value of the third is that it is the only one that is a record rather than a set of instructions, which is why it can be searched by topic and why it can hold the errors and the pending work, which instructions are the wrong shape for.

The flow in the README shows the timing, and it is the part that explains the two hooks.

During work  ──> PreCompact hook  ──> raw transcript autosaved before any compaction
End session  ──> /cpr:preserve    ──> CLAUDE.md updated (optional)
                 /cpr:compress    ──> curated session log saved
New session  ──> SessionStart hook──> latest Quick Resume Context injected automatically
                 /cpr:resume      ──> last N summaries + topic search ──> full context restored

The PreCompact hook sits inside the working session, so the raw transcript is captured before a compaction can flatten it. The SessionStart hook sits at the beginning of the next session, so the memory brief arrives without you having to ask.

The auto-compact change, and the two release lines

The section on working with auto-compact records a change of policy, and it is the sort of thing that only shows up in a changelog.

Earlier versions of CPR told you to disable auto-compact. You no longer need to. The PreCompact hook now runs before both the manual `/compact` command and automatic compaction, receives the transcript path from Claude Code, and writes one autosave log per session into the CC-Session-Logs/ directory. After compaction, the SessionStart hook puts the latest Quick Resume Context back into context.

The improvement is real but bounded, and the README is clear about the boundary. You still get the best results by running `/cpr:compress` before `/compact`, because that is where the curated summary comes from. The autosave only guarantees that you never lose the raw conversation.

That distinction is the whole design in one sentence. The hook path is a safety net that costs nothing and runs by default, and the skill path is the one that produces something a human wrote. If you only ever let the hooks run, you have transcripts and a brief. If you run the compress command, you have a summary.

The release history shows the same progression. v1.1.0 in May 2026 is labelled token savings, proven analytically. v1.2.0 in September 2026 is labelled raw session log by script, zero output tokens, which is the autosave path arriving without spending tokens on a summary. And v2.0.0 in September 2026 is CPR as a plugin, with hooks that save and restore automatically, which is the packaging change that makes the whole thing installable with one line.

The v1.2.0 note about zero output tokens is worth pausing on, because it describes a design choice rather than an optimisation. The autosave path writes the transcript to disk with a script, and it does not ask the model to summarise anything, so it costs nothing in tokens. The cost moves instead into storage and into the SessionStart hook, which has to read something and put it in context.

The token claim, and what kind of claim it is

The savings figure is stated in the header and again in the Why It Saves Tokens section, and the wording is careful in a way that is easy to miss.

The header says an estimated ~66% reduction in session-restart token cost, with an analytical model and a range of 51-74 percent. The badge says ~66% median. So the number is presented as an estimate from a model, with a range, and not as a measurement.

The reasoning behind it is in the README: re-establishing context at the start of every session is expensive, because the user re-explains the project, Claude re-reads files, prior decisions get re-derived, and conversations rebuild from scratch. The claim is that CPR replaces the rebuild with an injection of a short brief, and the saving is the difference between those two costs.

That is a sensible model, and the direction of the claim is not in doubt. What a reader cannot get from the README is a before and after on real sessions, which is why the analytical label matters. The 51 to 74 percent range is wide, and the percentage will depend entirely on how large the project is, how many decisions were made, and how much of the previous session was actually worth restoring. A session that was mostly reading files will compress well. A session with a long design discussion will not.

The design decision that makes the saving work at all is that the hooks do not spend tokens. The PreCompact hook writes the raw transcript to disk with a script, and the SessionStart hook injects a short brief rather than the whole history. So the model is not asked to re-summarise on every session, and the only token cost is the brief itself.

Installation, usage, and what the README does not say

The README has an Installation section and a Usage section, and both are in the table of contents with anchors, but the text available here stops before them, so the specific install command and the recommended workflow are not in the documentation you can read here.

What is stated about installation is that it takes one line, and that removing it is a plugin uninstall command.

/plugin uninstall cpr@cpr

The usage surface is the three slash commands themselves, and the recommended workflow section is anchored separately from usage, which suggests the two differ. The commands are the ones already listed: `/cpr:compress`, `/cpr:preserve` and `/cpr:resume`, with `/cpr:resume <topic>` for the topic search. The SessionStart hook takes no arguments, because it is automatic.

Two questions the documentation here does not answer are worth raising before you install. The first is what the Quick Resume Context actually contains and how long it is, since that is the part injected into every new session and therefore the part you pay for every time. The second is what the log format is, beyond the existence of an examples/session-log-example.md file, since a structured log you can grep and a log you can only read are different things in practice, and the searchable-by-topic claim depends on the format.

The repository layout suggests the answers are in the skills/ and hooks/ directories, and the claim that every file is plain markdown or a small script means the answer is a directory listing away rather than a reverse engineering exercise.

Where CPR is the wrong choice

Three cases point elsewhere. The first is a developer whose sessions are short and unrelated, which the README rules out explicitly. There is no next session to pay the save back, and the plugin would be adding hooks that run on every compaction and every session start for a workflow that never repeats.

The second is a team with a sensitive codebase and a strict data policy. The session logs hold the full transcript, the errors and the pending work, which is exactly the content a security review would want to see kept out of a repository, and the README's answer is that you commit CC-Session-Logs/ if you want the team to have it. The plugin therefore defaults to writing transcripts, with the hard disk and the remote model provider as the places that data ends up, and a team that has to answer for that needs to make the decision deliberately rather than discover it later.

The third is a user who wants a measured saving rather than an estimated one. The 66 percent figure comes from an analytical model with a 51 to 74 percent range, and if the case for the plugin rests on a number, that number has to be measured on your own sessions, which the plugin does not do for you.

The alternative worth comparing is writing the summary yourself, and the difference in approach is instructive. The `/cpr:preserve` command updates CLAUDE.md with the learnings that should carry into every future session, and you are the one deciding what those are. That file is versioned, reviewed and shared with the team, which is what you want for decisions that other people need to know. CPR session logs are the opposite: a private, growing, unedited record. The two serve different purposes, and a team that wants both is not choosing between them.

For a developer working alone on a long-running project, the honest comparison is with no plugin at all, because the built-in auto memory and CLAUDE.md already cover instructions and preferences. What CPR adds is the layer in between, the state of the work, and for a solo developer who keeps re-explaining their own decisions, that is a real saving on a real cost.

Editorial conclusion

CPR fits a developer who works on the same project across many Claude Code sessions and keeps losing the reasoning behind earlier decisions, and who is willing to commit session logs to a repository. It does not fit a developer whose sessions are one-off fixes, which the README says explicitly, and it does not fit anyone who needs a measured token saving rather than an estimate. Before you install it, read the Why It Saves Tokens section closely, because the figure is an analytical model with a stated range of 51 to 74 percent, and check what the SessionStart hook injects into your context before every session, since that is the part you pay for on every run.

Frequently asked questions

Official sources

1. EliaAlberti/cpr-compress-preserve-resume on GitHub
2. Issues
3. License: MIT
4. README
5. Releases