I Built the Lean Workspace. Three Weeks In, It Bloated Anyway. Here's What I Do Every Day.

How do you stop Claude Code from burning tokens after you've already set up a clean workspace? You prune CLAUDE.md weekly, keep one eye on the statusline, and give every project its own rulebook so the global context stays thin. That's it. Three habits. The setup was the easy part — the discipline is the job.

Quick Check: Who Is This For?

• Non-technical builders who already use Claude Code or something like it
• People who set up their workspace weeks ago and now watch context hit 40% before they've typed a single word
• Hong Kong financial planner here — not a software engineer, just someone who builds with AI every day and learned this the hard way

If you haven't set the workspace up yet, start with Post 5 — How to Stop Burning Tokens. This post is the follow-up.

Why This Post Exists

Post 5 was about building a lean workspace. CLAUDE.md as the instruction manual, memory files as the filing cabinet, handoffs as the bookmark. I wrote it, a lot of you set it up, and I went on with my life.

Three weeks later, I opened Claude Code one morning and the context bar was already at 40% before I asked it a single question.

I'm not gonna lie — I panicked a little.

My "lean workspace" had quietly bloated. New rules added every time I got something wrong. New project pointers in MEMORY.md. New skills loaded at session start. Every file was individually justifiable. Together they were a mess.

Spoiler: I didn't rebuild. I trimmed.

And now I do it every week. Here are the three habits that stuck.

1. Prune CLAUDE.md Like You Prune a Plant

CLAUDE.md is the file Claude reads first every session. Everything in there eats context before you've done anything.

When I first set mine up, I treated it like a to-do list. Every time I got burned by a mistake, I added a rule. "Always check the schema before migrations." "Never skip the SEO gate before deploy." "Use absolute paths in sub-repos."

Six weeks in, the file had 47 rules. Half of them were niche. A third contradicted each other. None of them got shorter as time went on — they just piled up.

So I split it.

The top-level `CLAUDE.md` now holds maybe 15 lines. Identity. Session protocol. Hard rules I genuinely break without them. That's it.

`MEMORY.md` stays under 50 lines. If it grows, I move the new stuff to INDEX-feedback.md (niche rules), INDEX-projects.md (project-specific context), or INDEX-references.md (tool evaluations). Claude only loads the INDEX files when it needs them — not every session.

Niche feedback goes to its own file. My Canva rule, my Instagram hashtag rule, my Cantonese-vs-Mandarin rule — none of these matter for 95% of sessions. So they sit in INDEX files, loaded on demand.

The discipline: every Sunday, I open MEMORY.md and ask "does every line earn its seat?" If a rule hasn't fired in a month, it moves to an INDEX or gets deleted.

A fat CLAUDE.md is a tax you pay on every single session, for every single task, forever. Keep it thin.

2. Keep One Eye on the Statusline. Run /burn on Sunday.

Live monitoring + post-hoc audit. You need both.

The statusline is the little bar Claude Code shows at the bottom of the terminal. Mine shows the model I'm on, context percentage, and session duration. I look at it the way a driver looks at the speedometer — not constantly, but enough that I notice when something is off.

Rules I use it for:

• If context hits 60% and I haven't done real work yet, something is wrong. A skill is loading too much, or I left a giant file open from last session.
• If context hits 80% mid-task, I stop and dispatch a subagent instead of keeping everything in the main thread.
• If a fresh session opens at 40%, my MEMORY.md bloated again and it's pruning time.

The statusline catches drift live. That's its job.

`/burn` is my weekly audit. It reads the token logs, groups by category, and tells me where the tokens actually went. Research agents? Skill injections? File reads I forgot about?

Last week, /burn told me 34% of my tokens went to skill injections I didn't use. One skill was being loaded every session because its description matched half my prompts, but I never actually needed it. I tightened the trigger, saved 50K tokens a week.

The statusline stops today from going sideways. /burn stops next month from going sideways.

You need both because they catch different things.

3. Give Every Project Its Own Rulebook

This is the one that took me longest to internalize.

I have seven active projects. For a long time, every project's rules lived in the global CLAUDE.md. When I worked on the insurance team's MPF tool, Claude saw my blog-publishing rules. When I worked on the blog, Claude saw the database migration rules for the CRM.

None of that context was relevant. All of it was loaded.

So I moved every project's domain rules into its own file: 02_Product/<project>/CLAUDE.md. The global CLAUDE.md stays universal — session protocol, mentorship style, hard technical rules that apply everywhere. Each project folder carries its own domain knowledge, architecture decisions, and hard rules that only matter when I'm working on that thing.

The rule I follow now: when I start a session inside a project folder, that project's CLAUDE.md loads. When I'm at the root, only the global one loads. The insurance rules stay with the insurance app. The blog rules stay with the blog.

A real example from last week. I was researching Hong Kong's public hospital system for the Financial CRM — dispatched three research subagents in parallel, each with its own context budget. They burned about 224,000 tokens between them. My main session? Stayed under 60% the whole time.

That only works because the global context is thin. If my main thread had been carrying every project's rules, there wouldn't have been room for the actual work.

Project-specific CLAUDE.md isn't about organization. It's about keeping the main context empty enough to do something.

The Takeaways

1. The setup is the easy part. Building a lean workspace takes a weekend. Keeping it lean takes a weekly habit. Plan for the maintenance, not just the build.
2. A fat CLAUDE.md is a tax on every session. Under 50 lines for MEMORY.md. Move niche rules to INDEX files. Prune on Sunday. If a rule hasn't fired in a month, it probably doesn't need to be loaded every session.
3. Monitor live, audit weekly. Statusline for today, /burn for the trend. One catches drift before it hurts you. The other catches waste you'd never notice otherwise.
4. Projects are their own universes. Every 02_Product/<project>/ gets its own CLAUDE.md. The global workspace stays thin. Your main context stays empty enough for the actual work.

Extra: The One Thing I Didn't Expect

The side effect of pruning weekly is that I now know what I actually use. After three prunes, my MEMORY.md is about half the size it was — and every line that survived is a rule I've broken recently.

Turns out the filing cabinet gets more useful as it gets smaller. The Karpathy/second-brain post made the same point about a different file system — synthesis over storage.

Same lesson. Different file. Still true.

What's the rule in your own setup that you haven't questioned in a month?