How to give Cursor codebase memory with an on-device graph

Cursor's agent is a strong codebase explorer, but its understanding is session-shaped: it searches, reads, builds a picture of your architecture, and then the session ends and the picture goes with it. Ask the same structural question tomorrow and it runs the same exploration — same searches, same file reads, same tokens.

You can give Cursor a persistent memory of your codebase's structure with an on-device knowledge graph. Graphify builds the graph locally — your code never leaves your machine — and exposes it to Cursor through MCP, the open protocol Cursor already speaks. Setup takes about two minutes; here's each step.

Install the CLI

Graphify is an open-source (MIT) Python package: uv tool install graphifyy. Everything it builds stays on your machine, and there's no telemetry. Code parsing is fully local; the only optional network dependency is the model used to read non-code sources into the graph, and you choose that — Claude, OpenAI, Gemini, DeepSeek, Kimi, Bedrock, Azure, or Ollama for a fully local pipeline.

Connect it to Cursor

Run graphify install. It detects Cursor and registers Graphify's MCP server — eight tools for querying the graph, tracing paths, and explaining nodes — so Cursor's agent can call the graph natively during a conversation, the same way it calls its other tools. Graphify supports 17 assistants through the same mechanism; the full list is on the integrations page, so a graph you build once also works in any other assistant you use.

Build the graph

From your repo, run /graphify . (as a skill inside an assistant session) or the equivalent CLI mapping command. Tree-sitter parses your code locally across 36 languages — the call and import edges come from real AST extraction, tagged EXTRACTED, with no model involved in reading your source. Docs, SQL, schemas, and Terraform are folded in by your model and tagged INFERRED; connections that couldn't be fully resolved are kept and tagged AMBIGUOUS. That provenance model — knowing what was found versus what was guessed — is the graph's honesty guarantee, and it's covered in depth in concepts.

The output is three files sitting in your repo: an interactive graph.html map, a written GRAPH_REPORT.md brief covering god nodes and subsystem communities, and the raw graph.json.

Use it

Now ask Cursor a structural question — what calls this function, what's the blast radius of changing this table, how do these two services connect. Instead of a search-and-read loop, the agent queries the graph: a traversal over typed edges, returning just the relevant nodes rather than whole files. You can run the same queries yourself with graphify query, graphify path, and graphify explain — the docs have the full reference.

Because graph answers are small and the graph persists between sessions, context stops being spent on re-discovery. How much you save depends entirely on your repo and your questions; one community user reported 71.5× fewer tokens on their workload, which we cite as exactly that — a community-reported number, not a benchmark. The structural claim is the durable one: traversing edges sends less text to the model than pasting files, and the understanding doesn't reset when the session does.

One habit to build: re-run the mapping after major changes so the graph tracks reality. And if you're weighing this against embedding your codebase into a vector store, the trade-offs are laid out honestly in Graphify vs RAG.