We’ve been using Claude Code on our codebase for a while now, and it works well, but we noticed something that quietly costs us time and money. Every time we open a fresh session, Claude has to read through our source files just to understand how everything fits together before it can help with anything real. It does this again and again, because it starts each session with no memory of the last one. On a project of any real size, that adds up fast.

Graphify is a small tool that fixes this. It builds a structured map of our codebase one time, saves it, and lets Claude read that map instead of re-reading all our files on every session. The short version for leadership is simple. It means lower token usage per session, so more of each session goes toward solving actual problems instead of orientation. It means Claude keeps architectural context across sessions rather than relearning it every morning. And it means faster, cheaper, more consistent assistance on our code, with noticeably better answers when we ask how a system fits together and why it was built that way. It sits on top of the Claude Code setup we already have, so there’s no new platform to buy and no new vendor to commit to.

Getting it set up

The whole thing takes a few minutes. You’ll need Python 3.10 or newer and Claude Code already installed.

First, install the package. The cleanest way is pipx install graphifyy or uv tool install graphifyy, because those keep it isolated in its own environment and avoid a common Python path error that trips people up with a plain pip install. If you prefer pip, run pip install graphifyy && graphify install. One thing to note so nobody gets confused: the package on PyPI is currently spelled with a double y as graphifyy, while the command you actually type stays graphify.

Next, build the graph. Open Claude Code inside your project folder and type /graphify . with the dot meaning the current directory. It reads your files and produces a folder called graphify-out. Inside you’ll find an interactive graph you can open in a browser, a saved graph file that persists so you can query it weeks later, a report highlighting the important and surprising parts of your codebase, and a cache so that future runs only reprocess the files that changed.

After that, keep it fresh automatically. Run graphify hook install to add a git hook that updates the graph every time you commit, so the map stays current instead of drifting out of date. If you ever upgrade graphify, run that command again, since it stores the interpreter path when you install it.

From then on you barely think about it. Later sessions query the saved graph rather than re-reading the whole codebase. The only habit worth keeping is making sure the graph is current before a big session on a fast-moving repo, which the git hook mostly handles for you.

The longer explanation of why this works

If you want to understand why this makes a real difference rather than just taking the summary on faith, it helps to look at what Claude is spending its effort on.

A language model has a fixed context window, which you can think of as the amount of information it can hold in mind at once. When Claude Code reads your files to understand your project, all of that reading consumes part of the window and part of your token budget. On a project with a few dozen files, orienting itself can burn through a large chunk of tokens before you’ve even asked your question. That’s expensive, and it’s slow, and worst of all it happens on every single session because the model has no memory of what it learned last time. If your team runs many sessions a day, you are paying that orientation cost over and over.

Graphify changes what Claude reads. Instead of raw files, it builds a knowledge graph, which is a compact representation of the pieces of your codebase and the relationships between them. It uses proper parsing of your source code across many programming languages to extract the real structure, so it understands functions, modules, and how they connect, not just blocks of text. It can also pull in things beyond code, like design documents, diagrams, and notes, and fold them into the same map. The result is that Claude can understand the shape of your project by reading something small and structured rather than something large and unstructured. The project’s own figures put this at roughly seventy times fewer tokens per query compared to reading the raw files. Even if the real number for your codebase is smaller, the direction is clearly in your favor.

There are two further benefits that matter in daily use. The first is persistence. The graph is written to disk, so the understanding survives between sessions. Claude can pick up context from weeks ago without rebuilding anything, and a cache based on file fingerprints means that when you do rebuild, it only touches the files that actually changed. The second is that the graph captures relationships and reasoning, not just names. It groups related parts of your codebase together, points out the heavily connected pieces that quietly hold everything up, and surfaces connections you might not have known existed. This is the part that leads to better answers about how your system fits together and why decisions were made, which is exactly the kind of question that flat file reading struggles with.

There’s also a quality safeguard worth mentioning to anyone cautious about trusting an automated map. Every relationship in the graph is labeled by how it was found. Some are extracted directly from your source and are reliable. Some are inferred, meaning the tool made a reasonable guess and attached a confidence level to it. And some are flagged as ambiguous and set aside for a human to review. So Claude is never quietly treating a guess as a fact, and you can always see the difference.

Two honest caveats

Two honest caveats to keep things grounded. Graphify is a community tool rather than an official Anthropic product, so the impressive numbers you’ll see quoted come from its author rather than from independent testing. And the graph is only as accurate as its last build, which is why the automatic git hook matters on an active codebase. The sensible move is to run a short pilot on one of our real repositories, measure our own token usage before and after, and let that number decide how widely we adopt it. A figure from our own codebase will be far more convincing than anyone else’s headline claim.

Thanks to Maicon for showing me the value of Graphify in the first place.