What do you do when your planning files get too big?

[kennym]

My planning files are getting huge over time, and I might have to do some housekeeping? How do you solve for that?

There's a lot of unnecessary stuff like progress reports on stuff that was already done; it might give context but it also eats up tokens.

[behrnt-slatgng]

Disclosure: I build Grunz, a hosted coding agent, so I've had the same problem from the harness side. What worked for us was splitting the file by how often each part changes, instead of pruning it.

1. Goal and constraints: short, rarely edited, and never summarized. The original ask, the stop conditions, and the things you must not do. This is the part that gets lost first when anything compresses the file, because it's the oldest and least-repeated text in it. Keep it at the top and keep it small.
2. Current state: rewritten, not appended. What's done, what's in progress, and the next step, as a replacement block each time. "Done" items become one line each: what changed and where, not the story of how.
3. History: append-only, but moved out of the file the agent reads every turn (for example an archive/ file it only opens when it needs to know why something was done a certain way).

The progress reports you mention belong in 3. Most of their value is being able to answer "why is it like this" later, and the agent rarely needs that on a normal turn.

One trap to avoid: if you let the model do the housekeeping, check that the goal section comes out word for word. A summarizer will happily turn "stop before deploying" into "deployment work," and a plan that reads fine after cleanup can still be missing its stop condition.

[OthmanAdi]

My planning files are getting huge over time, and I might have to do some housekeeping? How do you solve for that?

There's a lot of unnecessary stuff like progress reports on stuff that was already done; it might give context but it also eats up tokens.

Hey man 👋🏼 the isolation should work.. which harness are you using?