Straight answers.

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, two ways. The hosted product at app.graphify.com has a Free plan with no card, and Pro and Teams above it when you outgrow the caps. The open-source engine is free under the Apache 2.0 license, runs on your machine, and needs no account or API keys. There is also 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.

With the open-source engine, no: code is parsed locally with tree-sitter, with no telemetry and nothing uploaded (non-code files use the model backend you configure, which can be local like Ollama). The hosted product builds and keeps the same graph for you in the cloud.

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).

You can skip installing entirely: start on the hosted product at app.graphify.com and connect a repository. To run the open-source engine yourself, 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. That 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.