graphify: Turn Your Codebase into a Knowledge Graph for AI Coding Agents

graphify has been all over my timeline this week: it went past 126k GitHub stars, got into Y Combinator and showed up on the Vercel Marketplace. The pitch is simple. Type /graphify in Claude Code, Codex or Cursor, and your agent queries a graph of your code instead of reading files one by one.

"Saves tokens" is an easy claim to make and a hard one to check, so I installed it on a plain Linux box and pointed it at a real repo. No cloud trial, no API keys. Here's what happened.

What graphify actually is

graphify is an open-source (Apache-2.0) Python CLI plus an agent skill. It parses your project with tree-sitter and writes three files to graphify-out/:

• graph.html, an interactive force-directed graph you open in a browser
• GRAPH_REPORT.md, a summary with "god nodes", communities and surprising connections
• graph.json, the full graph your agent queries through explain, path and query

Code extraction is deterministic and local. An LLM only gets involved for docs, PDFs, images and video, or for naming communities, and only if you configure a backend.

Setup

My test box runs Debian 13 with Python 3. The PyPI package name has a double y:

python3 -m venv venv
venv/bin/pip install graphifyy      # installed 0.9.92
git clone --depth 1 https://github.com/encode/httpx testbed/httpx

For the testbed I picked httpx: a real, well-known Python HTTP client with about 17,750 lines of Python plus docs and a changelog. It's big enough to be interesting and small enough that I know roughly what the answers should be.

Building the graph: 2 seconds, 0 tokens

You don't need an assistant for the code-only build. The update command does it straight from the CLI:

cd testbed/httpx
graphify update .

Re-extracting code files in . (no LLM needed)...
  AST extraction: 101/101 uncached files (100%) [8 workers]
[graphify watch] Rebuilt: 2233 nodes, 4453 edges, 166 communities

A fresh build took 2.1 seconds. After I edited one file, an incremental rebuild re-parsed only that file and took 1.6 seconds. The report's own footer says Token cost: 0 input · 0 output.

The output is not small: graph.json is 1.7 MB, graph.html is 1.9 MB and GRAPH_REPORT.md is 24 KB. Markdown docs got pulled in as structure too, so CHANGELOG.md and docs/api.md show up as nodes.

What the report got right

The "god nodes" list is honestly a good first page for a new contributor:

1. Response - 170 edges
2. Request - 111 edges
3. Changelog - 79 edges
4. Client - 69 edges
5. AsyncClient - 51 edges
6. BaseClient - 45 edges

That's httpx's real core. 88% of edges were EXTRACTED (read directly from the source) and 12% were INFERRED, with an average confidence of 0.91. I like that every edge carries this tag, because it tells you what to trust.

"Surprising connections" was less useful. Every entry was a changelog or doc heading linked to Client, which is true but not surprising.

Querying: where the token savings come from

This is what your agent actually runs. I counted every output with tiktoken's cl100k encoding:

graphify explain "httpx/_client.py::Client"
graphify path "httpx/_client.py::Client" "DigestAuth"
graphify query "how does a request get sent through the transport"

• explain on Client came to 628 tokens. It listed 69 connections with file and line numbers, like --> HTTPTransport [uses] [INFERRED] httpx/_client.py:L731. Reading _client.py itself costs 13,659 tokens.
• path returned a 3-hop chain in a single line: Client <-contains- _client.py -imports_from-> _auth.py -contains-> DigestAuth.
• query came to 1,728 tokens. It ran a BFS that found 536 nodes but showed only 82, and printed a clear TRUNCATED warning telling me to raise --budget to 14720 to see everything.

So yes, for "where is X and what touches it" questions, a graph lookup is roughly 20x cheaper than dumping the file. What it doesn't do is replace reading the code once the agent has to change a function. The graph points you to the right lines; it doesn't contain them.

Two rough edges

Ambiguous names. graphify explain "Client" refused to answer, because Client matched both the class in httpx/_client.py and a heading in docs/api.md. The error tells you to use the path::symbol form, which works, but docs being indexed alongside code means common names collide a lot.

Community labels with a small local model. Without an API key, the 166 communities are named after a representative file or symbol (test_content.py, AsyncByteStream). graphify can rename them with an LLM, Ollama included:

pip install openai     # the Ollama backend needs it; the first run told me so
graphify label . --backend=ollama --model=qwen3:1.7b

On my box, with a 1.7B model on CPU, this ran for more than 11 minutes without finishing, and I killed it. The code graph doesn't need this step at all, but if you want nice labels, give it a real model or an API key. I saw the same kind of small-model limit when I ran Anatomy's skill on a 1.7B local model.

Is it worth installing?

For code, yes. It's free, local and fast, and explain/path give an agent a cheap map before it starts opening files. I'd add graphify update . to a git hook and let the agent use the graph first.

What I didn't test: the /graphify skill inside a paid assistant, the semantic pass over PDFs and images, and the hosted Graphify Cloud product with its "80% token savings" claim. My 628-vs-13,659 number is one lookup on one repo, not a benchmark of a whole agent session.

Repo: github.com/Graphify-Labs/graphify