Five weeks ago I did a spring cleaning of my global CLAUDE.md context, cutting it from 21K to 7K characters. The other day I noticed the file had almost returned to its old size. How did that happen, and what do vendors recommend in such cases?

The interesting part: the old instructions did not come back. New processes and rules appeared instead, all of them obviously useful for the work at hand. The block on using the task tracker alone had grown to 5K characters and taken up nearly a third of the file.

Growth of the working context is, of course, a consequence of active work rather than a sign of breakage. New useful rules inevitably accumulate.

The real problem is that (1) not every such instruction needs to load in every session, and (2) nobody was watching the file swell.

So first I rolled up my sleeves again. The detailed task tracker instructions moved into a separate t-tasks skill: Claude loads it only when there is actual work with tasks. What stayed in the global CLAUDE.md is a short map - where tasks live and which repository to use for them. The criterion for the remaining blocks was the same: does the model need this always, or only for one particular kind of work?

After this cleanup, Claude started receiving about half as much context from me at the beginning of each session.

It is easy to think: “There he goes about optimization again - cut the file in July, it grew back, now he cut it once more.” There are a couple of differences that earn this post.

First, I looked at the best practices and cleaned not only the global CLAUDE.md but also the local ones and the skills.

Second, I approached it systematically - you could say I opened my own Performance Analysis Lab. It is run by a new skill, /t-perf. It keeps the task list and coordinates all work on performance and token economics: from collecting data to regular reviews of context and skills. I no longer have to hold the plan in my head or gather information about processes and working materials from files myself.

What stays with me is decision-making and the part of the work that is not yet worth delegating. The rest is a process: a snapshot is saved before changes, the reasoning behind decisions is recorded in a journal, and after 30 days a watchdog knocks with a reminder about the next round of maintenance.

The broader topic - running AI agents properly, managing context, counting cost, choosing models, verifying changes - is fairly large, so I will keep coming back to it.

With these reviews the goal is not to squeeze the file down to nothing but to find the right place for every instruction. Sometimes a new rule is better left in the global file after all. It spends a little context in every session, but it can prevent far more expensive cycles of work.

In the next post on running agents I will show exactly such a case: why, after a big cleanup, I deliberately made CLAUDE.md bigger again.

So maintenance is still not something to forget about - but now I have someone responsible for it.