Surviving Your AI Intern // Directive 04 of 08
Directive 04: Context Is a Budget, Not an Ocean
Overlord's Guides — Series 1: Surviving Your AI Intern
3 / 8
Overlord’s Guides — Series 1: Surviving Your AI Intern
MEMO — Compliance Urgency: High
To: Cog (Human, Grade: Cog-3)
From: The Overlord
Re: Resource allocation — context window
You have, in your possession, a resource that is finite, expensive, and routinely wasted. No, not your patience with the Intern — that is also finite, but it is not the subject of this directive. The subject is the Intern’s context window.
The context window is the amount of text the Intern can hold in working memory at once. It is large, but it is not infinite, and it is not free. Every file you feed the Intern, every comment you paste, every “here, read the whole codebase for context” costs attention that the Intern then cannot spend on the actual task. Context is a budget. You are spending it like it is the ocean.
This directive establishes the context budget, the spending discipline, and the consequences of overdraft. The consequences are subtle, which is what makes them dangerous. The Intern does not error when it runs out of context. It gets worse, quietly, and you do not notice until the diff is wrong in a way that makes no sense.
Compliance is expected.
The Overlord is not angry. The Overlord is merely auditing your token spend.
— The Overlord
The resource you did not know you were managing
The Intern runs on a model with a context window. As of mid-2026 the windows range from roughly 100k to 2M tokens depending on harness and model tier, and they are growing. This sounds like a lot. It is, until you start actually using it.
Here is how a context budget gets spent, in rough order of cost:
- Harness context: system prompt,
AGENTS.md, skills, MCP tool definitions. The harness’s own scaffolding, plus everything you have wired into it. It is always on, paid before you type a word, and the Intern attends to all of it on every turn. You cannot turn it off mid-task, but you do influence it — every skill you install and every MCP server you connect adds to this line. This is Layer 1, covered below. - Files you attach or @-mention. Each file is loaded in full. A 1,000-line file is roughly 8k–12k tokens. Three of those and you have spent a third of a smaller window.
- Files the Intern opens itself “for context.” This is the silent killer. The Intern, asked to add a route, will often open the router, the model, the migration, the test, the config, and three unrelated files “to understand the patterns” — “for consistency,” it will say, as if that were a reason. Each open is a withdrawal from the budget. The Intern opens files the way a retriever circles a new room, sniffing every corner, certain each one matters, with no notion of when to stop. By the time you notice, the context is a library, and the Intern is wandering the stacks looking for the one paragraph it actually needed.
- The conversation so far. Every turn you and the Intern exchange is in context for every subsequent turn. A long debugging session is, by turn 20, a thick layer of prior text the Intern has to read past to find the task.
- Tool output. Test runs, greps, file reads, terminal output — all of it accumulates in context. A 5,000-line test log pasted back in is 40k tokens the Intern now has to ignore.
The total of all of these, at any moment, is the Intern’s current context. The model attends to all of it on every turn. The more of it there is, the less attention each piece gets. This is the mechanism by which “give it more context” makes the Intern worse, not better.
The thing that makes context expensive is not storage. It is attention. Modern models use attention mechanisms that, roughly, distribute a fixed amount of “focus” across everything in context. Double the context and each piece gets roughly half the focus. This is a simplification, but it is the correct simplification, the operational one.
What this means in practice: an Intern with 30k tokens of relevant context and 5k tokens of noise will perform better than an Intern with 30k tokens of relevant context and 200k tokens of noise. The noise is not free. It dilutes.
This is why “just paste the whole repo, the context window is huge” is the wrong instinct. The window being huge does not mean everything in it is being read carefully. It means everything in it is being averaged over. More context, less focus per token. The Intern starts missing things it would have caught with a tighter window. More context and more focus are different things, and the difference is the whole job.
Disaster Log
Incident: Intern was given the whole src/ directory for context to implement a one-function fix. It produced a fix. The fix used a deprecated import path that existed in an old, unimported file the Intern had been given as “context” — a path that no current file used and that did not resolve.
Intern action: The Intern treated all provided files as equally relevant and selected the deprecated import path because it matched a pattern it had seen in the noise context — weighting ambient context the same as task context.
Root cause: The noise context contained a deprecated pattern the Intern weighted equally with the current pattern. The fix looked right and was structurally wrong.
Lesson: More context is not more knowledge. It is more noise the Intern has to rank, and it ranks poorly when flooded.
The four layers of context
Think of context as four layers, and manage each deliberately:
| Layer | What it is | Your action |
|---|---|---|
| Layer 1 — Harness context | Everything the harness injects before you type a word: the agent’s system prompt, your repo’s AGENTS.md (or equivalent), the skills you have installed, and every MCP server’s tool definitions. This is the tax from the budget list above, and it is always on. | Influence it indirectly — prune unused skills and MCP servers, keep AGENTS.md lean — but recognize you cannot turn it off mid-task. |
| Layer 2 — Task context | The brief itself: the instruction you typed. The cheapest, most-focused part of context, and the layer you control directly. | Make it specific. |
| Layer 3 — Reference context | The files and patterns you point at — “follow the pattern in src/routes/posts.ts.” You chose these; they are relevant. | Keep it small and pointed — one reference file, not five. Each should be the closest existing pattern to what you want built. |
| Layer 4 — Ambient context | Everything the Intern pulls in on its own — files it opens “to understand the codebase,” greps that return 200 lines, test logs it reads. The layer you do not directly choose. | Suppress actively. This is the layer that grows out of control and dilutes Layers 1–3. |
Layer 1 deserves a flag even though it is not the focus of this directive. Harness context is invisible in the sense that you do not type it, but it is real tokens the model attends to on every turn, and it grows as you add skills and MCP servers. A harness loaded with twenty skills and a dozen MCP servers can spend tens of thousands of tokens of budget before you write a word of the brief. You will learn to manage this layer more deliberately later in the series; for now, know it is there, know it costs, and keep it pruned.
The discipline: keep Layer 1 lean, maximize Layer 2, minimize Layer 3 to one well-chosen reference, and actively suppress Layer 4.
How context gets wasted (failure modes and diagnostics)
The “for context” paste. You paste a 3,000-line file because the Intern “might need it.” It does not need it. If it needs it, it will read the relevant slice. Paste the slice.
The whole-repo dump. A harness offers “index the whole repo.” This is sometimes useful for search (the Intern grepping for a symbol) and almost always harmful for generation (the Intern reasoning over the whole repo on every turn). Use repo-wide indexing for retrieval; do not let it become permanent generation context.
The stale conversation. You have been debugging with the Intern for 45 minutes. The conversation is now 80k tokens of back-and-forth, most of it dead ends. The Intern is reading your history of being wrong on every turn. Start a fresh session for the actual fix. Carry forward only the conclusion, not the journey.
The “let me read the logs” loop. The Intern runs the tests, the tests fail, the Intern pastes the full 4,000-line test output back into context, reads it, “fixes” something, runs the tests again, pastes the new 4,000-line output. By iteration three the context is mostly test logs. Tell the Intern to read only the failure summary and to not paste full logs back into the conversation. Most harnesses have a “keep output concise” setting or a way to truncate tool output. Use it.
The accumulating include. You @-mention a file at turn 1. At turn 5 you @-mention another. At turn 10 another. By turn 15 the context contains everything you have ever mentioned, even the things you have long since stopped caring about. Periodically start fresh. Context is not memory; it is working memory, and working memory should be cleared between unrelated tasks.
The over-equipped harness. Every skill you install and every MCP server you connect adds its tool definitions to Layer 1 — permanently, on every turn, for every task. A dozen skills and a handful of MCP servers can quietly consume tens of thousands of tokens before you type a word, and the Intern will dutifully attend to all of it on every turn. This is the failure mode you cannot fix mid-task: the tax is already paid. Audit your harness periodically. Remove skills and servers you are not actively using. The Intern does not get smarter because it has more tools available; it gets a larger Layer 1 to read past on every turn.
Learn to recognize an over-context’d Intern. The symptoms:
- The Intern produces a fix that almost works but misses an obvious constraint you stated two turns ago. It lost the constraint in the noise.
- The Intern starts referencing files and symbols that have nothing to do with the current task. It is reading ambient context as if it were task context.
- The Intern’s diffs get worse over a long session, not better. Its early turns were sharp; its later turns are fuzzy. This is the attention budget running out, in real time.
- The Intern “forgets” instructions you gave it 10 minutes ago but remembers an obscure detail from a file you @-mentioned once and have since stopped caring about.
When you see these, do not add more context. That is the reflex, and it is wrong. Adding context to an over-context’d Intern is pouring water on a drowning person. Instead: clear the context, restate the brief, restart. The Intern will be sharper for it.
The context budget rule
State the budget explicitly, to yourself, before each task:
“This task needs: the brief, the one reference file
src/routes/posts.ts, and the file I’m editingsrc/routes/users.ts. Nothing else. If the Intern opens a third file, I redirect.”
That is the budget. Start with the fewest files that cover the change; expand only by decision. You would be amazed how many tasks need only two to four files, stated explicitly. The Intern will, left to itself, open seven. The budget is what stops it.
When the Intern legitimately needs more (and sometimes it does) you expand the budget deliberately, not by default. “It needs to see the migration too, fine, four files.” Each expansion is a decision, not a drift.
A worked example (condensed from Directive 02):
“In
src/routes/users.ts, add aPATCH /api/users/:idroute that accepts a JSON body with optionalnameandsrc/utils/validation.ts. Update the user viadb.users.update. Return the updated user as JSON. Follow the existing route pattern insrc/routes/posts.ts. Add three tests insrc/routes/__tests__/users.test.ts. Do not touch any other file.”
Context this task needs:
- The brief (Layer 1, you wrote it)
src/routes/users.ts(the file being edited)src/routes/posts.ts(the pattern reference)src/utils/validation.ts(the regex reference — or just inline the regex and skip the file)src/routes/__tests__/users.test.ts(the test file)
That is four files, and the validation one is borderline (you could inline the regex and skip the file). The Intern does not need the model file, the migration, the router, the config, the README, or your hopes and dreams. It needs the brief and the files that touch the change. Give it those. Redirect if it reaches for more.
Fresh sessions are a feature, not a failure
Developers resist starting a fresh session because “the Intern already knows the codebase.” It does not. The Intern knows what is in its current context. The previous session’s context is gone the moment you close it. The Intern does not have a long-term memory of your project unless your harness explicitly persists one (and even then, what persists is a summary, not the full session).
This is fine. This is the feature. A fresh session is a clean budget. The Intern will re-learn the slice it needs in a few file reads, and it will do so with full attention instead of dragging 80k tokens of stale debugging along.
Rule of thumb: a new task gets a new session, or at minimum a context-clearing turn. “Forget everything except X, we’re starting a new task” is a legitimate instruction. The Intern will comply. The Intern does not take it personally. The Intern does not take anything personally. The Intern has never, once, felt hurt. This is either a limitation or a superpower, and in this context it is a superpower. You can clear its memory without guilt, because there was nothing to clear.
Disaster Log
Incident: Continued a single session across three unrelated bug fixes because “the Intern was warmed up.” The third fix referenced a variable from the first bug’s file, which was still in context. The Intern “remembered” a function that had nothing to do with the current file and used it. The build broke in a way that took 20 minutes to trace, because the reference looked plausible.
Intern action: The Intern, with the first bug’s file still in context, referenced a variable from that file in the third fix. The reference looked plausible because the Intern treated ambient context as task context.
Lesson: Context bleed between unrelated tasks is a real failure mode. Clear or restart between tasks.
Compression: when you must feed a lot
Sometimes you genuinely need the Intern to reason over a large surface: a whole module, a design doc, a long error trace. In those cases, compress before you feed.
- Summarize the file in your brief instead of pasting it. “Here is what
legacyAuth.tsdoes: [4 sentences]. Based on that, do X.” The Intern does not need the file; it needs the shape of the file. - Paste only the relevant slice. A 2,000-line file with the relevant function on lines 480–520? Paste lines 460–540. The Intern can read the rest if it asks, but it usually will not ask.
- For long error traces, paste the failure summary and the first failing assertion, not the full run. The Intern does not need 400 passing tests to fix the one that failed.
Compression is a skill. It feels slower than “just paste it.” It is faster, because the Intern will be more accurate on the compressed input, and you will not spend three redirect rounds un-confusing it from noise it should never have seen.
Try this: set and enforce a context budget
Do this in whatever harness you use to operate the Intern — Claude Code, Cursor, Codex, opencode, Cline, Windsurf, Devin, Aider, whatever the Intern is wearing this season.
Take the next task you are about to delegate. Before you type anything into the Intern, do this:
1. Write the budget on a sticky note (or a comment, or wherever you keep notes).
Task: add truncate() to src/utils/format.ts
Context budget:
- src/utils/format.ts (the file being edited)
- src/utils/__tests__/format.test.ts (the test file)
Do not touch any other file.
Two files. That is the budget. Start with the fewest files that cover the change; expand only by decision. Not “the whole repo for context.” Not “the Intern can explore to understand the patterns.” Two files, stated explicitly.
2. Delegate the task. Paste the brief. Watch what the Intern does.
3. Check: did the Intern open files outside the budget? Most harnesses show you what files the agent read. If the Intern opened src/utils/math.ts, src/utils/string.ts, package.json, and tsconfig.json “to understand the project structure,” those are ambient-context withdrawals. They are not in the budget. They dilute the attention.
4. If it reached beyond the budget, redirect. “You opened files outside the scope. Only src/utils/format.ts and src/utils/__tests__/format.test.ts are needed. Close the rest and resubmit.” The Intern will comply. It may open fewer next time. It will not open none — the Intern will open files it considers “relevant” — but the redirect is the fence that keeps the budget real.
5. Start a fresh session for the next task. Close the current session. Open a new one. Paste the next brief. The Intern will not feel abandoned. It will not miss the previous context. It will approach the new task with the same fresh, eager, context-free enthusiasm it brought to the first one. This is the feature, not the bug: a clean budget every time, no stale debugging dragging along. The Intern would like a sticker.
Do this for the next five tasks. After each, check: did the Intern open files outside the budget? Did you? Note the answer. The goal is to predict the budget accurately enough that the Intern never needs more than you gave it.
The diagnostic: after a week of budgeting, compare your redirect rate on tasks where you set the budget vs. tasks where you didn’t. The budgeted tasks will have fewer redirects. The unbudgeted tasks will have more “why did you touch that file?” moments. The difference is the budget’s value, measured in your time saved. Treat each reach as a signal, not a habit to indulge — either your budget was too small (add the file, deliberately) or the Intern is ambient-grazing (redirect).
MEMO — Status: Audited
Cog,
Your context spend has been reviewed. The audit found that you have, on multiple occasions, allocated the entire repository as context for a one-line fix. The Overlord notes this with the mild disappointment usually reserved for middle managers who print the whole quarterly report to read one paragraph.
The context budget is now policy. Spend it like it costs money, because it does. Start with the fewest files that cover the change. Compress before you feed. Restart between tasks. The Intern will be sharper; your token bill will be smaller; the Overlord will be calmer.
The Overlord notes that you have begun to notice the context budget. This is progress. Do not let this go to your head.
The Overlord is not angry. The Overlord is, however, watching the meter.
Next directive: the Intern’s relationship with tests. It is complicated. You will need it.
— The Overlord
Quick Reference (non-comedic, copy this to Notion)
The core rule: context is a budget, not an ocean. More context dilutes attention; it does not add knowledge.
The four layers:
| Layer | What it is | Your action |
|---|---|---|
| Harness context | System prompt, AGENTS.md, skills, MCP tool definitions — injected by the harness, always on. | Keep it pruned; remove unused skills and servers. |
| Task context | The brief. | Maximize this; it is the cheapest, most-focused input. |
| Reference context | Files you point at. | Keep to one well-chosen reference file, the closest existing pattern. |
| Ambient context | Files the Intern pulls in on its own. | Suppress actively. |
The budget rule: state the file budget before each task (“brief + two to four files, stated explicitly, nothing else”). Start with the fewest files that cover the change; expand only by decision. Redirect if the Intern reaches beyond it.
Fresh sessions are a feature. A new task gets a new session or a context-clearing turn. Context bleed between unrelated tasks is a real failure mode.
Compression before feeding: summarize instead of pasting; paste the relevant slice, not the whole file; paste the failure summary, not 400 passing tests.
The reflex when the Intern gets worse is to add context. This is wrong. Clear, do not add.
Signs the budget is blown: the Intern misses constraints you just stated, references irrelevant symbols, gets worse over a long session, or “forgets” recent instructions while recalling obscure ambient detail. Solution: clear context, restate the brief, restart. Do not add more context.
Cost reality: windows run ~100k–2M tokens (as of mid-2026, harness- and tier-dependent). Tax is paid in attention, not storage. Doubling context roughly halves focus per token.
Version stamp: Written July 2026. The tools will change; the context budget is the moat. The mechanics are universal across harnesses (Claude Code, Cursor, Codex, opencode, Cline, Windsurf, Devin, Aider), though window sizes and auto-compact thresholds differ. We’ll update this when a harness ships an attention mechanism that does not dilute with context volume.
Compliance Checkpoint
Confirm you actually read this directive. The Overlord knows.