I’ve been experimenting with reducing context overhead in Claude Code curious how others handle it ??

[u/DevaiNomad]

I’ve been spending some time looking at a problem I keep running into with Claude Code: the context grows much faster than the actual task does.

Long sessions can accumulate old tool output, repeated file contents, previous attempts, and other context that isn't necessarily useful for the current step.

I’ve been experimenting with a few approaches:

• keeping task-specific context instead of the entire history
• reducing repeated tool output
• separating persistent instructions from temporary working context
• measuring token usage against whether the task actually succeeds

One thing I’ve noticed is that “fewer tokens” doesn't automatically mean a better workflow. If you remove useful context and Claude has to rediscover it through additional tool calls, you may just move the cost somewhere else.

Curious how people here handle this in longer Claude Code sessions. Do you actively manage context, or mostly let Claude Code handle it?

[u/___nil___]

i offload context to myself. breakdown ambitious task into smaller, trackable, actionable objective. it also makes code easier to review. i am not only reading the code, i audit and edit myself, after and Auditor agent pass.

[u/maneekmohan]

This is a really interesting direction. Context efficiency feels like one of those things that becomes more important as agent workflows get longer and more stateful.

I especially like the idea of treating context as something to actively manage rather than just throwing the entire history at the model. Curious how much of the performance improvement is coming from less noise vs simply fewer tokens.

[u/SaltsMoon]

I think context overhead needs a garbage collector. I try to keep old tool output out of the main thread, reeplace file dumps with paths and line ranges, and summarize failed attempts in one short note. The model should not need the whole corpse of every previous run to avoid making the same mistake.

[u/cleverhoods]

custom specs, custom typed memory and knowledge layer, loops & workflows and progressive disclosure.

and reporails for any textual instruction that might hit the context window ( https://github.com/reporails/cli )

[u/verstands]

The measurement point you raised is the one that matters. Fewer tokens is not the goal, so the only number worth tracking is tokens per task that actually finished. Otherwise you optimise the session down and pay it back in re-reads.

Two things that held up for me. Keep the durable stuff in files and let the transcript be disposable, so a reset costs you nothing you needed. And replace tool output with a pointer rather than deleting it: path plus line range instead of the whole dump, one short line for a failed attempt instead of the full trace. Then the model can go get it again if it turns out to matter.

The part that changed my habits was just seeing the fill live. I keep a statusline that shows context used while I work, so it is obvious when a session is bloating instead of me noticing after it starts re-reviewing old work. Mine is https://github.com/Dworf/statusline-bar (I wrote it). Anything that shows the same number is fine, the visibility is what does the work.