CLAUDE.md in Practice: 7 Lines, 35 Lines and 490 Lines, Measured

Claude Code in business Three real CLAUDE.md files, measured: what each adds to every Claude Code call, a rule broken four times, and a file that became a diary.

I have three CLAUDE.md files. One is 7 lines long, one is 35, and one is 490, and until this morning I had never checked what any of them cost. So I ran a one-word prompt from four folders and counted. The 490-line file adds 59,666 input tokens to every call made from its folder, before I have typed a word. That is more than the whole of Claude Code’s own startup on my laptop.

This post has three parts. First, the measurement: what each file and the memory index adds per call. Second, one rule that was broken four times in three weeks, and what the rewrite that finally held looks like. Third, the 490-line file itself, which stopped being a set of instructions somewhere around line 60 and became a diary. All the numbers come from a read-only script that prints counts and never the text of the files.

1. What three files cost on every call #

A quick map, because the names matter. Claude Code reads a global ~/.claude/CLAUDE.md in every session, then the CLAUDE.md of whatever folder you start it in. On top of that there is a memory folder: one small note per fact, and an index file, MEMORY.md, with one line per note. The index is loaded at the start of a session. The notes are opened only when one looks relevant.

Here is how big mine are today.

Size on disk doesn’t tell you much, so I measured the thing that actually gets billed. The script starts claude -p with the default flags and the prompt “Reply with the single word OK.” from an empty folder, then from each project folder, three times each on haiku, and reads the input token count out of the JSON envelope. (How that envelope works is in the claude -p field guide.)

Three things I did not expect.

The baseline is already 48,007. That is the default system prompt, my plugins and my MCP servers, with no project at all. It matches the 48,234 I measured for the previous post on a different day, so the number is stable. Instruction files are stacked on top of that.

The files are in Korean, and Korean is expensive. 64,652 characters became about 59,666 tokens, close to one token per character. English text usually gets several characters to a token. If you write your instructions in a language other than English, your files are heavier than their line count suggests. Mine are roughly four times heavier.

The memory index costs twice what the bots file does. I thought of it as a table of contents. It is 13,264 tokens of table of contents.

Two honest limits on these numbers. The “added by the folder” column is the folder, not only the file: the bots repo also holds an identical AGENTS.md copy, and a project folder brings a little context of its own. And none of this touches the three bots that call a model at night. They pass flags that skip all of it, which is how they get down to 26,923 tokens a call. The cost here lands on working sessions and on scheduled tasks, which start with the defaults. On a flat US$100 plan that isn’t a line on a bill. It is usage allowance, and it is room in the context window that the actual work then doesn’t get. The money side is in the cost post.

2. The rule that was broken four times #

The global file holds exactly one rule: everything I can see must be in Korean. I am not a developer, I read most of this on a phone, and a paragraph of English status text in the middle of a job is a paragraph I skip.

It took four corrections to get that rule to hold, and the notes have the dates.

• 2 October. A reply came back in English. I complained, with feeling. Claude Code saved a memory note: replies are always in Korean.
• 21 to 23 October. Broken three more times in three days. Each time the final answer was in perfect Korean. The English was in the one-line progress notes between tool calls, the “Next I’ll check the log” kind.

That second failure is the interesting one, because nobody disobeyed anything. The note said “replies”. A progress line between two tool calls doesn’t feel like a reply. The rule had a hole exactly the size of the thing I was complaining about.

On 23 October at 16:00 the rule moved out of the memory note and into the top of the global file, rewritten. Here are both versions, translated.

Four things changed, and I now check every new rule against them.

1. Where it lives. A memory note is opened when it looks relevant. A globalCLAUDE.md is read every session, in every folder, including scheduled tasks that run while I’m asleep. A rule that must never be broken doesn’t belong somewhere it might not be opened.
2. It lists what counts. Not “replies” but progress notes, text between tool calls, questions, tables, summaries, confirmations, and apologies. The apologies line is not a joke. An apology for writing in English had arrived in English.
3. It names the conditions under which it slips. When the system instructions are in English. When a tool result is in English. When the session gets long. Those were the three situations in which it had actually failed.
4. It gives the reason. “The owner is not a developer and often reads on a phone.” A rule with a reason gets applied to cases the rule didn’t list.

Since that rewrite the notes record no fifth correction. I’ll be careful with that: it means I haven’t had to complain again in three weeks, not that I have a log proving zero English lines. But the earlier version lasted nineteen days and then failed three times in a row, so I’m counting it.

The price of this rule is 348 characters. It is the cheapest file I have and the one that does the most.

3. The file that turned into a diary #

Now the 490-line one. I don’t write these files by hand. I say “remember this” or “from now on do it this way”, and Claude Code adds a section. In a project that changes every day, that happened every day.

These are some of its headings, translated, with supplier names replaced by letters.

The counts tell the story on their own:

• 60 headings, 57 of them dated. “27 Oct: write test passed.” “6 Nov: supplier B at 9.9%.”
• 33 of the 60 end with a note that I asked for it. Each one was a reasonable request on the day.
• Line 1 is a warning about a test that ran on 23 October. It says “read this first”. Twenty days later it is still read first, 59,666 tokens at a time.

Nothing in that file is wrong. It is an accurate record of three weeks of work. The trouble is that a record and an instruction are different things, and only one of them needs to be read before every single task. “The write test passed on 27 October” is history. “Never complete a purchase unless all three sources agree” is a rule. The file has both, in date order, and the rules are buried under the history that produced them.

Compare the 35-line file in the bots repo. It has had four commits, the last on 8 October, and it has not grown since. Its first section is titled “First: which computer is this?”, because we once installed the bots on the wrong Mac. Then: how to check whether the bot is alive, whether the machine was asleep, where the log is, how to restart. Then four things never to do. There isn’t a single date in a heading. It describes how the place works, so it stays true until the place changes.

The memory index has the same disease in miniature. Seventy lines, median 105 characters, and one line of 2,044 characters: the entry for our biggest bot, where every new rule was appended to the pointer instead of to the note it points at. That one line is 20% of the index. The note it points to is opened only when needed. The pointer is paid for every time.

So this is what I’m changing, in order:

1. Split the 490-line file in two. Rules that will still be true next month stay inCLAUDE.md . Everything with a date in its heading moves to a notes file in the same folder, which gets read when a task needs the history.
2. Delete line 1. A “read this first” that has expired is worse than no warning, because it teaches the reader that the top of the file is stale.
3. Cut the long index line back to a pointer. The detail already lives in the note.
4. Re-run the probe. The target is the newest project under 60,000 tokens from its current 107,673.

None of that is done yet. Today’s numbers are the “before” picture, and I’d rather publish the before with real figures than the after with a tidy story. One thing I won’t do is delete the history. Twice this month the answer to “why does the bot do that?” was in one of those dated sections.

If you want one test to take away: read each line of your CLAUDE.md and ask whether it would still be true if nobody touched the project for a month. If yes, it’s an instruction. If no, it’s a diary entry, and it is being re-read on every call.

One line from me #

My most effective instruction file is 348 characters and my most expensive one is 64,652, and the expensive one opens with a warning about a test that finished twenty days ago. If you’re working out where your own tokens go, the claude -p field guide shows how to read the count for a single call, and the scheduled tasks post covers the jobs that pay this overhead while nobody is watching.

More on this topic: the Claude Code in business guide, with every post in reading order.