Graphify: A Local AST-Based Knowledge Graph for AI Coding Assistants

What Graphify Solves and Who It Is For

Graphify addresses the problem of navigating a large codebase where grep and file-by-file reading are slow and lose the connections between symbols. It builds a knowledge graph from your code, docs, SQL schemas, configs, and PDFs, and lets you query it with plain-language questions or path queries. The target user is a developer working inside an AI coding assistant like Claude Code, Cursor, Codex, or Gemini CLI, who wants to ask 'what does this function depend on?' or 'how do these two modules connect?' without manually tracing references. The README positions it as an alternative to 'grepping through files', and the examples show commands like `graphify explain "APIRouter"` returning node details and connections. This is for teams that value deterministic, local analysis over embedding-based retrieval, and who are comfortable with a CLI-driven workflow rather than a background service.

The Mechanism: Tree-Sitter AST, Not Embeddings

The core mechanism is deterministic parsing with tree-sitter AST. The README states that code is parsed locally, with no LLM involved and nothing leaving your machine. This is a fundamental difference from vector-based tools: there are no embeddings and no vector store. Instead, the graph is built from explicit syntactic relationships: calls, imports, inherits, and mixes_in, resolved across approximately 40 languages. Each edge in the graph carries a confidence tag: EXTRACTED means the relationship is explicit in the source, while INFERRED means it was derived through graphify's resolution logic. This distinction is important because it tells you whether a connection was directly read from code or guessed by the tool. The graph is stored in graph.json, which you can query without re-reading your files. This design means the graph is reproducible and auditable, but it also means that semantic understanding of prose, like the intent behind a comment or the meaning of a PDF, is out of scope unless you configure a separate semantic pass that calls a model.

Getting Started: Install, Register, and Query

The README gives a 30-second setup. You install the CLI with `uv tool install graphifyy` or `pipx install graphifyy`. Then you run `graphify install` to register the skill with your AI assistant. After that, in the assistant you type `/graphify .` to map the current directory. The output is three files in a `graphify-out/` directory: `graph.html` for interactive browsing, `GRAPH_REPORT.md` which summarizes key concepts, surprising connections, and suggested questions, and `graph.json` which holds the full graph. You can then run commands like `graphify explain "APIRouter"` to see a node's source location, community, degree, and its connections with edge tags. There is also `graphify path "FastAPI" "ModelField"` which returns the shortest path between two nodes, and `graphify query "<question>"` which returns a scoped subgraph. The CLI is the primary interface, and the skill registration is what ties it into your assistant. The commands are concrete and the output format is plain text, which fits a terminal workflow.

Edge Confidence and the Limits of Inference

The edge confidence tags are a genuine strength but also a limitation. EXTRACTED edges are reliable because they come directly from the source code, such as an import statement or a method call that is syntactically present. INFERRED edges are derived by graphify's resolution, which means they can be wrong or miss context that a human would catch. The README does not explain the inference algorithm in detail, only that it is 'resolved by graphify'. This is a potential failure mode: if you rely on an INFERRED edge to understand a dependency, you might be misled. The example output shows `--> RequestValidationError [uses] [INFERRED]`, which suggests that the tool can detect usage even when it is not a direct call, but the confidence tag is your only clue. For a codebase with heavy metaprogramming, dynamic dispatch, or reflection, the AST-based approach will miss relationships that only exist at runtime. The README does not claim to handle such cases, so you should treat INFERRED edges as hypotheses to verify, not facts.

Beyond Code: Docs, PDFs, and the Semantic Pass

Graphify is not limited to code. The README states that docs, PDFs, images, and video/audio can map into the same graph, but with a key caveat: these require a semantic pass that uses your assistant's model or a configured API key. This means the local-first guarantee only applies to code parsing. If you include PDFs or images, data leaves your machine and you incur API costs. The README says this pass is 'only if you configure one', so it is optional. This split is a trade-off: you get a unified graph, but the trust model changes depending on the file type. For a code-only project, nothing leaves your machine. For a project with documentation, you must decide whether the benefit of having PDFs in the graph is worth sending them to an external model. The README does not detail how the semantic pass integrates with the AST graph, so the quality of the merged graph is unclear. If your codebase is heavily documented with architectural decision records (ADRs) or RFCs, the README claims that `# NOTE:` and `# WHY:` comments and ADR/RFC citations become first-class nodes linked to code, which could be useful, but the mechanism is not specified.

Performance Claims and What They Don't Tell You

The README includes a benchmarks table with results on LOCOMO and LongMemEval-S, but the table is truncated. It shows graphify achieving recall@10 of 0.497 on LOCOMO (n=300), compared to mem0 at 0.048 and supermemory at 0.149, and QA accuracy of 45.3% versus supermemory 49.7% and mem0 27.3%. These numbers are presented without methodology details, such as how the graph was queried or whether the same model was used. The QA accuracy is notably lower than supermemory, which suggests that for question-answering over long-term memory, graphify may not be the best choice. The benchmarks are also from the project itself, so they should be treated as self-reported. More importantly, the benchmarks do not measure the core use case of code navigation; they measure memory retrieval, which is a different task. If you are evaluating Graphify for code understanding, these numbers are not directly relevant. The README does not provide benchmarks for path tracing or explain accuracy, which would be more useful for the intended audience.

Alternatives and the Vector Store Divide

The main alternative to Graphify is a vector-based retrieval tool like mem0 or supermemory, which the README explicitly compares against. The difference in approach is fundamental: vector stores embed chunks of text into high-dimensional vectors and retrieve by similarity, which is good for fuzzy semantic search but bad for exact structural queries like 'what imports this module?'. Graphify builds an explicit graph with typed edges, which is better for tracing dependencies and understanding architecture, but it cannot handle natural language queries that require semantic inference. Another alternative is a traditional code search tool like ripgrep or ctags, which are faster and simpler but provide no graph structure. Graphify's value proposition is that it gives you the graph without the cost of a vector store, but you lose the ability to ask open-ended questions like 'what does this function do?' unless you use the semantic pass. If your primary need is semantic search over docs, a vector store is the right tool. If your primary need is structural understanding of code, Graphify is a fit. The README does not mention any other graph-based tools, so the comparison is limited to what it provides.

Maintenance, Licensing, and Upgrade Considerations

Graphify is released under the MIT license, which means you can use, modify, and distribute it freely, including in commercial products, as long as you preserve the copyright notice. The project is actively developed, with the last push on 2026-08-28 and releases v0.9.51, v0.9.50, and v0.9.49 within days of each other. This high release cadence suggests fast iteration, but it also means you should expect frequent changes and potential breaking changes between versions. The default branch is named 'v8', which is unusual and may indicate a versioning strategy tied to the CLI or skill format. The installation method via `uv tool install graphifyy` suggests the package is published on PyPI under the name 'graphifyy' (note the double 'y'), which is different from the repository name. This could be a source of confusion when searching for the package. The README does not document upgrade procedures, so you will need to check the changelog or release notes manually. Given the early-stage nature (the README mentions 'early access to the graphify platform' before public v1), the CLI may be less stable than a mature tool. Budget time for testing new versions before adopting them in a production workflow.

Editorial conclusion

Adopt Graphify if you work in a multi-file codebase inside an AI coding assistant and need deterministic, local answers about structure, imports, and calls without sending code to a model. Do not adopt it if you need semantic understanding of prose-heavy documentation or if your team cannot tolerate the overhead of a separate graph.json that must be regenerated on code changes. Before committing, verify that your primary languages are covered by the ~40 tree-sitter grammars, test the quality of INFERRED edges on your own code, and confirm that the CLI's output formats (graph.html, GRAPH_REPORT.md, graph.json) integrate with your existing review workflow. The project is under active development with frequent releases, so check the changelog between versions for breaking changes.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes