I Audited My Claude Code Setup and Found 90K Tokens of Context Waste

I run five Claude Code sessions a day across three projects. Until last week I had never checked how many tokens were being consumed before I typed my first message. The number was not good.

Across my jakebauman.io, NorthSignal, and Personably projects, Claude Code was burning between 15,000 and 30,000 tokens before my first prompt. On a 200K context window, that is 7.5 to 15 percent of usable context gone before I ask for anything. Worse, I was running Sonnet sessions that capped at 128K, so the same overhead ate 12 to 23 percent of the window.

The cost adds up fast. Sonnet costs $3 per million input tokens. At 15K wasted tokens per session times 25 sessions a week, that is 375K tokens a week. A million and a half tokens a month. Not a fortune, but it compounds across every agent you run. And the real cost is not money. It is degraded output. Claude gets worse as context fills, and garbage context makes garbage decisions.

I ran the same audit on my Hermes Agent OS sessions and found a different shape of the same problem. Memory entries that described completed projects from April. Skills auto-loading reference docs I had not touched in months. Session context that repeated the same conventions every turn because I had not consolidated them into durable rules.

Here is what I found, the audit methodology I used, and the cleanup that cut per-session overhead to under 5,000 tokens.

The three things burning my context

Every Claude Code project had a CLAUDE.md file. That is the right pattern. Your CLAUDE.md is the employee handbook your agent reads at the start of every session. The problem was what I had put in mine.

1. CLAUDE.md as a dumping ground

My Personably project had a CLAUDE.md that was 1,800 words long. It included:

• A complete project history going back to the first commit
• A list of every npm package and its version
• Three different deployment workflows, two of which were deprecated
• A changelog of features shipped in January that nobody needed to reference in July
• Full API endpoint documentation that the model could have read from the codebase itself

The file had grown by accretion. Every time I learned something or fixed a bug, I added a line. Nobody ever removed anything. The document was telling my agent about problems it would never encounter and decisions it did not need to revisit.

A good CLAUDE.md does four things and stops:

1. Sets identity. Who the agent is, who you are, who you serve.
2. Gives goals. Concrete outcomes, not vague aspirations.
3. Lays out rules. Constraints, preferences, style guide, tools.
4. Maps your workspace. Where files live, what each directory is.

Everything else is either discoverable from the codebase or belongs in a skill the agent loads on demand.

This is not a theory. I cut the Personably CLAUDE.md from 1,800 words to 400 words by removing project history, deprecated workflows, and discoverable documentation. The agent performed identically because the codebase and package.json already contained that information. The CLAUDE.md just needed to tell it which project it was in and what rules to follow.

2. Auto-loaded files nobody asked for

Claude Code had been configured to auto-load several files at session start:

• A .claude/context.md file with 3,000 words of "project context" that duplicated the CLAUDE.md
• A .claude/conventions.md file listing code style rules that were already enforced by ESLint and Prettier
• The project's README, which was a visitor-facing marketing page, not a technical document

None of these were being referenced in sessions. The context.md file was genuinely useful when I was onboarding a new developer, but I was the only developer. The conventions file was redundant with the linter config that the agent could read on its own.

The fix was simple. I moved context.md to .claude/reference/context.md so it exists when needed but does not auto-load. I deleted conventions.md entirely since ESLint already enforced every rule in it. I removed the README from auto-load by adding .claudeignore:

README.md
LICENSE
CHANGELOG.md
.git/
node_modules/
.next/
dist/

That .claudeignore file alone saved about 4,000 tokens per session by keeping the agent from loading files it never used.

3. Memory that had outlived its usefulness

Hermes Agent OS stores durable memory across sessions. That is powerful. It also means memory can become a liability if you never prune it.

I found memory entries for:

• A PR number from a closed feature branch in March
• A "task in progress" note from a project that shipped in April
• Five different entries describing the same API key location in slightly different ways
• A convention note that was now embedded in the project's CLAUDE.md, making the memory entry a duplicate

The worst offender was a "session summary" entry. Memory is for durable facts. Session outcomes and completed-work logs are not durable facts. They are session history. I had accidentally stored three months of task progress notes in memory, and every session was loading them. The agent was reading about bugs I fixed in April before it could help me with what I was working on in July.

The cleanup rule I now follow: if a memory entry describes something that will be stale in a week, it does not belong in memory. Task progress, PR numbers, commit SHAs, and completed-work summaries go to session history, not persistent memory. Memory is for stable facts: user preferences, environment details, tool quirks, and conventions that do not change.

The audit I ran

Here is the exact audit I performed on each project. You can run this on your own setup in twenty minutes.

Step 1: Check current usage. Start a fresh Claude Code session. Before typing anything, run /context. Look at the token count. That number is your overhead baseline. If it is above 10,000 tokens and you are not actively working on a massive monorepo, you have waste to cut.

Step 2: Read your CLAUDE.md. Open it and ask yourself: does this agent need to know this at session start? If the answer is "maybe" or "only in specific situations," the information belongs in a skill or a reference file, not in the startup context.

A useful test: if you deleted a line from CLAUDE.md and the agent could still find that information by reading your codebase, your config files, or your package.json, then the line should be deleted. The agent can discover what it needs. You do not need to pre-deliver the entire codebase in prose form.

Step 3: Check auto-loaded files. Look at your .claude/ directory. Are there files being loaded at startup that are never referenced? Move them to .claude/reference/ and load them on demand.

Step 4: Review .claudeignore. If you do not have one, create it. Exclude everything the agent does not need: marketing files, license files, build output, node_modules, and large data directories. Be aggressive. You can always un-ignore something if the agent actually needs it.

Step 5: Audit Hermes memory (if you use it). Run through your memory entries and apply the staleness test. If the fact will not matter in a week, it is session history, not memory. Delete it. Consolidate duplicate or overlapping entries into a single compact entry.

Step 6: Verify. Start a fresh session. Run /context again. Compare to the baseline. Track the delta. The target is under 5 percent overhead on your working context window.

What I did not cut (and why)

There are things that look wasteful but are not.

My Hermes Agent OS profile still loads the full AGENTS.md at session start because that file is the project context router. Without it, the agent does not know which profile handles which workstream, which sites deploy to which Vercel projects, or which skills to load for which task types. That file is 2,500 words, it loads every session, and it is worth every token.

The test is not "is this file large?" The test is "does removing this file degrade the agent's decisions?" The AGENTS.md passes that test. My old CLAUDE.md changelog from January did not.

Some conventions are repeated across both Hermes and Claude Code. My anti-slop voice rules, no-em-dash rule, and customer-first charter exist in both systems. That looks like duplication but it is not. When Claude Code is writing an article for jakebauman.io, it is running in an isolated session without access to Hermes skills. The rules need to be in its startup context. When Hermes is reviewing the same article, it loads its own skills. The shared brain pattern I adopted handles this cleanly.

The shared brain pattern

After the audit, I centralized the knowledge that both Hermes and Claude Code need into one source of truth.

Instead of maintaining separate memory stores, skill files, and project context for each runtime, everything lives at ~/.hermes/. Both agents read from and write to the same directories:

• Memory: durable facts in ~/.hermes/memories/, accessible to both systems
• Skills: reusable procedures in ~/.hermes/skills/, usable by either agent
• Project context: CLAUDE.md files in each repo, with a .claude/reference/ directory for on-demand deep dives

The pattern is: one agent writes, the other reads. When Hermes discovers a new convention during a cron session and saves it to memory, Claude Code picks it up on its next session. When Claude Code creates a skill during a build session, Hermes can use it the next morning. No manual sync. No stale state across runtimes.

The setup took about thirty minutes. The payoff is that I never have to wonder whether the agent on one system knows what the agent on the other system figured out last week. They share a brain.

The results

Across all three projects, my per-session overhead dropped from 15,000 to 30,000 tokens to between 3,000 and 5,000 tokens. That puts overhead under 4 percent on a 128K window and under 2.5 percent on a 200K window.

The cost savings are real but secondary. At my session volume, the token reduction saves about $45 a month in Claude API costs. Not life-changing.

The real gains are:

• Faster session starts. Less context to process means Claude responds to the first prompt faster.
• Better output quality. Less noise in the context window means the agent makes fewer mistakes, especially in long sessions where context pressure is highest.
• Easier onboarding. My CLAUDE.md files are now short enough that a human can read them in sixty seconds and understand the project. That matters when I open a project I have not touched in two weeks, or when I am showing my setup to another builder.
• No more memory rot. My Hermes memory is now lean enough that every entry earns its place. I can read the whole memory store in two minutes and know exactly what the agent knows.

The template I landed on

Here is the CLAUDE.md template I now use for every project. It is short by design. Four sections, no history, no cruft:

# Project Name

Brief one-sentence description of what this project is and who it serves.

## Identity
- I am [agent role]. I work for [your name/company].
- My job is [concrete outcome, not vague aspiration].

## Goals
- [Specific, measurable goal]
- [Specific, measurable goal]

## Rules
- [Constraint or preference]
- [Style guide rule]
- [Tool or workflow rule]

## Workspace
- Source code: [directory or key files]
- Config: [config file locations]
- Build: [build command]
- Deploy: [deploy command or URL]

That is it. Everything else lives in the codebase, in skills loaded on demand, or in a .claude/reference/ file that the agent can pull when it actually needs the deep dive.

The CLAUDE.md is not a wiki. It is the minimum the agent needs to start working without making a mess. When I am tempted to add something to it, I ask: will the agent make a wrong decision without this line? If the answer is no, the line does not belong here.

Run your own audit

If you run Claude Code regularly and have never checked your session overhead, do it now. Open a fresh session, type /context, and look at the number. If it is above 10,000 tokens on a project you know well, you are carrying dead weight.

The cleanup takes twenty minutes. The payoff is permanent. You get faster sessions, cheaper sessions, and better output. More importantly, you stop training your agent on noise.

I am going to make this audit a quarterly routine. Context waste accumulates. CLAUDE.md files grow. Memory entries multiply. The agent will not tell you it is getting slower. It will just start making weirder decisions in long sessions, and you will blame the model when the real problem is the junk you keep feeding it.