It’s still early days in the young field of agentic coding. We don’t have many commonly agreed best practices, and those we did develop in 2025 are mostly already irrelevant in 2026.

I am noticed one difference, which may (or may not) affect results but certainly affects token usage, and so may reflect a difference in coders who pay for their own tokens vs those who don’t.

Some coders seem to prefer very long sessions with their agents. They care about reducing token usage only to the extent that they are forced to because their context is entirely full with tokens. So they look to memory systems that can avoid storing data in context, and ways of “compacting” a session down once the context is full. I suspect they may also be the same people who love to use sub agents, because they can fire them off willy nilly without affecting the context of the main agent. (But maybe I just haven’t figured out how to benefit from sub agents yet.)

I typically try to keep context under 25% full. The vast majority of tokens used in a session are the cached context tokens. Yes they are cheaper because they are cached, but they still dominate the total costs, so my costs will average a quarter of those of someone who typically works close to 100% full context. (This assumes of course that I can still achieve the same results in the same number of turns, which may not be true.)

I start a new session for almost every feature. When iterating on a feature, debugging it or adding a second similar feature it can be very tempting to maintain context, but even here I often prefer to have the agent decide which parts of the session are actually relevant and save them to a file for use by the new session.

If I know exactly which files will need editing then I manually add those files to the context rather than have the agent grep the entire codebase.