Graphify, in plain words: a map of your code that AI agents can read

When an AI coding assistant such as Claude Code works in a repository, it spends most of its budget reading files to find out how things connect. Graphify, an open-source project from Graphify-Labs, attacks that cost from the other side: it reads the repository once, builds a map of what calls, imports and contains what, and lets the assistant ask the map instead of re-reading the code.

What it builds

You run it on a folder. It parses the source with tree-sitter, a fast parser that understands the grammar of the language, so this step needs no AI model and costs nothing. Out come three files:

• graph.json, the map itself: every file, function, class and import as a node, every call or import as an edge.
• graph.html, an interactive picture of that map you can drag around.
• GRAPH_REPORT.md, a written summary: the most connected pieces (it calls them god nodes), clusters of code that belong together (communities), and connections you probably did not know were there.

Documents, PDFs and images can be added to the same map, but that step does need a model, so it costs tokens.

What it offers an AI assistant

Three commands. "Query" answers a question about how things connect. "Path" shows the route between two pieces of code. "Explain" describes one piece and its neighbours. Each answer is a small slice of the graph rather than a pile of files, which is where the saving comes from. It also ships as a slash command for Claude Code, as a server other tools can call, and as a git hook that rebuilds the map after every pull.

The numbers, and what they mean

Graphify's own benchmark reports 71.5 times fewer tokens per question than reading raw files on a mixed corpus of 52 files, papers and images. On a four-file corpus the saving was 5.4 times, and on one small library it was about 1 time, which is to say none. The authors say it themselves: the tool earns its keep on large corpora and adds little to a repository that already fits in a model's context.

What happened when we tried it

We ran it on this website's repository: 240 files, mostly TypeScript. It finished in about twenty seconds, at zero cost, and produced 1,897 nodes, 5,161 edges and 92 communities. The map was accurate. The community names were placeholders, because naming them needs a model, and the "surprising connections" were mostly small utility functions that every component uses. Nothing surprising, because a site this size is already easy to navigate by folder.

So we did not keep it. The map would have added 4.7 MB to the repository and a step to remember after every change, for a saving we could not measure. That is not a mark against the tool. It is the right answer to the question it asks: how big is your corpus?

When it is worth it

• A large codebase with several services, where a new engineer or an AI assistant spends its first hour finding out what talks to what.
• A mix of code and documents, such as a research repository with papers next to the code that implements them, where the cross-links are the point.
• A team that wants one shared map checked into the repository, kept fresh by the git hook.

If your repository is a few hundred files with clear folders, a good README does the same job for free.

The idea is bigger than the tool

Turning a body of knowledge into nodes and relations, then answering questions from the graph, is the same idea behind our own knowledge topography of the How AI works hub, and behind graph-based retrieval in general. When the material is large and interlinked, a map beats a search box. When it is small, the search box wins.