Frequently asked questions

Graphify is an open-source (Apache 2.0) skill that turns your codebase into an on-device knowledge graph your AI coding assistant queries instead of grepping through files. It's a Python package (graphifyy on PyPI) plus a /graphify skill and an MCP server; the code repository is github.com/Graphify-Labs/graphify. It is not affiliated with other projects named Graphify.

RAG retrieves fuzzy top-k chunks by embedding similarity and hopes the model reconnects them. Graphify builds a real graph and traverses it, so every answer is an explicit path with file:line citations: no embeddings and no vector store. It's the difference between guessing which chunks are relevant and following the actual call and import edges.

Yes. The core tool is open source under the Apache 2.0 license: no account, no API keys, free to use. There is a separate early-access enterprise layer (verification at the merge gate, graph-aware review, and an engineering digest) for teams, self-hosted in your own infrastructure.

17, including Claude Code, Cursor, GitHub Copilot, Codex, Gemini CLI, and Aider. Running graphify install registers the /graphify skill with the assistants it detects, and the graph is also served over an MCP server that any MCP client can query.

No. Graphify parses code locally with tree-sitter: deterministic AST extraction, no model call, no telemetry, nothing uploaded. Non-code files (docs, PDFs, SQL schemas, Terraform) are optionally read by the model backend you configure, which can be a local model like Ollama to keep everything on-device.

36, parsed on-device with bundled tree-sitter grammars: Python, TypeScript, JavaScript, Go, Rust, Java, C, C++, C#, Ruby, Kotlin, Swift, PHP, and many more, including variants like JSX and TSX and infrastructure languages like Terraform (HCL).

Install the Python package with `uv tool install graphifyy`, run `graphify install` to register the skill with your assistant, then type `/graphify .` inside the assistant to build the graph. It takes about five minutes and runs entirely on your machine.

The PyPI package is graphifyy, spelled with a double y: `uv tool install graphifyy`. Other graphify* packages on PyPI are unrelated to this project. The GitHub repository is github.com/Graphify-Labs/graphify and the website is graphify.com.

Two ways, same graph: the CLI (graphify query, graphify path, graphify explain, graphify prs) or the MCP server, which exposes 10 tools including query_graph, get_node, get_neighbors, and shortest_path.

Every edge in the graph carries a provenance tag. EXTRACTED means it came straight from the tree-sitter AST (a real call, import, or definition). INFERRED means a model connected it, for example a doc page to the code it describes. AMBIGUOUS means the evidence couldn't be fully resolved, like dynamic dispatch: Graphify keeps the edge but flags it as uncertain.

There's no hard size limit: parsing is on-device with tree-sitter, so it scales with how much code you have. A small project indexes in minutes; a large monorepo takes longer and is bounded mainly by disk read and CPU on your machine, not a network round-trip. It's a local batch job, so run it once and keep it fresh incrementally rather than rebuilding from scratch.

The graph reflects the code as of the last index, so it goes stale as you commit. You don't rebuild the whole thing: `/graphify . --update` re-scans only what changed and patches those nodes and edges, which is far cheaper than a full pass. Run it after meaningful changes, or wire it into a hook or CI step so the graph tracks your working tree.

EXTRACTED edges are deterministic: they come straight from the AST, so a call or import edge is as reliable as your parser. INFERRED edges are where a model links non-code, like a doc or schema to the code it describes, and those can be wrong. The failure mode is a plausible-but-incorrect link; when the evidence can't be resolved, Graphify marks the edge AMBIGUOUS rather than asserting it.

LSP answers one hop: where is this symbol defined, where is it referenced. A graph answers the questions that span the codebase: what breaks if I change this, every path between two functions, how a config or doc connects to the code. It's persistent, queryable by your AI assistant, and every edge carries a provenance tag, so you get multi-hop blast-radius reasoning rather than a jump-to-def.

ctags builds a flat symbol index for jump-to-definition; Sourcegraph is hosted code search you send your code to. Graphify parses on-device and produces an actual graph (typed nodes and provenance-tagged edges) that your AI assistant traverses over CLI or MCP. It's not search-a-box or a symbol table; it's a local, agent-queryable model of how your code connects, that stays on your machine.

No. That's the point. Instead of stuffing files into the model's context and hoping the answer is in there, the assistant queries the graph and pulls back only the relevant nodes and edges for the question. It reads the map, not the whole territory. One community user reported roughly 71.5× fewer tokens versus letting the assistant grep and read files directly.

It's a Python package with bundled tree-sitter grammars, so it runs anywhere Python does, including Windows. The graph is written to graphify-out/graph.json. It's derived from your code and contains structural facts like symbol names and file paths, so treat it with the same sensitivity as the repo itself: committing it to a private repo is fine, but don't publish it anywhere you wouldn't publish the source.