Resident Context Inventory

Instruction files, tool definitions, MCP servers — anything that, once placed, loads every turn — get counted, item by item. The goal of reducing them isn't token cost — it's making the resident content you keep actually take effect. But some items can't be reduced by counting, and the inventory's floor never reaches zero.

Problem

Resident content costs one judgment to place and charges rent every single turn afterward. And the force runs in only one direction — an incident happens and an instruction gets added, a useful-looking server gets connected and its tool definitions get added, someone's convention gets added. No one brings a reason to reduce. The person who placed something remembers only the judgment made at that moment, and never sees the payments continuing on every turn since. And the cost of a filled seat shows up not on the invoice but on the quality side — the official docs state plainly that once an instruction file grows long, some instructions can go unread (Official, see in Practice). Paying rent every turn for an instruction that doesn't even apply goes on, unnoticed by anyone.

Context

Applies when:

• Resident content keeps growing — you remember adding, but not removing
• You remember adding a tool or an MCP server — even adding just one server means loading the tool definitions it provides
• It feels like "the instruction I wrote earlier isn't taking effect" — this is where the cost of a filled seat shows up first

Does not apply when:

• Resident content is still small. Counting itself isn't free
• There's no material for judging what's safe to discard. Resident content whose purpose is unclear survives an inventory pass as "probably needed." The correct order is applying Failure as Institutional Memory's form — write it concretely — first
• The idea strikes mid-task. Taking inventory moves the preamble and breaks the cache once. Doing it in a batch at a natural break is cheaper

Boundary with neighboring patterns:

• Failure as Institutional Memory — that pattern grows resident content; this pattern shrinks it. A direct tension (resolved in Solution)
• Read-and-Discard Isolation — reducing what keeps loading every turn is this pattern; expelling what suddenly balloons in the moment is that pattern
• Session Boundary Design — that pattern handles the conversation (the side that piles up); this pattern handles resident content (the side that loads every turn). Different sections of the same context window
• Instruction Layering and Scoping — scoping is one way to reduce residency. That pattern is how to scope; this pattern is how to count and discard
• Keeping the Prefix Stable — taking inventory moves the preamble. Its frequency and unit are constrained by that pattern

Solution

Why this works. First, the cost of resident content is a multiplication. The judgment to place it happens once; the payment happens once per turn. The two are separated in time — it looks cheap at the moment of placing it, and no one is watching at the moment of paying for it. Taking inventory works not because it introduces a new discipline, but because the mere act of "looking" closes this asymmetry. The moment you count, the one-time judgment and the per-turn payment land on the same screen.

Counting is done item by item. Looking only at the total lets you discard nothing. Only once broken into items can you tell where the floor is, and where your own judgment begins above it. And the floor isn't zero — the official docs state that system instructions and tool definitions "are always present and take up a fixed portion of the context window" (Official, see in Practice). Taking inventory isn't the claim that everything can be reduced. Trying to shrink what can't be shrunk, and neglecting what can, both come from the same failure to count.

Next, don't mistake the motive. Reducing resident content is often thought to be about token cost, but the real subject is effectiveness. The official docs state that a long instruction file "may result in some instructions being overlooked," and a different vendor writes that "longer files consume more context and reduce adherence" (both Official, see in Practice). Two companies, independently, tying length to quality. In other words, reducing resident content is what makes the resident content you keep actually take effect. It looks like a cost question; it's a quality question.

So the test isn't "is this expensive" — it's "is this worth having read every single turn."

This test isn't new. It's the same single test as Failure as Institutional Memory's "write only what the model has no way of knowing." That pattern applies it before something is placed; this one applies it after. So the two patterns don't conflict — this pattern isn't saying "don't add." A memory that meets the condition may be added; what's subject to inventory is resident content that doesn't earn its rent. But even when the conflict resolves, the cost doesn't disappear. Even a memory the model has no way of knowing incurs rent every turn. If resident content meeting the condition keeps growing, eventually you either scope it (Instruction Layering and Scoping) or accept that you're near the floor.

Finally, whether something can be inventoried is decided not on the day of the inventory but on the day it was placed. Resident content written abstractly, like "check carefully," gives no one a way to judge when it stopped being needed, and it survives an inventory pass. Only resident content stating the condition under which it's needed can actually be discarded.

Trade-offs

Advantages

• What remains gets easier to make effective. This is an improvement not in cost but in adherence. It's the official docs that tie length to adherence causally (Official, see in Practice), not a guess by this catalogue.
• Free space grows. Free space isn't the goal itself — it's the seat available for actual work. A long conversation, a sudden burst of investigation, both sit there. Keeping resident content thin is also making room for other patterns to work.

Costs

• When discarded resident content turns out needed again, no one notices. Residency is countable when it's "there," but "not there" is invisible. That discarding broke something can't be observed until it shows up as a failure. So the side making the discard decision needs the condition for safe discarding written down (Failure as Institutional Memory's triple is that form).
• Taking inventory breaks the preamble. Because resident content sits at the head of the preamble, moving it means rebuilding everything after it. Every inventory pass carries this rebuild cost (Keeping the Prefix Stable). This is why "whenever it occurs to you" is worse than "in a batch, at a natural break."

GitHub Copilot in Practice

Copilot isn't a single product. The difference that matters most for this pattern is that the means of "seeing" resident content differs by surface. Copilot CLI shows an itemized breakdown; VS Code surfaces totals and a breakdown from the chat input.

Copilot CLI — the inventory is itself a product feature

Source: Context management in Copilot CLI (retrieved 2026-07-16).

The same page defines what's resident Official:

• System instructions and tool definitions: The built-in instructions that tell Copilot how to behave, plus the schemas of all available tools. These are always present and take up a fixed portion of the context window.

Built-in instructions and the schemas of all available tools are always present and take up a fixed portion of the context window. Solution's "the floor never reaches zero" is written here as the official definition itself. This also means tool definitions have no option to "keep it, but thinner" — a tool's schema is present because the tool is available.

And the /context breakdown becomes exactly this pattern's invoice Official:

• System Prompt: the base system prompt.
• Custom Instructions: your loaded custom instructions (shown only when present).
• System Tools: built-in tool definitions.
• MCP Tools: tool definitions contributed by MCP servers.
• Messages: your conversation history.
• Free Space: unused context still available.
• Buffer: capacity reserved for the model's response and headroom.

This pattern's practice — counting resident content item by item — exists as an actual product feature. Three things stand out. First, MCP Tools is its own item — adding one MCP server means loading the tool definitions that server provides onto every subsequent turn. It's its own item precisely because it's the item that swells. Second, Custom Instructions is shown only when present — an item only whoever placed it pays for. Third, of the seven items, System Prompt and Buffer are not something the user placed — count them and there's nothing to reduce.

Both a way to see it and a way to remove it are provided (source: Copilot CLI command reference, retrieved 2026-07-16) Official:

Command / flag	Original text (verbatim)
/context	Show the context window token usage and visualization. …
/instructions	View and toggle custom instruction files.
--no-custom-instructions	Disable loading of custom instructions from AGENTS.md and related files.

/instructions being a toggle feeds directly into the practice of inventory-taking. You can turn something off and watch what happens before discarding it.

VS Code — a way to remove, and a place to look

Source: Optimize your AI usage in VS Code (retrieved 2026-07-16) Official. The same page recommends inventory-taking itself:

Every tool call produces output that consumes space in the context window and contributes to credit consumption. Disable tools you don't need for the current task to prevent unnecessary calls.

"Disable tools you don't need for the current task" — the official docs push toward removing tools. But this text speaks only to the output of a tool call taking up a seat. The claim that the definition (schema) itself is resident comes from the Copilot CLI text above. The same "disable your tools" is written for different reasons depending on the surface.

Where to look isn't an itemized list — it's the chat input Official:

To view the cumulative cost and token breakdown for the entire session, hover over or select the context window control in the chat input.

github.com — custom instructions for code review

What this section's Official quotes actually cover

The text below describes custom instructions for Copilot code review. Do not cite it as a benchmark for instruction files in general.

Source: Using custom instructions to unlock the power of Copilot code review (retrieved 2026-07-16) Official:

• Context limits: Very long instruction files may result in some instructions being overlooked.

The official docs state that length lowers effectiveness. But what the original text names is code review custom instructions, so no general line-count guideline for instruction files in general follows from this sentence. Only the direction follows — get longer, and it moves toward being overlooked.

Equivalents in other tools

Claude Code's docs tie residency's cost and effectiveness together in one place (source: Claude Code memory (CLAUDE.md), retrieved 2026-07-16) Official:

CLAUDE.md files are loaded into the context window at the start of every session, consuming tokens alongside your conversation. ... Because they're context rather than enforced configuration, how you write instructions affects how reliably Claude follows them. Specific, concise, well-structured instructions work best.

Loaded into the context window at the start of every session, consuming tokens alongside your conversation. This is the equivalent of "residency," in another tool. The same page also ties length and adherence together causally Official:

Size: target under 200 lines per CLAUDE.md file. Longer files consume more context and reduce adherence. …

⚠ The original text says target under — a target, not a ceiling. Don't read it as "crossing 200 lines is a violation." What this catalogue adopts is the causal claim — longer files consume more context and reduce adherence. GitHub's overlooked and Anthropic's reduce adherence are two separate companies, on two separate products, writing the same direction. This pattern's claim — that the reason to reduce residency is effectiveness, not cost — stands on that agreement.

Observed in real-world use

In one individual repository (observation as of 2026-07-07, Claude Code environment, n=1), the amount of resident content was actually measured. Not written as a general law.

What was observed Measured

• The project's CLAUDE.md is 86 lines
• Skills have bodies, but only the description is resident, at about 9% of the total body

Not observations (the auditor's judgment, not Measured)

• That this setup is working was not observed. No one measured adherence with resident content doubled, so there's no counterfactual. The grounds for effectiveness aren't a measurement — they're on the official docs' side (overlooked / reduce adherence)
• 86 lines is not a target for other repositories. All that's visible is that "in this environment, residency stayed under half of the folklore guideline" — that it is the right amount was not observed

Counting and discarding are different things

Both the line count and the ratio are visible without running a counterfactual. "So it's working" is not visible. Inventory-taking provides only the former — a number helps a discard decision; it doesn't substitute for one.

Also Known As

Name	Source
Context breakdown display (/context)	Primary — but this names the means of observation, not this pattern (the practice of counting and discarding) (source: in Practice section above)
Resident Context Inventory	Descriptive — this catalogue's descriptive name; no primary source uses it

The official docs give a name only as far as the means of seeing. /context shows a breakdown, but it doesn't ask "is this item worth reading every turn." The tool stops at producing a number; the discard decision stays with the user. It's the same shape as the Also Known As section of Failure as Institutional Memory — there the tool gives a container and leaves the content undecided; here it gives a number and leaves the judgment undecided. Naming always stops just past where the tool stops.

Related

• Failure as Institutional Memory — that pattern grows resident content; this pattern shrinks it. A direct tension, but they share a test ("write only what the model has no way of knowing" = "is this worth reading every turn"). That pattern's triple is also this pattern's precondition — a memory with no stated condition can't later be judged safe to discard
• Read-and-Discard Isolation — reducing what keeps loading every turn is this pattern; expelling what suddenly balloons in the moment is that pattern
• Session Boundary Design — the conversation (the side that piles up) is that pattern; resident content (the side that loads every turn) is this pattern. Different sections of the same context window
• Instruction Layering and Scoping — scoping is a way to reduce residency without discarding it. That pattern is how to scope; this pattern is how to count and discard
• Keeping the Prefix Stable — taking inventory moves the preamble, and each pass rebuilds it. Its frequency and unit are constrained by that pattern
• If reading just one more next: Instruction Layering and Scoping — it covers how to reduce the resident content an inventory pass turns up