[agotterer]

I wonder how much of this had to do with the context window size? Gemini’s window is 5x larger than Cladue’s.

I’ve been using Claude for a side project for the past few weeks and I find that we really get into a groove planning or debugging something and then by the time we are ready to implement, we’ve run out of context window space. Despite my best efforts to write good /compact instructions, when it’s ready to roll again some of the nuance is lost and the implementation suffers.

I’m looking forward to testing if that’s solved by the larger Gemini context window.

[macNchz]

I definitely think the bigger context window helps. The code quality quite visibly drops across all models I've used as the context fills up, well before the hard limit. The editor tooling also makes a difference—Claude Code pollutes its own context window with miscellaneous file accesses and tool calls as it tries to figure out what to do. Even if it's more manual effort to manage the files that are in-context with Aider, I find the results to be much more consistent when I'm able to micromanage the context.

Approaching the context window limit in Claude Code, having it start to make more and worse mistakes, then seeing it try to compact the context and keep going, is a major "if you find yourself in a hole, stop digging" situation.

[seunosewa]

I've found that I can quickly get a new AI session up to speed by adding critical context that it's missing. In my largest codebase it's usually a couple of critical functions.once they have the key context, they can do the rest. This of course doesn't work when you can't view their thinking process and interrupt it to supply them with the context that they are missing. Opacity doesn't work unless the agent does the right thing every time.

[data-ottawa]

Does /compact help with this? I ran out of context with claude code for the first time today, so looking for any tips.

I'm trying to get better at the /resume and memories to try and get more value out of the tool.

[agotterer]

I thought I read that best practice was to start a new session every time you work on a new feature / task. That’s what I’ve been doing. I also often ask Claude to update my readme and claude.md with details about architecture or how something works.

As for /compact, if I’m nearing the end of my context window (around 15%) and are still in the middle of something, I’ll give /compact very specific details about how and what to compact. Let’s say we are debugging an error - I might write something along the lines of “This session is about to close and we will continue debugging in next session. We will be debugging this error message [error message…]. Outline everything we’ve tried that didn’t work, make suggestions about what to try next, and outline any architecture or files that will be critical for this work. Everything else from earlier on in this session can be ignored.” I’ve had decent success with that. More so on debugging than trying to hand off all the details of a feature that’s being implemented.

Reminder: you need context space for compact, so leave a little head room.

[nojs]

The best approach is never to get remotely close to the point where it auto-compacts. Type /clear often, and set up docs, macros etc to make it easy to built the context you need for new tasks quickly.

If you see that 20% remaining warning, something has gone badly wrong and results will probably not get better until you clear the context and start again.