Optimizing Your Context Window: How to Stop Burning Tokens in Python Projects

Monday morning, after the sprint meeting, all the tasks are defined for the week. I start by dumping the ticket description into Claude Code and wait comfortably with my coffee, scrolling Instagram, until the agent finishes. Last time, it took 3 hours and burned through all the tokens for the week.

I’ve hit my 5-hour limit too many times, and the weekly limit scares me too.

But by changing some habits, I’ve been able to reduce token consumption, and now I don’t even burn through the 5-hour token window on my Claude Pro account.

I must know the project better than the AI

At every prompt, the AI has to read the files, the structure, the database schema… again and again to understand the project and know where to implement the feature. The AI’s memory is limited to the current conversation.

I know the project — I’ve been working on it for years. So I pin the files where the changes should be made, instead of letting the agent search for them.

For example, when adding a field to the User entity, I pin models/user.py, schemas/user_schema.py, and the migration file directly, rather than asking the agent to locate them. For a checkout bug, I pin services/checkout_service.py and controllers/checkout_controller.py instead of letting the agent scan the whole services/ folder.

Keep a README updated with the main features and architecture

When making changes across several layers, the agent needs a global view of the system. There are two ways to get there: either it reads the whole folder structure and a couple of files per directory, or the documentation (README plus markdown files under a docs folder) is kept up to date.

This way, the agent gets a global view without reading the entire project over and over.

For instance, a docs/architecture.md describing the layers (controllers, services, repositories) and how they interact saves the agent from opening a dozen files to understand the data flow. A docs/api.md listing the main endpoints and contracts lets it implement a new endpoint by pattern-matching instead of reading every existing controller.

Use plan mode

When the changes are complex, beyond what I can reason through quickly, I ask for advice using plan mode.

Plan mode reads the available documentation, then reads a few specific files where the solution could be implemented, and finally lists alternatives that fit the current architecture.

Once the plan is approved, the agent keeps that information in memory and doesn’t need to keep reading files (and burning tokens).

Yes, it consumes more tokens than targeting a single file directly. But to investigate properly, the agent needs to read several files — services, repositories, and so on — to understand what already exists. While planning, it asks about my preferences, explaining the trade-offs of each option.

At the end, the plan describes exactly what the AI will do. If I’m not satisfied, I ask for changes. Requesting changes at this stage costs very few tokens, since everything is already in memory.

Example: adding a caching layer — plan mode proposes Redis vs. an in-memory LRU cache, with trade-offs, before writing a line of code. Another: refactoring a monolith into modules — it lists the proposed boundaries first, so I can veto a split before any file is touched.

Start a new conversation

What about bugs? Sometimes I start a conversation to investigate one. I share the logs, the cloud architecture, the user’s behavior…

If the bug is simple, I let the agent fix it directly in that conversation.

But sometimes the bug is harder and needs a full refactor. In that case, I start a new conversation to limit the scope (and avoid hallucinations). Before switching, I ask the previous conversation to give me a prompt with all the relevant information, files, and impacts. This is especially useful when the fix lives in a different project from the one where I started.

Example: a memory leak traced to a background worker in a separate repo — I ask the first conversation to summarize root cause and affected files, then paste that into a fresh, scoped conversation. Or when a bug spans frontend and backend repos, I close the exploratory conversation and start two focused ones, each with a pre-digested prompt.