Graphify Turns a Folder Into a Knowledge Graph. The 71x Claim Needs Context.

Graphify picked up roughly 7,300 stars this week, which puts it near the top of GitHub's weekly trending board and takes its total past 137,000. The pitch is one line long: point your coding agent at a folder, type /graphify ., and get back a knowledge graph of everything in it.

What makes that interesting isn't the graph. It's the number attached to it: 71.5 times fewer tokens per query, measured against reading the raw files. If that holds in general, it's not a convenience tool, it's a change to how much context an agent needs to hold.

Where it came from

The author, safishamsi, frames the project as an answer to a specific habit of Andrej Karpathy's: keeping a /raw folder where papers, tweets, screenshots, and notes get dumped, and never being able to find anything in it later. That's a relatable problem, and a more honest origin story than most, because it describes a failure mode rather than a market.

The stated goal is narrower than "search your documents." It's to produce something persistent that survives between sessions, and to be explicit about what it inferred versus what it extracted. Every edge in the graph is tagged EXTRACTED, INFERRED, or AMBIGUOUS. That's an unusual design choice and, in my view, the most valuable part of the whole thing.

What it actually does

Install is two commands, and yes, the PyPI package name is temporarily wrong:

pip install graphifyy && graphify install

The doubled Y is a naming dispute, not a typo. The CLI and the skill command are both still graphify. On Windows, if the command isn't recognized after install, the Python Scripts folder has to go on PATH, or you use pipx install graphifyy and skip the problem.

Then, inside Claude Code, in any directory:

/graphify .
/graphify ./raw --mode deep
/graphify query "what connects attention to the optimizer?"
/graphify path "DigestAuth" "Response"
/graphify explain "SwinTransformer"

The output lands in graphify-out/. There's an interactive graph.html you can click through, an obsidian/ folder that opens as a vault, a graph.json that persists so you can query weeks later without re-reading anything, a cache/ keyed on SHA256 so re-runs only process changed files, and a GRAPH_REPORT.md that lists what it calls god nodes — the highest-degree concepts — plus "surprising connections" ranked by a composite score where code-to-paper edges count for more than code-to-code.

The multimodal part is not marketing. Code files go through tree-sitter for AST parsing plus a call-graph pass. Markdown, PDFs, and images go through Claude: concepts and relationships from prose, citation mining from papers, and vision for screenshots, diagrams, whiteboard photos, and images in other languages.

There are also exports that matter for anyone who doesn't want to live inside this tool: --svg, --graphml for Gephi or yEd, and --neo4j, which generates a cypher.txt rather than requiring a running database. The stack is NetworkX, Leiden clustering via graspologic, tree-sitter, and vis.js. No server. Nothing leaves the machine except the Claude calls.

The 71.5x number, examined

The benchmark corpus is 52 files: Karpathy's repositories, five papers, four images. Result, 71.5 times fewer tokens per query compared with reading the raw files.

The repository is unusually honest about how this scales, which is rare enough to be worth quoting in substance: token reduction grows with corpus size, and at six files the graph's value is structural clarity rather than compression, because six files fit in a context window anyway. Their own worked example on the graphify source plus the Transformer paper is 5.4x. On six synthetic library files, roughly 1x.

That's the correct shape. If your corpus is already under a context window, you're not saving tokens, you're buying a map. If it's fifty files of mixed types, the savings are real and large, because the alternative isn't reading the files once — it's reading them repeatedly, across multiple turns, each time an agent loses its place.

The comparison also flatters graphify slightly in one direction and undersells it in another. Reading raw files is the worst-case baseline; a well-tuned retrieval index would look better by comparison than raw files do. But a retrieval index returns passages, and the thing graphify returns is relationships — the answer to "what connects attention to the optimizer" is not a passage, it's a path. Those are different queries, and only one of them is served by a vector store.

The "no vector store" claim is a real architectural position

Most retrieval systems chunk text, embed it, and do nearest-neighbor search. Graphify skips all of that: local deterministic AST parsing for code, LLM extraction for prose and images, then a graph. There's no embedding step and no similarity search.

What you get instead is explainability. Ask why two things are connected and you get the edges, each labeled with whether it was extracted from the source or inferred by the model. A vector index cannot tell you that. It can only tell you the cosine distance was small.

The cost is coverage. A graph only knows what the extractor found. If the extraction pass missed a relationship, no query will surface it, and there's no fuzzy fallback. The AMBIGUOUS tag is the honest acknowledgment of this, and the --mode deep flag exists because the default pass is conservative about inferring edges.

Where it earns its place

Two workflows, in my experience of tools like this.

The first is onboarding to an unfamiliar codebase. Not "where is function X" — grep is fine for that — but "what are the load-bearing concepts here, and which of them touch the billing code." That's a graph question, and the god-nodes report answers it in a form you can read in two minutes.

The second is the multi-agent case. When several agents are writing code in parallel, each one's model of the repository goes stale within minutes. A graph rebuilt on every commit (graphify hook install sets up a post-commit hook) or on file save (--watch) gives every agent the same current map instead of five divergent guesses.

The obvious limit: this is built as a Claude Code skill first. The manual install path drops a SKILL.md into ~/.claude/skills/graphify/ and adds a line to CLAUDE.md. There's an MCP server mode (--mcp) that other clients can use, but the ergonomics are clearly optimized for one ecosystem, and the Claude dependency means the extraction pass costs real money on a large corpus.

The honest verdict

Graphify is not a search engine and shouldn't be evaluated as one. It's a persistent, inspectable model of what's in a folder, with the unusual property that it tells you which parts it guessed. For a 137,000-star project that's been trending for a week, the interesting question isn't whether the graph is impressive — it's whether the habit of tagging inference survives contact with users who just want answers.

My guess is that most people will use query, ignore the edge labels, and never look at graph.json. The ones who keep it will be the ones who needed the map, not the answer key.