Context Budgeting: Giving Your AI Assistant Only What It Needs

The promise of large context windows was simple: give the model more code, get better answers. In practice, teams are discovering that more code is not the same as more relevant code, and that irrelevant context actively degrades answer quality.

Context budgeting is the practice of deliberately selecting which code goes into the AI's context window for a given task. A code graph makes this selection structural and systematic, rather than based on gut feel.

Why more is not better

Language models have a documented tendency to perform worse as context length increases, particularly for "lost in the middle" scenarios, where relevant information is buried in a long, noisy context window. Adding every file that might be relevant dilutes the signal.

The right context for any coding task is: the target file, its direct dependencies, its direct callers, and (for significant changes) its structural community. Not the whole codebase. Not every file you've opened this week.

The graph-derived context slice

A code graph lets you derive the context slice for any node with a single traversal:

1. Target node: the file or function you're working on
2. Import closure (depth 1): what the target directly imports, its dependencies
3. Caller set: what directly calls the target, context for understanding the interface contract
4. Community peers: the files in the same Leiden community, structurally cohesive context
5. High-centrality community neighbours: load-bearing files adjacent to the target

This slice is typically 5, 15 files, regardless of codebase size. It is structurally bounded, deterministic, and reproducible.

Context drift and context rot

Context rot happens when the files in your AI's context window no longer match the code that's actually running. You pasted auth/session.js three refactors ago. The interface changed. The AI is now reasoning from stale context.

A graph-derived context slice is computed at the current commit. It reflects the code that exists now, not the code you copied last week. Every time you regenerate it, you get the current structural neighbourhood.

This is the difference between a context selection workflow and a context copy-paste workflow.

Spiderbrain's /api/score endpoint

The /api/score endpoint accepts a set of query terms or a node slug and returns the top-ranked files by structural relevance, weighted by spikescore (a combination of centrality, community membership, and query relevance).

The output is a ranked context list: the files most worth including for the given task. Drop these into your AI assistant's context window and the answers improve, because the signal-to-noise ratio improves.

The practical workflow

1. Identify the node you're working on (the function, module, or feature area)
2. Query /api/score with that node as the anchor
3. Take the top N results (typically 8, 12 files)
4. Include those files in your AI assistant's context
5. Work the task; re-query if the scope expands

This is not a perfect system, no context selection is. But it is systematic, auditable, and consistently better than "paste everything I've looked at today."

What changes when context selection is structural

The biggest shift is that context selection becomes a first-class engineering concern rather than an afterthought. Teams start asking "what is the right context for this task?" before asking "what should the AI do?"

That ordering change, understand structure first, apply intelligence second, is the foundation of reliable AI-assisted engineering.