digora
← articles · · 6 min read

One question I ask my coding agent before closing every session, and what it caught in 68 runs

TL;DR: Before I close or /clear a Claude Code session, a hotkey I press types /substantial. The agent answers one question, “Is there anything else substantial that is worth saving for later from the context of this session?”, and lists candidates, one line each, with where each would go. I pick, and only my picks get saved. Some stats over the last 2 weeks: 68 runs, 53 of them offered something, 135 candidates in all. The surprise was that about one candidate in five was a correction to a note I already had, which the prompt never asks for.

And these corrections might just be what prevents my saved notes from turning into a mess as time goes on.

What was about to be lost

The work itself is usually recorded already, in a commit, a README or a plan. What gets lost is everything around it. Across the 135 candidates there were 51 open items or “todos”, 41 facts that took effort to find, 27 stale notes, 8 rule proposals and 8 pointers to files. Some real ones, generalized:

Stale notes (in 25 of the 53 runs that offered anything)

  • A memory note said a feature branch was unmerged, with three unpushed commits. It had been merged and pushed that morning. The next session would have reported it as pending, or tried to merge it again.
  • A to-do step said to re-run a sync script that had been retired two days earlier.
  • My cost note said a cold resume costs as much as 40 warm turns, because it assumed the whole context gets rewritten to the cache. That day I measured that the first ~26k tokens (system prompt and tools) stay cached across sessions. So a 100k-token session on Opus costs about $0.60 to resume cold, not $0.80: 30 warm turns, not 40. For a 50k session the old note was off by 2×. Every later “is it worth keeping this session warm?” estimate would have repeated the error.

These came up because the agent, while checking whether something was “already saved”, opened the note and saw that it was wrong.

Facts and open items

  • A cloud worker launched with --model opus actually ran an older Opus, because the alias resolved differently there. That was in a cost report, not in the note that the next launch reads.
  • Background sessions refuse edits after a single cd into a git repo, because the isolation guard keys on the working directory. Writes through other tools kept working, which made it confusing to debug.
  • A config-check template didn’t know about a key I had just added. Reinstalling it would have stopped a bot from starting.

Rules, proposed rather than written: “keep each shell command short enough to read in the approval prompt”. The agent named the file and the wording, and I said yes.

Alternatives, and what they cost

  • Built-in auto memory applies the same filter after turns: is this useful later, and can it be read from the code instead? But it doesn’t ask, and as far as public notes on its code show, it writes only into its own memory directory. My stale to-dos, plans and READMEs are outside its reach, and so are rules.
  • save-before-compact is the closest published design to /substantial. It’s a Claude Code skill you run right before compacting or clearing. It runs the same sweep: what is worth keeping that isn’t already in the repo, a file or memory. It routes each item, so facts go to memory and decisions to project files. The difference is who chooses. save-before-compact writes everything it judges worth saving on its own, then shows a receipt of what it saved and what it left out on purpose. /substantial lists the candidates and saves only the ones I pick.
  • /compact focus on … keeps chosen things in the summary, but not in a file the next session will find.
  • A hook at exit can’t do it. PreCompact and SessionEnd can run a shell command, an HTTP call or an MCP tool, but not a prompt, so they can’t make the model take a turn.
  • Reviewing transcripts later with a cheap model. I measured this from the logs, at API list prices. My 68 runs with logged usage cost $20.70 in total, a median of 19¢ each. Feeding the same contexts (median 92k tokens) to a fresh model would cost at least $14.99 with Sonnet, input only. So in tokens, a batch review is not more expensive. What it loses is the timing: I’m not there to pick, the reviewer doesn’t know which notes the session just made wrong, and a list I read tomorrow is exactly the kind that doesn’t get triaged.

One practical finding: 20 of the 68 runs came after the session had sat idle past the 1-hour prompt cache, and those 20 cost $13.39, two-thirds of the total. It’s better to ask before you walk away, not when you come back.

So I automated the case where I forget. My background sessions over 10% of the context window keep the cache warm on their own: a scheduled ping every 30 minutes, four times, which keeps the cache alive for about 2.5–3 hours after my last reply. The last ping now also asks the question, while the cache is still warm: one more cached read instead of a cold rewrite later. Nobody is there to pick, so it only lists and writes nothing. When the idle session is closed, the list goes into a log, and my memory review walks every list nobody answered.

Attention is the real cost

The question costs one model turn, but it also costs a person turn. From the timestamps, the median time from list to pick was 66 seconds (the middle half between 31 s and 2.5 min). That adds up to about 80 minutes over 14 days, around 6 minutes a day.

That’s the expensive part of the setup. A Max plan is $100 or $200 a month. Six minutes a day is roughly 2–3 hours a month (what’s your hour worth?): at $60 an hour, that is more than the $100 plan. Tokens are not the scarce resource; attention is. I spend it here because this is the point where I am able to spend it most efficiently. Both the agent and I still have the context, and a wrong note costs a re-discovery later: another session, another measurement.

So it sits in a ritual. Three hotkeys sit side by side: one asks the question, one says “agreed”, one ends and closes the session. “Review, then close” is one motion. A separate memory review catches what slips through (I might write about that later).

Why isn’t this built in? A guess, not a fact

A prior-art review I had a model run assumed this: Anthropic designed memory as the agent’s own notebook, kept the person out of the write path, and doesn’t want to cost you a turn of attention. The one piece of evidence I trust is that a memory-write confirmation dialog exists behind a disabled flag and hides itself after 8 seconds (that is someone else’s reading of the shipped code). The rest is inference: requests for an exit hook were closed as stale or duplicate, which isn’t a “no”, and I found nothing from Anthropic on the why. The plainer explanation may be that nobody has asked for this exact combination: requests exist for each part, but not for a list with destinations that you pick from at the end.

Limits

One person and 14 days. A script counted the runs; one model sorted the candidates into kinds, in a single pass. I haven’t measured how often I’d skip the question without the hotkey; that is a guess. The automatic review on the last keep-warm ping is new this week, so none of the numbers above include it.

References

Drafted with Claude (Opus 5.5). Edited and fact-checked by me.

Corrections and questions: kurdalaegon@digora.dev