The hard part of keeping AI coding sessions isn't the save decision. Saving is cheap and mostly right: you've just finished a three-hour debugging conversation, you can still feel which parts mattered, and the file costs a few kilobytes. The decision nobody plans for arrives much later, when you open the project after a quiet stretch and find forty transcripts in .prjcontext/sessions/, none of them read since the week they landed. That's the moment you need to prune AI coding sessions, and it's also the moment you have the least idea which ones still carry anything.
So the advice to "keep the sessions worth keeping" is only half a policy. A kept session has a shelf life. It stays useful until its reasoning gets written down somewhere shorter or the code it describes gets replaced, and after that it is weight: one more thing in the folder, one more file a new teammate scrolls past, one more candidate when you're hunting for the conversation where you actually decided something.
Keeping it was never the finish line
The value of a saved transcript is entirely in retrieval, and retrieval gets worse as the pile grows. Ten sessions with dated, descriptive filenames are browsable. Forty are not, because the cost of finding the right one starts to exceed the cost of just asking the assistant to re-derive the answer. At that point the archive has inverted: you kept things so you wouldn't have to re-explain the project, and now you re-explain it anyway because digging is slower.
This is the same failure as a memory file that grew past the point anyone reads it, which is covered in why your decisions file needs pruning. Sessions rot differently, though. A memory entry goes wrong by being false. A session stays perfectly accurate about a past that stopped mattering.
What a session is still doing for you a month later
Be specific about the job, because that's what tells you when it's done. A kept session typically does one of four things:
- It holds the reasoning behind a choice that isn't obvious from the code.
- It records what you tried and rejected, so a fresh session doesn't re-propose it.
- It serves as the readable trail when a regression needs tracing back to where it was introduced.
- It gives a teammate the context to understand a part of the system they didn't build.
Three of those four can be done by something much shorter. A five-line decision record covers the first and second. A one-line note in memory pointing at a commit covers the third most of the time. Only the fourth sometimes genuinely needs the full conversation, and even then the reader usually wants the summary first.
Prune AI coding sessions once the decision has a home elsewhere
Here is the rule worth applying. Open the session and answer one question: if this file vanished tonight, what exactly would I lose?
If the answer is a sentence or a paragraph you could write down right now, that's not a reason to keep the session. That's a reason to write the paragraph and then delete the session. The transcript was the raw material; the decision record is the product. The session to decision record workflow is the step most people skip, and skipping it is why the folder keeps growing: nothing ever graduates out of it.
If the answer is "nothing, honestly, I just remember it was a long one," delete it without ceremony.
If the answer is a specific piece of reasoning that resists compression, usually because the conclusion still looks wrong to a reader who wasn't there, keep it. That's the real test for which AI sessions to keep long term: not importance, but incompressibility.
Three kinds that are safe to delete
The promoted session. Its decision now lives in decisions.md with a date, a reason and a consequence. The transcript is a longer version of a thing you already have in a form people read. Delete it, and if you want the trail, put the version or commit reference in the decision entry.
The stale AI session. It's about a module you deleted, a library you dropped, or an approach you reversed. A stale AI session is dangerous in a mild way: someone (or an assistant, if you feed it the folder) reads it as current and reconstructs a plan you abandoned. Keep the reversal note, drop the conversation.
The mechanical one. The assistant renamed thirty files, migrated a config format, or wrote tests from an existing spec. The diff is a better record than the chat, and the chat contains nothing but confirmations.
The one kind to never prune
Keep the session behind a decision that looks like a mistake. Every project has one or two: the odd retry loop, the duplicated type, the place where you went against the obvious pattern because of something you learned at 23:00 on a Tuesday. The decision record says "chose X over Y." The transcript says what Y actually did when you tried it, which is the part that stops the next person (or the next session) from undoing the work.
These are also the sessions most worth putting in front of a colleague before the pattern spreads, which is the point of reviewing a teammate's AI session. A session that survives that kind of reading has earned permanent residence.
A five-minute pass, not a project
Don't schedule a cleanup. Attach it to something you already do. When you next touch project memory, sort the sessions folder oldest first, open the top three, and run the one question on each. Three files per pass is enough; a project that gains a session a week stays in balance at that rate.
Pruning is easier when deleting isn't destroying. In PrjLab, sessions are plain files pushed alongside the code and the memory, and every push creates an immutable version, so removing a transcript from the current state leaves it readable in the version where it last existed. You prune what the project presents today without losing the trail, which takes most of the anxiety out of the decision. The getting-started guide covers how sessions travel with a repository if you want to see where they sit.
The folder is not an archive. It's a working set, and working sets need a rule for leaving.
