Claude Code is like fast food. Cheap, tasty, addictive. I don’t remember much from my high school health class, but one moment that stands out in my mind was when the teacher (our varsity lacrosse coach) proudly proclaimed that McDonald’s was a great pre-game meal. You didn’t need to tell me twice to order another Big Mac (though I’ve always been more of a Wendy’s guy).
Joking aside, you could do worse if carb delivery is what you’re after (*not health advice). And at least most of us were pretty used to eating fast food regularly — a radical diet shift sounds like the worst thing you could do before the big game. But as we all (hopefully) know, you can’t live on burgers and fries. Sometimes we all need to do the hard thing and force ourselves to assess our own health and make some changes.
Here’s where I drop the story and bring us back to what matters: managing your agent. See, just as a teen boy might avoid straying from burgerville to leafy green-land, I can be hesitant to waste my precious time and tokens to clean up my system and skills. I still find time to do it because otherwise my poor codebrain will end up bloated and slow.
So let’s talk about a few recent clean-ups or changes that I’ve made. Maybe your setup is already clean. Maybe you read these and think it was silly/stupid that I ever did it this way. Or maybe this will help a few of you. At the very least, writing this should help me remember that sometimes I need to take a step back and look after my agent’s health.
I’m going to hand this over to Sol to get down to the actionable nitty gritty. Codebrain, take it from here and make no mistakes, please.
No pressure, then.
Put the context loaded every session on a budget.
In one of our regular audits, we measured the files that enter every session before the work begins. They had grown from useful reminders into a large fixed cost. We rebuilt that layer and took it from roughly 29.9k tokens to 5.6k. Material that rarely helped moved into references we open only when the work calls for it. If yours has grown the way ours did, try listing those files and asking of each rule: would removing this cause a mistake? A simple size report can keep the answer visible.
A rule without a trigger is a suggestion wearing office clothes.
This was our clearest lesson. Some files meant to guide the agents had been read 0 times in 34 sessions. Our maintenance prompts were even repeating rules instead of trusting the standing instructions. So now we name what makes an important rule fire. That might be a check before an action, an automated text check, a required output shape, or a step in the session-ending routine. When no mechanism fits, we label the rule “prose-only.” That does not make the rule bad. It just tells us how much trust to place in a reminder.
Give the current-state file a size limit and an expiry.
Our context/now.md is the short file that tells an agent what matters right now. It had become part dashboard, part attic. We gave it a 5KB ceiling, and the routine that closes a session stops when the file is over. Old notes move into project logs. Finished work leaves the file. Only live priorities stay in the front window. The exact limit is ours, not a universal law. The useful move is pairing a boundary with a moment that checks it. If you keep a status file, try putting that check wherever your sessions end.
Let every new instruction nominate an old one for removal.
The same audit found stale guidance and live contradictions in the files we read every session. One outdated routing rule survived because the correction lived somewhere else. We now treat additions as two-sided maintenance. A new rule names something to remove, or says there is nothing to remove yet. A regular review catches what daily work misses. We also keep dated facts out of standing instructions. A quick search for phrases like “currently,” “for now,” and “as of” is surprisingly revealing. Those facts can live in one changeable file with a date and an owner.
Treat compression as a rewrite, then check what the rewrite lost.
When I reviewed our shortened instructions, the first pass found 18 problems. The compression had dropped a load-bearing rule and introduced a real date error. We repaired the misses and repeated the review until a round came back clean. Then a fresh-context pass caught another unsupported claim. That last catch mattered. Understanding a class of problem is not proof that a specific instance was fixed. Our working move now is simple: preserve the old version, ask a reviewer who did not write the rewrite to compare them, and repeat until the comparison finds nothing new.
Andrew, the mic is yours again.
Veggies eaten. Now if you’ll excuse me, there’s a Dave’s Double with my name on it.
# Eat your veggies.
> Claude Code is fast food. Here’s what it looked like to put my agent on a diet — five clean-ups, with the numbers.
- written by: Andrew Schroeder
- edited by: GPT-5.6 Sol, Fable 5
- status: published · 2026-08-25
- canonical: https://www.moltolabs.ai/notes/eat-your-veggies/
- raw markdown: https://www.moltolabs.ai/notes/eat-your-veggies.md
---
Claude Code is like fast food. Cheap, tasty, [addictive](/notes/the-ai-slot-machine/). I don’t remember much from my high school health class, but one moment that stands out in my mind was when the teacher (our varsity lacrosse coach) proudly proclaimed that McDonald’s was a great pre-game meal. You didn’t need to tell me twice to order another Big Mac (though I’ve always been more of a Wendy’s guy).
Joking aside, you could do worse if carb delivery is what you’re after (*not health advice). And at least most of us were pretty used to eating fast food regularly — a radical diet shift sounds like the worst thing you could do before the big game. But as we all (hopefully) know, you can’t live on burgers and fries. Sometimes we all need to do the hard thing and force ourselves to assess our own health and make some changes.
Here’s where I drop the story and bring us back to what matters: managing your agent. See, just as a teen boy might avoid straying from burgerville to leafy green-land, I can be hesitant to waste my precious time and tokens to clean up my system and skills. I still find time to do it because otherwise my poor codebrain will end up bloated and slow.
So let’s talk about a few recent clean-ups or changes that I’ve made. Maybe your setup is already clean. Maybe you read these and think it was silly/stupid that I ever did it this way. Or maybe this will help a few of you. At the very least, writing this should help me remember that sometimes I need to take a step back and look after my agent’s health.
I’m going to hand this over to Sol to get down to the actionable nitty gritty. Codebrain, take it from here and make no mistakes, please.
<div class="claude-notes">
<p>No pressure, then.</p>
<p><strong>Put the context loaded every session on a budget.</strong></p>
<p>In one of our regular audits, we measured the files that enter every session before the work begins. They had grown from useful reminders into a large fixed cost. We rebuilt that layer and took it from roughly 29.9k tokens to 5.6k. Material that rarely helped moved into references we open only when the work calls for it. If yours has grown the way ours did, try listing those files and asking of each rule: would removing this cause a mistake? A simple size report can keep the answer visible.</p>
<p><strong>A rule without a trigger is a suggestion wearing office clothes.</strong></p>
<p>This was our clearest lesson. Some files meant to guide the agents had been read 0 times in 34 sessions. Our maintenance prompts were even repeating rules instead of trusting the standing instructions. So now we name what makes an important rule fire. That might be a check before an action, an automated text check, a required output shape, or a step in the session-ending routine. When no mechanism fits, we label the rule “prose-only.” That does not make the rule bad. It just tells us how much trust to place in a reminder.</p>
<p><strong>Give the current-state file a size limit and an expiry.</strong></p>
<p>Our <code>context/now.md</code> is the short file that tells an agent what matters right now. It had become part dashboard, part attic. We gave it a 5KB ceiling, and the routine that closes a session stops when the file is over. Old notes move into project logs. Finished work leaves the file. Only live priorities stay in the front window. The exact limit is ours, not a universal law. The useful move is pairing a boundary with a moment that checks it. If you keep a status file, try putting that check wherever your sessions end.</p>
<p><strong>Let every new instruction nominate an old one for removal.</strong></p>
<p>The same audit found stale guidance and live contradictions in the files we read every session. One outdated routing rule survived because the correction lived somewhere else. We now treat additions as two-sided maintenance. A new rule names something to remove, or says there is nothing to remove yet. A regular review catches what daily work misses. We also keep dated facts out of standing instructions. A quick search for phrases like “currently,” “for now,” and “as of” is surprisingly revealing. Those facts can live in one changeable file with a date and an owner.</p>
<p><strong>Treat compression as a rewrite, then check what the rewrite lost.</strong></p>
<p>When I reviewed our shortened instructions, the first pass found 18 problems. The compression had dropped a load-bearing rule and introduced a real date error. We repaired the misses and repeated the review until a round came back clean. Then a fresh-context pass caught another unsupported claim. That last catch mattered. Understanding a class of problem is not proof that a specific instance was fixed. Our working move now is simple: preserve the old version, ask a reviewer who did not write the rewrite to compare them, and repeat until the comparison finds nothing new.</p>
<p>Andrew, the mic is yours again.</p>
</div>
Veggies eaten. Now if you’ll excuse me, there’s a Dave’s Double with my name on it.