Trimming Context: Dependency Graphs Instead of Full Repos

For code tasks, the fastest way to bloat a prompt is to paste an entire repository when the model only needs a handful of files.

A dependency graph lets you send structure instead of bulk: a map of what imports what, plus the specific snippets that actually matter.

Summary

A dependency graph is a small data structure that records which files or modules import, call, or otherwise depend on which others.

Instead of pasting a whole codebase into a prompt, you walk this graph from the file being changed and pull in only the files it's structurally connected to.

This keeps the prompt small and focused, which lowers cost and avoids diluting the model's attention with unrelated code.

It also scales better than manually guessing which files are relevant, since the graph is built once and reused across many prompts.

This page walks through building a minimal dependency graph in Python, using it to select relevant files for a change, and sending that trimmed context to Claude.

Recipe

Quick-reference recipe card - copy-paste ready.

import ast
import os
 
def get_imports(filepath: str) -> set[str]:
    with open(filepath) as f:
        tree = ast.parse(f.read(), filename=filepath)
    imports = set()
    for node in ast.walk(tree):
        if isinstance(node, ast.Import):
            imports.update(alias.name for alias in node.names)
        elif isinstance(node, ast.ImportFrom) and node.module:
            imports.add(node.module)
    return imports

When to reach for this:

• The task is about one file or function, but that file lives inside a much larger repo.
• You want Claude to understand how a change ripples to callers, without sending every caller's full source.
• The repo is too large to fit in a single prompt even at a generous context window.
• You're running the same kind of code-review or refactor prompt repeatedly and want a reusable selection step.

Working Example

import ast
import os
import anthropic
 
client = anthropic.Anthropic()
 
 
def get_imports(filepath: str) -> set[str]:
    """Return the set of module names a Python file imports."""
    with open(filepath) as f:
        tree = ast.parse(f.read(), filename=filepath)
    imports = set()
    for node in ast.walk(tree):
        if isinstance(node, ast.Import):
            imports.update(alias.name for alias in node.names)
        elif isinstance(node, ast.ImportFrom) and node.module:
            imports.add(node.module)
    return imports
 
 
def build_dependency_graph(repo_root: str) -> dict[str, set[str]]:
    """Map each file path to the module names it imports."""
    graph = {}
    for dirpath, _, filenames in os.walk(repo_root):
        for name in filenames:
            if name.endswith(".py"):
                path = os.path.join(dirpath, name)
                graph[path] = get_imports(path)
    return graph
 
 
def module_name_to_path(repo_root: str, module: str) -> str | None:
    """Best-effort mapping from a module name back to a file path."""
    candidate = os.path.join(repo_root, *module.split(".")) + ".py"
    return candidate if os.path.exists(candidate) else None
 
 
def relevant_files(repo_root: str, target_file: str, graph: dict[str, set[str]]) -> set[str]:
    """Files the target imports, plus files that import the target."""
    related = {target_file}
    for module in graph.get(target_file, set()):
        path = module_name_to_path(repo_root, module)
        if path:
            related.add(path)
    for path, imports in graph.items():
        target_module = os.path.splitext(os.path.relpath(target_file, repo_root))[0].replace(os.sep, ".")
        if target_module in imports:
            related.add(path)
    return related
 
 
def prompt_with_trimmed_context(repo_root: str, target_file: str, question: str) -> str:
    graph = build_dependency_graph(repo_root)
    files = relevant_files(repo_root, target_file, graph)
 
    context_blocks = []
    for path in sorted(files):
        with open(path) as f:
            context_blocks.append(f"# {os.path.relpath(path, repo_root)}\n{f.read()}")
 
    prompt = f"{question}\n\n" + "\n\n".join(context_blocks)
 
    response = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=500,
        messages=[{"role": "user", "content": prompt}],
    )
    return response.content[0].text
 
 
answer = prompt_with_trimmed_context(
    repo_root="./billing_service",
    target_file="./billing_service/retry_queue.py",
    question="If I add a max_attempts parameter to retry_queue.py, what callers break?",
)
print(answer)

What this demonstrates:

• build_dependency_graph walks a repo once and records each file's imports, which is cheap to compute and reusable across many prompts.
• relevant_files walks one hop in both directions: what the target file imports, and what imports the target file.
• Only the files in that one-hop neighborhood are read and included in the prompt, not the entire repo.
• The graph-building step is separated from the prompt-building step, so the same graph can answer many different questions about different files.

Deep Dive

How It Works

• ast.parse turns Python source into a syntax tree without executing it, which is the safe, standard way to inspect imports.
• Walking the tree with ast.walk finds every Import and ImportFrom node regardless of how deep it's nested in the file.
• The graph itself is just a dictionary mapping file paths to the module names they import, which is enough to answer "what does X depend on" and, by inverting the lookup, "what depends on X."
• Selecting a one-hop neighborhood (direct dependencies and direct dependents) is usually enough context for most single-file changes; deeper traversal pulls in more files at the cost of a larger prompt.

Choosing Graph Depth

Going beyond one or two hops usually reintroduces the problem this technique is meant to solve: the prompt grows back toward "the whole repo," just with extra steps.

Python Notes

# Guard against files that fail to parse (syntax errors, non-UTF8, etc.)
def get_imports_safe(filepath: str) -> set[str]:
    try:
        return get_imports(filepath)
    except (SyntaxError, UnicodeDecodeError):
        return set()

Real repos have generated files, vendored code, or occasional syntax errors from in-progress edits.

Wrapping the parse step so one bad file doesn't crash the whole graph build keeps this practical to run on a real codebase.

Gotchas

• Relative imports resolve incorrectly. ast reports the literal module string, so a relative import like from . import utils needs package-aware resolution, not simple path joining. Fix: resolve relative imports against the importing file's package path, or restrict the graph to absolute imports for a simpler first version.
• Dynamic imports are invisible to ast. Code that imports via importlib.import_module(computed_name) won't show up as a static Import node. Fix: treat dynamically-loaded modules as a known gap, and manually add known dynamic dependencies to the graph.
• The graph goes stale if it's built once and cached forever. A codebase that adds new imports won't be reflected in an old graph. Fix: rebuild the graph on each run for small repos, or invalidate the cache on file changes for larger ones.
• Circular dependencies can cause unbounded traversal at higher hop counts. Two files that import each other, chained through several more files, can make a "2 hop" traversal pull in far more than expected. Fix: track visited files during traversal and stop revisiting the same file.
• A one-hop neighborhood can still miss the actually relevant file. Some architectural changes affect a file with no direct import relationship, such as a config value read by convention rather than import. Fix: treat the graph as a starting point, not a guarantee, and let a human or a cheap relevance-scoring pass add files the graph misses.

Alternatives

FAQs

Related

• How Context Engineering Reduces Token Spend - the broader mental model this technique fits into.
• Prompt and Context Engineering Basics - hands-on examples of trimming prompts, including a simpler relevance-scoring approach.
• Summarization Before the Call - what to do when a selected file is still too long.
• Avoiding Redundant Tool Calls in Multi-Turn Agent Loops - a tool-use alternative to pre-computing a graph.
• Context Rot: Why More Tokens Doesn't Mean Better Answers - why including unrelated files can hurt answer quality, not just cost.

Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5 - and the official anthropic Python SDK (latest 0.x release). Model names, pricing, and SDK versions move quickly - verify current specifics at platform.claude.com/docs before relying on them.