Graphify: turn a codebase into a knowledge graph so Claude stops re-reading files
TL;DR
Graphify builds a knowledge graph from a folder of code, docs, papers and images. Instead of re-reading raw files for every question, Claude Code queries the saved graph. Savings grow with project size — on small repos the main benefit is seeing the structure.
Whenever you ask "where is this function called?" or "what does the payment module depend on?", Claude Code usually has to open many files to find the answer, costing time and tokens, and repeating it every new session. Graphify takes a different approach: build a knowledge graph from your code folder, documents, papers and images, then let Claude query the stored graph instead of re-reading raw files.
The core idea
The relationships between parts of a codebase (who calls whom, who imports whom, which concept connects to which) are structured data. Storing them as a graph once and querying many times is far cheaper than re-reading dozens of files for every question. The benefit grows with project size; for a repo of just a few files, the main value is seeing the structure.
How it works
| Step | Detail |
|---|---|
| Code analysis | tree-sitter (AST) + call graph, runs locally, no LLM needed |
| Document analysis | Docs, PDFs and diagram images are sent through Claude to extract concepts |
| Relationship labels | EXTRACTED / INFERRED / AMBIGUOUS, so you know what's certain and what's inferred |
| Output | A graphify-out/ folder: graph.html, graph.json, GRAPH_REPORT.md, an Obsidian vault |
The certainty labels are very valuable: they tell you when you can trust a result and when you should check by reading the code yourself.
Install and use
pip install graphifyy && graphify install
# inside Claude Code:
/graphify .When is it worth it?
- Onboarding to an unfamiliar codebase: open
graph.htmlto see central modules and related clusters before reading code. - Large repos, many questions: this is where the token savings are clearest.
- Lots of accompanying documentation: designs, papers and diagrams are linked into the same graph as the code.
Caveats and risks
- The savings figure (about 70×) comes from the project's own benchmark; measure on your own repo.
- Where data goes: code analysis runs locally, but documents and images are sent through Claude when building the graph. For sensitive documents, check your company's policy.
- Stale graphs: after many commits, an outdated graph gives wrong answers. Use a post-commit hook to rebuild.
- INFERRED edges: treat them as hints, not facts.
Suggested trial process
- Pick a medium-to-large repo you're working on.
- Build the graph and read GRAPH_REPORT.md to check it matches your understanding.
- Ask 5 real structural questions; compare tokens and accuracy with your usual approach.
- If it works, add a graph-update hook to your workflow.
How to apply it
- Dev: use graph.html to map things out before editing an unfamiliar module.
- Tech Lead: add GRAPH_REPORT.md to onboarding docs; it gives newcomers the big picture in minutes.
- PM: the graph helps answer impact questions quickly ("what does changing this affect?") when planning.