Graphify: building a graph of your codebase to cut token usage and request time

Real talk: I've had moments where I was too lazy to tell Claude which file to touch, hit enter, and then just watched it grep my entire repo for five minutes looking for the thing I couldn't be bothered to put in the prompt. On a big monorepo, finding where to make the change is the expensive part — not the change itself. The agent reads a dozen files, burns tokens, and eventually lands on the right one.

I wanted to kill both: the tokens and the time.

So I tried graphify — a CLI that builds a graph of your codebase (files, symbols, imports, calls, who-contains-what) and answers "where is X?" by walking that graph locally. No model call on the query. You build the graph once, and after that, asking it stuff is basically free.

Getting it running

Install is two commands (needs Python 3.10+):

pip install graphifyy && graphify install

That second one wires it into Claude. From there I just ran this inside Claude:

/graphify .

It asked whether to scan the full project or just the architecture. I started with architecture-only — faster and cheaper — but the test results weren't good enough; the queries kept landing in the wrong neighborhood. So I regenerated the graph over the whole project, ran the tasks again, and those are the numbers below. (That trade-off is real, and I come back to it at the end.)

Full install docs: graphify.net/#install.

Here's what I actually measured. No smoke.

What I tested

I gave it four real "where do I change this?" tasks on our React + TypeScript monorepo. Rule was simple: find the file, don't make the change. Same four prompts twice — once letting Claude search normally (the baseline), once through graphify after building the graph.

1. Change the color of the header cells of a data-matrix component
2. Add a new section to a side panel on a specific page
3. Add a new field to an entity-creation form
4. Add an item to the row action menu of a specific table

I phrased them the way I actually talk — vague, using product names that don't match any filename. On purpose. That's the realistic case, and it's where naive search struggles most.

The numbers

Baseline — Claude searching the repo:

Graphify — local graph query:

It found all four. Search time went from 4 minutes 14 seconds to under 2 seconds, and per-search tokens went from ~30k to basically nothing — because the query is just a graph walk, there's no LLM thinking about it.

That's the part that made me go "ok, this is real."

It's quick, not magic

Important: it found everything, but it wasn't always one perfect shot. And the key thing — the refining isn't your job. graphify is a tool the agent drives. When the first query misses, Claude fires the next one itself, reads the shortlist itself, drills down itself. You don't touch it. Here's how it actually went:

• Task 1 the first query was too generic and grabbed the wrong "header" node. Claude immediately ran a more specific query and nailed the right file. Two queries, still well under a second total.
• Task 2 it returned a shortlist of components with nearly identical names — the right one (the page's panel) was in there, sitting next to a similar one used for table rows. Claude picked the correct one from the list and moved on.
• Task 3 it landed on the form container and its data schema; the exact field component lives one level deeper, so Claude drilled in from there.

So the honest framing: graphify gets the agent to the right area in milliseconds, for free. Sometimes that's one query, sometimes it's a couple plus a pick from a shortlist — but those are the agent's steps, not yours, and each one is still sub-second and ~0 tokens. Compared to watching that same agent grind through the repo for a minute and a half, you've handed it the map instead of making it walk the whole thing — and you didn't have to do anything either way.

A harder one: trace the whole chain

The four tasks above were all "find the file." So I threw it something with more hops:

tell me where the data for this analytics dashboard page comes from — what API and what service.

That's not one lookup. It's a chain: find the page, follow it to the component that fetches, follow that to the API call, then back to the service actually serving the data. The kind of trace where a plain agent reads one file, learns the next name, reads that one, and so on — a slow chain of round-trips.

This one isn't ~0 tokens on either side, because even with the graph the agent still reads code to confirm each link. But the graph hands it the import and call edges up front, so instead of discovering the chain one file at a time it walks it:

Less than half the time — 52s vs 129s — on exactly the kind of multi-hop question where a naive agent usually bleeds the most, because every hop is another read-and-wait. The graph already knows what connects to what.

Is building the graph worth it?

It's not free to build. The graph that gave me these results cost around 116k tokens, one time. One baseline session of four searches was ~119k.

So the math is dumb-simple: you break even after about one session. Everything after that is free and instant, and the graph sticks around between sessions (you just re-index as the code changes). If you search your codebase with an agent more than a couple times — and if you use one at all, you do — it pays for itself almost right away.

And if you only care about finding files, you can build a structure-only graph (no LLM pass) for zero tokens. The catch is plain-English questions match a bit worse without the richer layer.

Verdict

Did it do what I wanted? Yeah, on both counts: it found all four files, time dropped ~150x, and tokens per search went to almost nothing. It's not always a one-shot — sometimes the agent runs a follow-up query or picks from a shortlist — but that's the agent's work, not yours, and it lands in seconds instead of minutes.

As a fix for the "sit there watching the agent grep for five minutes" problem, it's the best few minutes of setup I've spent in a while. Next time I'm too lazy to tag the file, at least the laziness is cheap now.

UPDATE — a friend asked me about LSPs

A friend read this and hit me with one question that got me thinking:

did you have ts lsp enabled?

My first reaction was, honestly, wtf is ts lsp.

Quick google later, turns out I was already using one — just for Swift. An LSP (Language Server Protocol) is the thing behind your editor's "go to definition," "find all references," and the red squiggle under a type error: a little server that actually understands your code as types and symbols instead of treating it like text. The TypeScript LSP is that, for TS. In Claude Code it means the agent can jump straight to a definition or ask "who references this?" instead of grepping around and reading files hoping to land on the right one. I had the Swift one installed and never once thought about the TS equivalent.

So: hey, let's try it.

Turning it on was quick:

# 1. the language server itself (needs Node 20+)
npm install -g typescript-language-server typescript

# 2. the plugin, from inside Claude
/plugin install typescript-lsp@claude-plugins-official

Reload and that's it — it's on for every project, you don't set it up again.

Then I re-ran the exact same test. No graphify this time. Same original prompts, word for word, in a fresh session with no context — just Claude searching the repo like the baseline, but now with the TS LSP plugin on.

The results were pretty shocking lol.

Baseline + TS LSP (no graphify):

Same four files, all found. Search time went from 4m 14s down to ~2m 34s — roughly 40% off, call it almost half, just from flipping on a plugin I didn't know I was missing. Tokens looked way down too (the original baseline was ~119k, this run I ballparked ~16–18k) — but big grain of salt there: I couldn't read the token meter cleanly this time, so I trust the time delta a lot more than the token one.

Now — it's not close to graphify. Graphify was ~1.7s and basically zero tokens; this is still minutes and thousands of tokens. Those graphify numbers are stupid low and this doesn't touch them. But that's kind of the point: this was a ~40% cut for free, with no graph to build.

I haven't tried the obvious next thing yet — graphify and the TS LSP together. I will, and I'll update this again when I do.

Two things I'm walking away with:

• There's a way to shave tokens without building a graph. Building the graph isn't free, and what it costs scales with your project — mine came out around ~116k because the repo is big, a smaller codebase would be way cheaper (and the structure-only graph is free). But the LSP plugin is free and universal no matter the size, so it's kind of a no-brainer floor to have on either way.
• There's a whole pile of "basic" stuff like LSPs I clearly don't know much about. A friend's one-line question taught me more than I expected. New topic to go check out.