Give your agent persistent repo memory — and pay for it only when it helps

On a big repo, your agent has amnesia. Every session it greps again, re-reads the same files again, rebuilds the same mental map — then throws it away. Asking "how does this subsystem work?" or "what breaks if I change this signature?" blows the context window and your token budget, and you can't tell when the effort actually paid off.

My Architect's Claude Code plugin gives the agent persistent memory of the repository — a local code graph it can navigate instead of re-ingesting everything. The honest part: the graph doesn't make every question cheaper. We measured it, and we'll show you exactly where it earns its keep and where it doesn't.

The problem, measured

We profiled this on our own repository first. Gathering facts about a codebase the agent already "knew" cost roughly 77k tokens and 20 tool calls — every session, on repeat, because none of that understanding survives past the conversation. Impact questions ("who consumes this symbol, what breaks if I change it?") are worse: answering them correctly means finding every consumer, which means a full pass over the repo — knowledge that, again, has nowhere to live.

That is the pain this use case removes: repeated whole-repo ingestion, and no way to know when the spend was worth it.

How My Architect fixes it

The plugin ships two skills that work together: recursive-context (index-don't-ingest discipline for oversized inputs) and code-graph awareness (Graphify integration). Neither is a new engine you have to trust blindly — they're discipline plus a local tool.

Step 1. Connect the agent

Connect Claude (or any MCP agent) to your project the usual way — see connecting an AI agent. The plugin installs the skills alongside the MCP tools in one step; you don't wire anything up per repo.

Step 2. Let it build the graph — on consent

Graphify is open source (MIT), parses your code via tree-sitter across 36 languages, and runs fully local: no API calls, no telemetry. It stores a graph of symbols and relations, plus an interactive HTML map and a text report, right next to your code.

You don't run a wizard. On a heavy task with no graph present, the agent offers — once — to install and build it, and only proceeds after you say yes. Silent installs are forbidden. On our repo the build took seconds and produced thousands of nodes and edges plus auto-found clusters, immediately surfacing "god nodes," import cycles and forgotten links. The important part for your budget: building and querying the graph spend zero model tokens — both are local utilities, not model calls.

Step 3. Ask the hard question

Now "what calls this function across 2125 files?" comes back from a near-instant local query, with paths — not a full grep pass. The agent answers subsystem and impact questions by navigating the graph instead of re-reading the tree.

The discipline that keeps a stale index honest

An index is a cache, and a cache can lie — it lags the code between rebuilds. So the feature is built on three rules, not on commands:

The graph is navigation, not fact. A query tells the agent where to look; something becomes a fact only when a live file confirms it. The proof contract is unchanged: only the code becomes a fact.
The freshness check is mandatory. Before trusting the index, the agent compares the index build time against the last commit. Stale? It says so out loud, offers a rebuild, and marks any candidates as coming from a stale index. A stale index can't quietly lie to you.
Verify by region. A candidate arrives with a path:line coordinate; verification reads about ±30 lines around it, not the whole file — otherwise verification would eat everything the graph saved.

The payoff — and the honest ceiling

Here is the aha, and we're going to give you the numbers instead of a slogan. We ran a controlled A/B on NestJS (2125 files — an order of magnitude larger than our own repo): two identical clones, one with the graph and one without, with prompts identical down to the path and not one word about the graph. The with-graph arm had to find it itself.

The result is selective, on purpose:

Understand a subsystem end-to-end — the graph won. Roughly 76k tokens with the graph vs ~262k without: about −71%, ~3.5× cheaper. Not because a query beats grep token-for-token, but because the graph narrowed the corpus up front, so one agent handled what the graph-less arm had to silently fan out across five sub-agents.
Impact questions ("who calls this, what breaks") — parity on tokens. Grep on a literal symbol name is cheap even at 2125 files; the graph's win there is completeness and speed, not budget.
Full subsystem audit — parity too. Both arms need orchestration; the graph doesn't shortcut the work.

And a methodological catch worth your attention: by top-line numbers the graph-less arm on "understanding" looked cheaper — until we opened its transcripts and found 205.8k tokens of nested agents the summary never counted. An honest measurement counts the whole tree of agents. We suspect a fair share of "90% savings" benchmarks don't.

So the aha isn't a multiplier. It's this: the agent answers what calls this across 2125 files from a near-instant local query, and the A/B tells you precisely when the graph earned its keep and when it didn't. No universal multiplier — a task class that saves, not a slogan. If you want the full write-up, the complete code-graph experiment with the token-savings measurements and the index-check discipline lays out the method and its limits (n=1 per cell, one repo, one model tier).

How to try it

Sign in and create a project — see getting started.
Connect your agent following connecting an AI agent; the plugin brings the recursive-context and code-graph skills along.
Point the agent at a large, unfamiliar repo and ask a subsystem question. When it offers to build the graph, say yes — then watch whether the answer comes from a query or a full read.

The index says where to look; only the code becomes a fact — and now the meter tells you which questions were worth indexing for.