Graphify turns your codebase into a knowledge graph, not a vector index
Graphify parses a codebase locally with tree-sitter into a traversable knowledge graph, tagging every edge extracted or inferred instead of asking you to trust a ranking. I look at how it's built, what its own benchmarks show, and where a confidence-tagged graph beats embeddings for production agent workloads.
I spend most of my week moving between two failure modes in agentic systems: agents that hallucinate structure they never actually read, and agents that burn a context window grepping the same three files four different ways. Graphify is aimed squarely at the second problem, and its design choices are worth a close look because they say something about where code-intelligence tooling is heading now that "embed everything" has run its course.
The pitch: type /graphify in your coding assistant, and it parses your project — code, docs, PDFs, images, video — into a knowledge graph you query instead of grepping. The interesting part isn't the pitch, it's the build.
Parsing without a model in the loop
Code is parsed with tree-sitter's AST, deterministically, with no LLM in the loop and nothing leaving the machine. That's a real architectural commitment, not a footnote: cross-file calls / imports / inherits / mixes_in edges get resolved across roughly 40 languages purely from syntax trees. Only the semantic pass over non-code material — docs, PDFs, images, video — calls out to a model, and only if you configure one. For a tool meant to sit in your dev loop via a git post-commit hook, that's the right default: your source doesn't round-trip through a third-party API just to get indexed.
The parser also promotes things most tools throw away. NOTE: and WHY: comments, ADR and RFC citations — these become first-class nodes linked to the code they annotate, rather than dead text a grep might surface by luck.
How graphify builds the graph: deterministic parsing for code, model-assisted parsing for everything else, unified into one traversable graph with every edge tagged by provenance.
A graph, not a vector index
Graphify's second bet is structural: no embeddings, no vector store, just edges you traverse. Every edge carries a provenance tag — EXTRACTED if it's explicit in the source, INFERRED if graphify resolved it — so a query result tells you not just what's connected, but how confident you should be that the connection is real. graphify explain "APIRouter" returns a node's degree, its community, and every incoming and outgoing edge with that tag attached. graphify path "FastAPI" "ModelField" walks the shortest route between two concepts, hop by hop. That's a genuinely different interaction model from asking a vector index for the top-k nearest chunks and hoping the ranking holds together.
Community detection (Leiden, no LLM) buckets the graph into subsystems automatically, and graphify query "<question>" returns a scoped subgraph instead of a wall of text. A run leaves you three artifacts: graph.html for interactive browsing, GRAPH_REPORT.md with the highlights, and graph.json you can query repeatedly without re-reading the project.
What the benchmarks actually say
The project's own numbers, in BENCHMARKS.md, are worth reading closely rather than taking at face value. On LOCOMO (n=300), graphify's recall@10 is 0.497 against mem0's 0.048 and supermemory's 0.149 — a large gap. But on LOCOMO QA accuracy, graphify lands at 45.3%, behind supermemory's 49.7% (mem0 trails at 27.3%). That's a real result worth stating plainly: strong recall didn't fully convert into answer quality on that benchmark. On LongMemEval-S (n=50), graphify ties dense RAG at 76% QA accuracy. The graph build itself costs zero LLM tokens, versus per-token costs for most comparison systems — a meaningful operating-cost difference if you rebuild the index often. The harness held the model and budget constant across systems and used a judge cross-checked against a second judge (90.6% agreement, Cohen's kappa 0.81), which is more rigor than most tool READMEs bother with. I'd still want to see this replicated outside the project's own harness before treating the QA numbers as settled.
Where this fits in a production agent stack
I care about this less as a novelty and more as an infrastructure decision. When you're running agents against a large repo in production — which is most of what I do day to day — the cost that actually matters isn't token price, it's the number of tool calls an agent burns re-deriving structure it already derived last session. A cached, traversable graph with confidence-tagged edges is a cheaper and more auditable substrate for that than a vector index, precisely because EXTRACTED vs INFERRED gives you a way to catch an agent's own confabulations before they compound into a bad plan. The local-first, no-LLM code parse also means the graph stays correct even when the model backing your assistant changes — the structure isn't contingent on any one vendor's embeddings.
The rough edges are the ones you'd expect from a young project with this much surface area: 20+ platform integrations to maintain, a semantic pass that still depends on model quality for anything that isn't code, and benchmark numbers that cut both ways depending on which metric you weight. None of that undercuts the core bet — that codebases are graphs, not bags of chunks, and that admitting when a claimed edge is deterministic versus inferred is a feature, not a compliance checkbox.
Trying it
Install is uv tool install graphifyy (the package is double-y; the CLI command is just graphify), then graphify install to register the skill with your assistant of choice — Claude Code, Cursor, Codex, Gemini CLI, Copilot, and 15+ others are supported. Run /graphify in a repo and you get graph.html, GRAPH_REPORT.md, and graph.json back in about the time it takes to read this sentence. It's MIT-licensed, and at 82.6k stars it's already past the point where "worth a look" undersells it — it's worth building a habit around.