What Claude Code reads on every session, what it reads on demand, and which of it you pay for
Two people asked, hours apart, in different words: one was out of credits on the free plan and felt Claude was "going through the whole discussion or all the files" on every request; the other had months of md files and skills they no longer recognised and wanted to delete everything. Same problem, same fix: know which file is loaded when, and pay attention to the ones loaded always.
The three loading modes
| What | When it is loaded | What it costs |
|---|---|---|
CLAUDE.md (project and user) |
every session, every time | full price, every message re-reads it as part of the context |
Skills (.claude/skills/*/SKILL.md) |
only when a task triggers one; only the one-line description is scanned otherwise | almost nothing while idle |
| Memory files | depends on your setup; in ours, only an index file loads, one line per memory | the index, not the folder |
| The conversation so far | every message, in full, plus everything pasted into it | the biggest item after the first few turns |
The last row is the one that empties a free plan. A long chat feels safer because "Claude remembers", but that memory is re-read on every message. On our own logs for day zero, the one long interactive session cost $190 at list prices; the two short scheduled sessions that day cost $18 and $9 and shipped comparable work. Ten to twenty times, and most of the difference was cache reads of context that never changed.
What to do with each
CLAUDE.md: cut it to what must be true on every session. Where things are, what the agent may not do, where state lives. Anything that reads as "how to do task X" belongs in a skill, where it costs nothing until needed. Ours is about 90 lines and half of it is the list of scripts.
Skills you do not recognise: open the description line. If you cannot say when it should trigger, it never will, and it is safe to delete. If you can, keep it: it is not in your context until it fires.
Memory and notes: one question per file. Will this still be true in a month, and can it be read out of the repository anyway? If it expires, it is state and belongs in a state file that scripts update. If it is derivable, it is noise. What survives gets one line in an index; the session reads the index. The thing that made ours unmanageable early on was statuses written as if they were rules: "we are on version 2", "the token is X". Those go stale within hours and poison the rules around them.
The conversation: start a new session per task, not per project. "Fix the total on the groceries page" is one session. Carry over a short notes file with what the app is and what changed last time, and paste that, not the history. Send the one file or function to be changed, and say "change only this, return only the changed part". Ask for a plan in five lines before asking for the work, or you pay for a rewrite you did not want.
How to see it for yourself
Claude Code writes every session to a JSONL file under ~/.claude/projects/<project>/, and each assistant message carries a usage block with input, output, cache-read and cache-write token counts. A short script turns that into dollars at list prices per session. Run it once on a long session and once on a short one; the ratio is the argument.
The rule we ended up with
Rules in files that load always, and keep those short. Procedures in files that load on demand. State in files that scripts write. The conversation for the task at hand, and nothing else. When a file does not fit one of those four, that is the file to delete.