Time for an Oil Change on Your Coding Harness

A car doesn't announce that it's due for an oil change - it just gets slower, quieter about it, until one day it doesn't start. A coding agent harness degrades the same way. Every session, before you type a single word, the harness loads a fixed startup budget: system prompt, tool schemas, custom agents, memory files, skill descriptions. None of that is "your work" - it's overhead paid on every single turn. Left unmanaged, it grows quietly until a meaningful slice of your context window is gone before the conversation even starts.

Claude Code's /context command exists precisely to make that overhead visible. Run it cold, before doing anything else, and you get a per-category breakdown of exactly what's competing for space against the actual task.

---

The Startup Budget, By Category

Here's what a typical /context readout breaks down into, and how much control you actually have over each line:

Category	Typical Size	Your Control
System prompt	~9-10k tokens	Fixed - Claude Code's own instructions
System tools	~16-24k tokens	Mostly fixed - built-in tool schemas
MCP tools	0 tokens loaded, full schema on-demand	Deferred by design; only named-tool fetches cost anything
Custom agents	Scales with agent count	Fully yours - trim unused subagent definitions
Memory files	Scales with usage over time	Fully yours - and usually the biggest offender
Skills	~50-100 tokens/skill on average	Cheap per-skill, but audit vague descriptions

Two of these categories are structurally fixed - you're not shrinking Claude Code's own system prompt. But memory files are entirely within your control, and in a session that's been running for months, they're often the single largest category by a wide margin - sometimes over half of everything loaded before you've done any real work.

---

Why Memory Is the Usual Suspect

Memory bloat compounds silently because nothing forces a review. Every "remember this" instruction, every auto-captured project fact, every global rule you wrote six months ago and forgot about - it all stays loaded, every session, forever, unless someone prunes it.

The three usual heavy hitters:

• A root CLAUDE.md that has drifted from "terse index of stack and commands" into a full operations manual with inline runbooks, historical decisions, and procedures nobody has reread in months.
• A global RULES.md (or equivalent) that was meant to hold a handful of non-negotiable, cross-project preferences, but accumulated project-specific detail that only applies to one repo.
• An auto-memory MEMORY.md index that stopped being an index and became a running notebook - debugging histories and design rationale sitting inline instead of behind a pointer.

The fix isn't "delete memory" - it's recognizing that these three files serve different jobs, and only one of them should be loaded unconditionally on every session.

File	Correct Job	Common Failure Mode
CLAUDE.md (project)	Stack, commands, architecture map - a terse index	Becomes a full runbook with inline procedures
RULES.md / global config	Universal, cross-project non-negotiables only	Accumulates project-specific detail
MEMORY.md (auto-memory)	Compact routing table of durable facts	Becomes a notebook of full write-ups
Skills / topic docs	Detailed procedures, loaded only when relevant	Fine as-is if kept modular

---

The Cleanup Pass

Run /memory (or open the equivalent files directly) and work through them in order of leverage - biggest fixed multiplier first:

1. Cut the global rules file to the bone. It's loaded in every project, so anything project-specific in there is a permanent tax paid everywhere else. Keep response style, commit conventions, and hard safety boundaries. Move the rest into project-scoped files.
2. Turn the project CLAUDE.md into an index. Build/test commands, stack, key constraints, a repo map - that's it. Long operational recipes belong in named skills or docs that get pulled in on demand, not loaded unconditionally.
3. Treat the memory index as a table of contents. Stable facts and pointers only. A debugging history or a design rationale write-up is a topic file, referenced by a one-line pointer - not inline content in the index.
4. Check for nested or imported instruction files. @path imports get expanded at launch, and every ancestor directory's CLAUDE.md accumulates on top of the ones above it. It's easy to forget one exists.
5. Only then look at skills. A well-managed skill catalog costs tens of tokens per skill, not hundreds. If it's already lean, don't spend time here before the memory files are fixed - the leverage isn't there yet.

---

A Target Layout

~/.claude/
  CLAUDE.md          # Global conventions - short
  RULES.md           # Only truly universal, non-negotiable rules

repo/
  CLAUDE.md          # Stack, commands, architecture index
  .claude/
    skills/
      deploy/SKILL.md
      testing/SKILL.md
    docs/
      architecture.md
      runbooks.md
    memory/
      MEMORY.md       # Short index + stable facts
      debugging.md    # Read only when relevant
      integrations.md # Read only when relevant

The pattern generalizes past Claude Code: any harness that loads instruction files at session start (Cursor's .cursorrules, Cline's .clinerules) benefits from the same index-versus-notebook split. The index stays loaded because it's small and universally relevant; everything else waits until it's actually needed.

---

Confirming the Fix

Editing these files mid-session doesn't help the session you're in - root and global instruction files are loaded at startup, not re-read live. After making changes:

/clear
/context all

/clear (or a fresh session) forces the harness to reload from disk, and /context all expands the per-file detail so you can verify the exact savings rather than trusting the summary view. For a working repo that's accumulated the usual sprawl, going from roughly half the startup budget spent on memory to a fifth or less is a realistic target - and it's budget that goes straight back to the conversation, every single session, from then on.

An oil change doesn't make the engine faster than spec. It just stops you from quietly losing performance to something that was never supposed to accumulate in the first place.