Context is the most precious — and most wasted — resource when working with a coding agent. The model does not see your project: it sees only what you put in front of it. If you paste a 2000-line file, the context is noise. If you point to the exact location, the context is a laser beam. The difference between the two is not a nuance: it is the difference between a useful suggestion and one you ignore.

Context is not the screen you have open: it is everything the model receives as input at a given moment. Managing it means deciding what gets in, what stays out, and when it resets.

Context hygiene 🔧

The first rule of context hygiene is counterintuitive: less context is often more context. We are not talking about saving tokens for the sake of saving tokens — we are talking about not polluting the window with distracting material.

Concrete practices:

• Do not paste entire files when you can reference a path and a line number. Most modern tools have commands to read specific files: use them.
• Close residual project tabs if you are using an IDE. Every open file contributes to background noise the model must process.
• New thread for every task. The context of a previous session does not disappear: it persists as residual noise. A refactoring task and a bugfix task should not coexist in the same conversation.
• Chunk large tasks. A task touching 15 files is a task of 15 sub-tasks. Each sub-task gets its own focused context.

A well-configured AGENTS.md reduces output tokens by ~20% because it gives the model the coordinates before it has to ask for them.

It is not just about quantity: it is about information density. A well-calibrated 500-token context beats 5000 tokens of noise.

Code as high-density context 📝

The most efficient context is the code itself — but only if the code is easy to read. This means:

• Descriptive names: a function called processData says nothing; normalizeUserEmails says everything. The model orients itself faster when names carry semantic information.
• Short functions: a 20-line function is a context unit the model can process as a block. A 200-line function is a labyrinth where the model loses the thread.
• Cohesion: files that do one thing well provide predictable context. The model learns the project structure faster when modules are coherent.

Code readability is not an aesthetic luxury: it is the most effective compression format for an LLM’s context.

A model that receives clean code asks fewer questions, generates more targeted suggestions, and makes fewer context errors. It is not magic: it is dense information entering the prompt without noise.

Cache and session stability ⚡

The work session with an agent has its own dynamics, and managing them poorly has concrete costs:

• Do not switch models mid-task. Each model has a slightly different “internal state” — reasoning patterns, error handling, response length. Switching mid-way is like changing the driver during a curve.
• Keep instructions and skills stable. If you have defined rules in AGENTS.md or in a skill, do not alter them mid-session. Instructions are the constraint that keeps the model on track.
• Output costs more than input. A single output token typically costs 3-5x an input token. This means every unnecessary line of context you add not only distracts — it increases the cost of the response.

State management is implicit in most tools: the model does not remember the previous session (unless you force it with copy-paste). But this is an advantage: you can reset context when the task changes, without residual artifacts.

Context stability is not rigidity: it is the guarantee that the model works with the same rules from start to finish of the task.

When NOT to use the agent ⛔

• Tasks where the context is too large for a single session — break them down first, then delegate.
• Situations where the code is too opaque — if you cannot explain the context yourself, the model will not perform miracles.
• When the context is constantly changing — refactoring in progress, unstable dependencies, branches in conflict. Wait for it to stabilize.

Final checklist ✅

• Did I reference specific files and lines, or paste entire contents?
• Is the thread dedicated to a single task, or do previous conversations leave residual context?
• Have complex tasks been broken into sub-tasks with focused context?
• Is the code readable — descriptive names, short functions, cohesion?
• Did I avoid switching models or instructions mid-session?

Further reading 📚

• Blog: Context engineering — the theoretical foundation behind all of this.
• Blog: Maintain a rich context — how to build and maintain dense context over time.
• Writing prompts that work — the previous level: the prompt is the vehicle for context.
• Blog: Modularity = less tokens — modularity as a form of context compression.