Context Budget
What to give and what not to give matters more than giving a lot.
Treat context as a finite budget to allocate. Every piece of irrelevant content you add takes some attention away from the parts that matter. A model's input window isn't an unlimited warehouse—it's finite attention. Making trade-offs around that fact is the foundation of writing good prompts and getting real value from AI coding tools. claude-code-best-practices
What you'll run into:
- You dump the whole project in, and the answers get vaguer
- The longer the conversation runs, the more often it violates rules agreed earlier
- You paste a long error log and it fixates on the wrong part
What to give
| Give | Share | Notes |
|---|---|---|
| Project constraints | Small | Lean, long-lived rules. Put them first |
| Current module's spec | Small | Data structures, states, boundaries. This block earns its place most |
| Directly relevant files | Medium | The two or three files you want changed, plus the interfaces they depend on |
| This task's instruction | Small | Put it last. Restate the key constraints here |
| White space | About 30% | Headroom for reasoning and output. Pack it full and there's no room left |
Key constraints are worth saying twice: once in the project rules up front, once in this task's instruction. It's a direct counter to the mid-conversation blind spot.
There's also a simple test for "directly relevant": list the files you want changed this round, and include those files plus the interfaces they depend on—the boundary is "affected by this change," and anything beyond it is noise.
What not to give
- The entire repo. Letting it rummage through every file looks easy but actually fills the window with noise. Name the specific files you want changed.
- The full error log. Scan it yourself first, then paste the key lines. Out of a few hundred lines of stack trace, fewer than ten usually matter.
- The entire history of the last topic. Once you finish something, start a new session—don't drag the previous discussion along.
- Large blocks of sample data. Two or three representative rows are enough, including one edge case.
- Things already settled but re-derived over and over. Write them to a file and let it read them—don't have it re-think them each time.
A simple self-check: if you yourself aren't sure whether a piece of content is needed this time, it probably shouldn't be given.
When to clear and restart
| Signal | What to do |
|---|---|
| It starts breaking rules agreed earlier | Write the key decisions to a file, then open a new session |
| It starts repeating things it already said | The useful signal has been diluted—restart |
| You switch to an unrelated task | Open a new session directly; don't keep chatting |
| Three rounds in a row and it's still wrong | Stop. The description is probably the problem—rewrite it clearly and run a new round |
Before restarting, have it summarize this round's conclusions into text you can paste into a file. That way a restart isn't starting from zero.
There's also a structural move: organize the codebase by feature. A login-related change only requires reading the auth directory, instead of pulling a few files from each layer—saving a lot of context. This choice costs almost nothing at project start and is expensive to retrofit later.
How to check your budget. Watch one full session: if the AI starts asking, after the third round, for information you already gave it, the key content got diluted—write what should be persisted into a file and restart. If it answers directly every round without re-confirming, the budget is working.