How I Keep Claude Code's Context Under 30%

I've written about my Claude Code setup and why CLAUDE.md is the most important file in your project. Both are about giving Claude the right information. This one is about the opposite problem - giving it too much.

The context window is the thing nobody configures and everyone fights. You can have a perfect CLAUDE.md, every skill, every MCP tool, and still get worse output as a conversation drags on. Not because the model got dumber, but because you buried the signal. Most of the bad answers I see aren't model problems. They're context problems.

• Context is the constraint
• Work in chunks
• Build the important things first
• /clear vs /compact
• Staying under 30%
• Watch the meter

Context is the constraint

Everything Claude knows in a conversation lives in the context window - your CLAUDE.md, the files it has read, the commands it has run, every message back and forth. It's a fixed budget, and it only fills up. It never empties on its own.

The catch is that a full window isn't free. The more you cram in, the harder it is for the model to find what actually matters. Early decisions get drowned out by later noise. It re-reads files it already read, forgets a constraint you set twenty messages back, and starts contradicting itself. The quality curve bends down long before you hit the hard limit.

So I stopped treating context as something to fill and started treating it as something to spend. A clean window with the three files that matter beats a full window with thirty files and a half-finished tangent. Less context, more signal.

Work in chunks

The single biggest habit: one conversation, one job. I break work into self-contained chunks and give each one its own session. Build the auth flow, then clear. Fix the failing test, then clear. Refactor the service class, then clear. I don't let a single conversation accumulate three unrelated tasks, because by the third one the window is full of the first two and none of it is helping.

A good chunk is something Claude can finish with room to spare. If a task is too big to fit comfortably - a feature that touches ten files and needs a dozen decisions - that's a planning signal, not a reason to push through. I break it down first, then run each piece in a clean context. The work goes faster and the output is more consistent, because Claude is never reasoning around a pile of stuff that's no longer relevant.

Build the important things first

Context is never cleaner than at the start of a project. No accumulated history, a short CLAUDE.md, nothing competing for attention. That's the moment to spend it on the parts you can't afford to get wrong.

So when I start something new, I build the core first - the architecture, the data model, the features everything else depends on - while Claude has the most room to think. The small stuff comes later: the extra setting, the polish, the nice-to-have endpoint. Those are low-stakes and forgiving, and they each start from their own clean context anyway. It feels backwards to do the hard part first, but the hard part is exactly what deserves the clearest window. Get the foundation wrong under a crowded context and everything you stack on top inherits the mistake.

/clear vs /compact

Two commands, two very different tools.

/clear wipes the conversation and starts fresh. Context drops back to near zero - your CLAUDE.md reloads, but the history is gone. This is my default. When a chunk is done, I clear and move on.

/compact takes everything so far and condenses it into a summary, keeping the thread alive while freeing space. It's useful when you're genuinely mid-task and need continuity but the window is filling up. The tradeoff is that a summary is lossy - it keeps the gist and drops the detail, and sometimes the detail was the point.

I reach for /compact rarely. Most of the time, when I feel the urge to compact, it's a sign the task should have been chunked smaller. A fresh /clear plus a clear prompt and a solid CLAUDE.md beats a compacted summary almost every time, because I'm handing Claude exactly what it needs instead of a blurry recap of how we got here. Clear by default. Compact only when continuity genuinely outweighs the loss.

Staying under 30%

In practice I almost never go past 30% of the window. Not because there's anything magic about that number - it's a tripwire, not a rule. When I notice context climbing past it, I take it as a sign the conversation has sprawled and it's time to finish the chunk, clear, and restart with just what the next step needs.

Keeping it low isn't just about avoiding the ceiling. A leaner context is sharper, faster, and cheaper. The model isn't sifting through history to answer, the responses come back quicker, and I'm not paying to re-send a transcript I don't need. Thirty percent leaves plenty of headroom for Claude to read files and run tools mid-task without ever getting near the edge.

Watch the meter

None of this works if you can't see your context usage. A status bar that shows it live is non-negotiable - I mentioned mine in the setup post, and the context bar is the part I'd miss most. It shifts from green to yellow to red as the window fills, so I always know where I stand without guessing.

That one glance is what drives every decision above. It tells me when a chunk has run its course, when I'm drifting toward the limit, and when to clear before the quality starts to slip instead of after. Without it you're flying blind, and you only notice the window was full when the answers have already gone sideways. With it, managing context stops being a chore and becomes something you just see.

Good context management isn't a trick - it's a habit. Work in chunks, build the important things first, clear early and often, and keep an eye on the meter. The best output I get from Claude doesn't come from a fuller context. It comes from a cleaner one.