I Asked Claude Code to Audit My Sessions and Suggest Mods

I watched Claude Mods Is The Biggest Claude Code Upgrade Since Skills by Chase AI, plus a few other videos on the same thing, and wanted to try a mod on myself. The cache timer and my usage being available sounded really handy (I’m always checking my remaining usage).

A mod is a small TypeScript plugin that hooks into things happening inside Claude Code (a tool call running, me submitting a prompt, a turn finishing) and can show something on screen, like a band above the prompt, a toast or a pane.

I figured I would ask Claude Code to read my old sessions and see if it came up with any other interesting ideas.

The prompt

I started from a prompt I had copied from the video, ran it, and fixed what went wrong. This is the fixed version.

I haven’t run this exact one, so treat it as a good starting point and not a tested recipe. You will want to change the list of what to look for.

Audit how I use Claude Code, then suggest mods that would fix the friction.

Load the plugin-authoring skill first, so you work from the real mod API.

Sources
- Transcripts are in ~/.claude/projects/, one folder per project, one .jsonl
  per session. Use the 30 newest across all projects, skip this session, and
  tell me how many you actually found.
- Some files are tens of MB. Don't read them whole. Write a small script that
  pulls out my prompts, the Bash commands, and any usage-limit or error
  messages.

What to look for
1. Things I ask for again and again (retries, "continue", the same
   instruction typed repeatedly, pasted-in reviews).
2. Things I check by hand: usage limits (5-hour and weekly), prompt cache
   state, git state, which files changed.
3. Commands Claude runs over and over that cost a round trip each time.

Rules
- Count everything: how many times, in how many sessions. Quote the exact
  moment. If you are inferring what I meant, say so and give the other
  reading.
- Before suggesting anything, check what the Claude app already shows or does
  (repo and branch strip, diff counts, usage-limit notifications, /context,
  /cost). Drop anything it already covers and tell me what you dropped.
- If a word in this prompt is ambiguous or doesn't match what is on disk,
  tell me what you assumed.
- Only name events and $ calls that exist in the mod types. Say what a mod
  can't do.

Suggest 5 mods. For each: name, the problem, the quoted moment with counts,
the event it plugs into, whether it acts before, after or instead, what it
shows on screen, whether it costs usage (none, or a model call), and the time
it would save, with your assumptions stated as estimates.

Rank by time saved. Don't build anything yet.

Three parts of it matter most:

• Check what the app already does first. My first run suggested two ideas the desktop app already covers (more on that below).
• Don’t read the big transcripts whole. Some of mine were over 25 MB, so it wrote a small script to pull out my prompts, the Bash commands and the limit messages.
• Count everything and quote it. The counts are what let me rank the ideas, and the quotes show whether something is a real pattern or one odd afternoon.

The rest tells it to say what it assumed and to stick to events that exist in the mod API. Mods are early access and the docs say the API moves between releases, so the types file the skill writes is the only thing that matches the version you are running.

What it found

The transcripts are in ~/.claude/projects/, one folder per project and one .jsonl file per session. I had 20, one being the session I was typing in, so it audited 19. A few of the numbers:

• 1,117 of 1,676 Bash commands started with cd
• 97 git status or git diff --stat calls, plus another 21 checking the branch or repo root
• 23 pasted-in blocks across 7 sessions, mostly another model’s review that I wanted compared with Claude’s own view
• 5 “You’ve hit your session limit” messages, with me typing “Try again” three times and “continue from where you left off” once
• 10 times a long pause meant the next response had to rewrite 50,000 or more tokens of cached context, about 5.2 million tokens in total

That last one is a rough count from the token numbers in the transcripts, not an exact figure. Some of those sessions reached 900k tokens of context, so a cold cache is not a small thing.

It came back with five ranked mods: a usage guard, an auto-resume after the limit, a repo state band, a handoff command, and one that adds my standing “compare this with your own view, don’t act yet” instruction whenever I paste in a review from another agent.

Two ideas the app already had

I then sent it screenshots of mods other people use that I thought looked useful (a bar showing how long the cache stays warm, with a handoff button, and a warning when the cache is about to go cold). While doing that I noticed the Claude desktop app already shows the repo, branch and changed line counts above the prompt, and it seemed to be including the resume idea, but I recalled Claude Code already seems to show something like this, so steered it not to include that.

That made the repo band and the auto-resume mostly pointless.

What I built

I picked the cache idea and merged it with the usage and handoff ones. It is a band above the prompt with a cache countdown, context size, an estimate of what rewriting the cache would cost, the 5-hour and weekly usage, session cost, and Handoff and Compact buttons. It also shows a toast about five minutes before the cache goes cold, and blocks Opus and Fable subagents unless I allow them.

A mod is three files in a folder under ~/.claude/dev-mods/: a plugin.json, a hooks.json and a TypeScript module. Claude Code asks once whether to enable hot reloading for the session, and after that the mod reloads whenever the turn that edited it ends.

If you write one, these caught me out:

• The validator is picky about $. claude plugin validate only lets me pass $ to functions declared at the top of the file, not ones nested inside register. Calling read($, ...) from a helper or a timer was also rejected, so I used $.state directly with the references written out as literals.
• Mods that keep state can’t be tested. claude plugin test has no $.state, so I left that to a live session.
• Command names can clash. My mod registered /handoff and I already had a /handoff skill. The engine refused it, the error was thrown inside session.start, and that skipped creating the timer behind the cold-cache warning. I moved it to /cockpit handoff and wrapped the registration so a refusal can’t skip the timer again.

Claude Code came back with this. I’ve changed one repo name and the handoff command name, which I renamed later:

What it does

• Band above the prompt: ● cache warm 41m │ ctx 109k │ rewrite ≈ $0.87 │ 5h 10% (+3%) · wk 59% │ session $1.01 [Handoff] [Compact]
  • It appears after your first turn.
  • The cache indicator turns yellow within 5 minutes of expiry and red once cold. Cold buttons show the cost, for example Compact (cold ≈ $1.23).
• Cold-cache warning: about 5 minutes before the cache goes cold, a toast shows the context size and rewrite cost and suggests Handoff or Compact. It stays quiet when a rewrite would cost under $0.25.
• Usage toasts: one when a single turn uses 10% or more of the 5-hour window, and one when the window first passes 75%.
• Subagent gate: it blocks Agent calls that ask for opus or fable, and blocks all subagents once the 5-hour window reaches 85%. Claude is told why. /cockpit allow-agents lifts both gates.
• Handoff (button or /cockpit handoff): it opens a pane with the standing rules from your own handoff prompt, a model-written summary, git status, your last three asks, and any other repos with changes. The pane has Copy and “Put in prompt box” buttons. The summary is one model call over the session’s own transcript, so it is cheap while the cache is warm.
• Compact: the first press arms the button for 6 seconds, and a second press runs it.
• Other repos: a second line, also changed: other-repo main ±3, lists repos Claude touched that aren’t the session’s own. The app already shows the session repo.
• Other commands: /cockpit hide, /cockpit show and /cockpit block-agents.

Things to check

• Cache lifetime: the engine gives no expiry time, so the clock is the end of the last turn plus the lifetime. auto starts at 1 hour and drops to 5 minutes if it sees a cold rewrite after a shorter gap.
• Rewrite price: the default is $7.50 per million tokens, a placeholder I chose. Set cacheWriteUsdPerMTok in the mod’s config to your model’s real rate, or every ”≈ $” figure will be off.
• Subagent gate: it only sees an explicit model on the call. A subagent type that picks Opus in its own definition gets through.
• Placement: the band is supported on the desktop surface, but I haven’t seen how it sits next to the app’s strip.
• Defaults I chose: since you hadn’t said, I used a 5-minute warning lead and the two-press Compact. Both can be changed in the config.

So it remains to be seen how well cache countdown works. Nothing exposes when the cache actually expires, so the mod guesses: the end of the last turn plus either 5 minutes or an hour. Not sure how useful the costings are either, so maybe I will remove them.

Try it on your own sessions

The counts were the part I would never have done by hand, like how often a pause had cost me a full cache rewrite. Expect a different list, since it depends on how you work.

Make it check what the app already does before it suggests anything, and don’t build the first thing it hands you.