# How Graphify Stopped My Team from Burning Thousands of Tokens Per Query > Source: > Published: 2026-06-21 11:26:47+00:00 Every time I asked Cursor about our auth flow, it would open 8-12 files, read through each one, and burn through tokens before even starting to answer. For a React Native codebase maintained by 6 developers, this adds up fast. I lead a front-end team building React Native apps. Cursor is our primary IDE. And while Cursor is great at understanding code, the way it retrieves context — by grepping and reading raw files sequentially — doesn't scale well on larger projects. Then I found [Graphify](https://github.com/safishamsi/graphify), and it fundamentally changed how our AI assistant interacts with our codebase. Before I get to the setup, it's worth understanding the mechanism — because it's not just another Cursor plugin. Graphify pre-processes your entire project into a **knowledge graph**. Think of it as a map of your codebase where every function, class, module, and concept becomes a node, and every relationship between them becomes an edge. When Cursor needs to answer a question, instead of reading 47 files to understand a flow, it runs `graphify query "auth flow"` — a scoped subgraph lookup that returns only the relevant nodes and connections. The important part: **code extraction happens entirely locally** via tree-sitter AST parsing. No API calls, no code leaving your machine. You only hit an LLM when processing docs, PDFs, or images. For a pure code project (which most React Native apps are), the extraction cost is basically zero. The output is three files: `graph.json` — the full graph (the core artifact your assistant queries)`graph.html` — an interactive visualization you can explore in a browser`GRAPH_REPORT.md` — an architecture summary with god nodes, surprising connections, and suggested questionsThat report alone is worth the setup. It finds connections between modules you didn't realize existed and surfaces the most-connected concepts in your project — the things everything flows through. I'm on an M1 MacBook Pro. Here's the exact setup that worked for me. ``` brew install uv # if you don't have it already uv tool install graphifyy ``` **Important: use uv tool install, not pip install.** On M1 Macs, pip can break Python path resolution because Graphify resolves the Python binary at runtime from a cached path. `uv` isolates the environment and avoids this entirely. I learned this the hard way. ``` cd your-project graphify extract . ``` First run takes a few minutes depending on codebase size. Since our projects are all code (no PDFs/docs), the entire extraction runs locally on tree-sitter — no API key needed for this step. ``` graphify cursor install ``` This writes a `.cursor/rules/graphify.mdc` file with `alwaysApply: true` . If you've worked with Cursor's rule system, you know what this means — it gets injected into every conversation automatically, telling Cursor to prefer `graphify query` over reading raw source files. Quick note for anyone working with `.mdc` files: a rule with `alwaysApply: false` and no `globs` and no `description` will never auto-apply — it becomes manual `@` -mention only. Graphify sets `alwaysApply: true` , which is the correct move for a global project context rule. ``` graphify hook install ``` This installs a `post-commit` hook. Every time anyone commits, it auto-rebuilds the graph using tree-sitter — fully local, takes seconds. It also sets up a git merge driver so if two devs commit graph updates in parallel, `graph.json` gets union-merged automatically instead of leaving conflict markers. After this, you basically forget Graphify is running. The graph stays current with every commit. This is where I had the most questions before adopting it, so let me cover the practical stuff. Add these to your repo: ``` graphify-out/ ├── graph.json # the core artifact ├── graph.html # interactive visualization ├── GRAPH_REPORT.md # architecture summary ├── manifest.json # tracks extracted files (uses relative paths — portable) └── cache/ # optional — commit for faster rebuilds .cursor/rules/graphify.mdc # the Cursor integration rule .graphifyignore # if you create one ``` Add this to `.gitignore` : ``` graphify-out/cost.json ``` `cost.json` tracks Graphify's own LLM API spend during extraction — not tokens saved in Cursor. It's local accounting, not a shared artifact. **Zero.** This matters — Graphify is purely additive. The `graphify-out/` folder is just inert data files. No build process depends on them, no CI breaks without them. The `.mdc` file only affects Cursor users who have that rule active. If a dev without Graphify installed triggers the `post-commit` hook, it fails silently (binary not found) and the commit goes through normally. You can adopt this incrementally. Install it yourself, commit `graphify-out/` , and other devs benefit from the graph whenever they install Graphify later. No coordination needed. `main` `graphify extract .` on main and commit `graphify-out/` . This becomes the shared baseline everyone pulls.One edge case: if someone runs a long-lived feature branch without the hook installed, their `graph.json` will drift. A manual `graphify extract . --update` before raising the MR resyncs it. I've considered adding this to our MR checklist, but honestly the hook handles 99% of cases. A few things I ran into or anticipated: **The M1 pip issue.** Already mentioned above — use `uv tool install` , not pip. Wasted about 20 minutes debugging path resolution before figuring this out. **Can you actually measure token savings?** Honestly, not directly. Cursor doesn't expose per-conversation token usage. What you *can* observe: response latency drops (graph queries are faster than multi-file reads), context window pressure reduces (fewer "context limit reached" moments), and Graphify logs every query at `~/.cache/graphify-queries.log` with nodes returned and duration — so you get a sense of how targeted the retrieval is. The rough mental model: without Graphify, Cursor answering "how does auth connect to the API layer?" reads 8-12 files. A typical React Native file is ~200-400 tokens. That's ~3000 tokens just for context loading, before the answer. With Graphify, it reads a scoped subgraph — a fraction of that. ** cost.json is not "tokens saved."** I initially confused this. `cost.json` tracks what Graphify itself spent on LLM calls during extraction. For a code-only project, this is near zero. It has nothing to do with what Cursor saves in conversation.**Graph drift on branch switches.** If you install the `post-commit` hook but not the `post-checkout` hook, switching branches won't rebuild the graph. The latest version of Graphify supports `post-checkout` hooks too — check if `graphify hook install` sets both up for you. If I were setting this up again: `GRAPH_REPORT.md` before sharing with the team.`cache/` initially.Graphify makes the most difference when: For small projects with 5-6 files, the graph adds structural clarity but the token savings are minimal — the files already fit in a context window. ``` brew install uv uv tool install graphifyy cd your-project graphify extract . graphify cursor install # or the equivalent for your IDE graphify hook install ``` That's 5 commands to set up. The graph builds, your assistant starts using it, and the hook keeps it current. No config files to write, no services to run. Check out the [Graphify repo](https://github.com/safishamsi/graphify) for the full docs. If you're on Cursor specifically, the `.mdc` integration is the smoothest path — it just works. If you've been feeling like Cursor "forgets" your codebase every conversation, or burns through context reading files it shouldn't need — Graphify is worth the 10 minutes to set up. It was for me. *I'm a React Native tech lead exploring AI-assisted development workflows. Find me on Twitter and GitHub.*