# Code Knowledge Graphs: Graphify vs CodeGraph vs GitNexus

Watch an AI agent answer "what breaks if I change this function?" on a large repo and you'll see something genuinely stupid: it greps for the name, gets forty hits, reads twelve files in full, guesses at the dynamic dispatch it can't see, and produces a confident answer that misses the one caller that actually matters. It burned 80,000 tokens to do worse than a junior with an IDE. The agent isn't dumb. It's just been handed a filesystem and told to reconstruct a call graph by reading text, which is a job we solved with static analysis decades ago and then somehow forgot when the interface became a chat box.

That's the gap these three tools fill. All of them precompute a graph of your codebase and hand it to the agent over MCP so it can ask a structured question instead of reading forty files. I've been through all three, and the useful finding isn't a winner — it's that they're answering three different questions, and one of them has a licence that should stop most readers cold.

## What is a code knowledge graph?

**A code knowledge graph is a precomputed index of your codebase as nodes (symbols: functions, classes, files) and edges (relationships: calls, imports, inheritance), queryable without reading the source.** It's what an IDE's "find all references" runs on, exposed as a database an agent can query.

The core insight is that *this is a build-time problem, not an inference-time problem*. Every one of these tools parses your code locally with [tree-sitter](https://tree-sitter.github.io/tree-sitter/) into an AST, walks it to extract symbols and edges, then resolves references across files. No LLM involved in that step — it's deterministic, it's fast, and nothing leaves the machine. The LLM shows up later, as a consumer of the finished graph.

Which is why I'd push back on the framing that these are "GraphRAG for code." [Knowledge graphs](knowledge-graphs-semantic-web) in the classic sense are about modelling messy real-world semantics. Code already *has* a formal structure — the compiler knows exactly what calls what. These tools aren't inferring meaning from prose; they're recovering structure that was always there and that grep threw away.

```mermaid
graph TD
  A["Source files"] --> B["tree-sitter AST parse"]
  B --> C["Extract symbols functions, classes, methods"]
  B --> D["Extract edges calls, imports, extends"]
  C --> E["Cross-file resolution"]
  D --> E
  E --> F["Community detection (Leiden)"]
  F --> G[("Graph store")]
  G --> H["MCP server"]
  H --> I["Agent asks: what calls this?"]
  J["Docs, PDFs, images"] -.->|"LLM enrichment (Graphify only)"| G
  K["File watcher / git hook"] -.->|"incremental rebuild"| G
```

The shared pipeline. Everything left of the graph store is deterministic and local — the LLM never touches your code during indexing. The two dotted paths are where the three tools diverge most: only Graphify pulls non-code material in, and each has a different answer for keeping the graph fresh.

## The three bets

Strip away the READMEs and each tool is a wager on what the bottleneck actually is.

**CodeGraph bets the bottleneck is agent friction.** One SQLite file, and — the detail I find most interesting — essentially *one* MCP tool. `codegraph_explore` answers almost any structural question in a single call, returning verbatim source grouped by file, the call paths between symbols, and a blast-radius summary. The narrower tools (`codegraph_callers`, `codegraph_impact`, and friends) still work but are unlisted by default, because measured agent behaviour showed one strong tool steers models better than a menu of narrow ones — fewer mis-picks. That is a real finding about LLM ergonomics, and it runs directly against the instinct to expose a rich API.

**GitNexus bets the bottleneck is analysis depth.** Rather than handing the agent raw edges and hoping it explores enough, it precomputes at index time — clustering, tracing, confidence scoring — so a tool call returns complete context in one shot. Its `impact` tool doesn't just list callers; it groups them by depth and labels them, so depth 1 reads "WILL BREAK" and depth 2 reads "LIKELY AFFECTED", each with a confidence percentage. With `--pdg` enabled it goes further into statement-level control and data dependence, with taint tracking from source to sink. That's program analysis, not indexing.

**Graphify bets the bottleneck is scope.** Code is only part of what a system is; the schema, the ADR explaining why, the paper the algorithm came from, the architecture diagram. Graphify pulls all of it into one graph — roughly 40 languages via tree-sitter, plus LLM enrichment for docs, PDFs, images, and video. Rationale from comments and ADRs becomes a first-class node. And notably: *no embeddings*. As the project puts it, this is "not a vector index... a real graph you traverse."

|  | CodeGraph | GitNexus | Graphify |
| --- | --- | --- | --- |
| Storage | SQLite + FTS5, one `.db` | LadybugDB (ex-KuzuDB) embedded graph | Plain `graph.json` |
| Language | TypeScript | TypeScript | Python |
| MCP surface | **1 listed tool** | **17 tools** + 2 prompts | 7 tools |
| Languages parsed | 30+ | 14+ | ~40 (36 grammars) |
| Non-code material | No | No | **Docs, PDFs, images, video** |
| Freshness | OS file watcher, 2s debounce | Re-index / `detect_changes` | git post-commit hook |
| Browser mode | No | **Yes** (WASM, ~5k files) | Static `graph.html` viz |
| Standout | Zero-config freshness | Impact + taint analysis | Breadth beyond code |
| Licence | MIT | **PolyForm Noncommercial** | MIT |
| Stars / first commit | 60.5k · Jan 2026 | 44.2k · Aug 2025 | 89.3k · Apr 2026 |

## The licence, because nobody reads them

**GitNexus is licensed [PolyForm Noncommercial 1.0.0](https://polyformproject.org/licenses/noncommercial/1.0.0), not an open-source licence.** It permits use only for noncommercial purposes. If you are being paid to write the code you point it at, you are outside the grant without a separate commercial licence from the author. GitHub's own API doesn't even classify it — the licence field comes back `NOASSERTION`, so the usual "it's on GitHub with 44k stars, must be fine" heuristic fails silently here. This is not a technical footnote. It's the first question your legal team will ask and the fastest way to get a tool ripped back out of a repo six months in. CodeGraph and Graphify are both MIT.

I want to be careful here: PolyForm Noncommercial is a perfectly legitimate choice, and the author is entitled to it. Plenty of good software is funded that way. But the practical consequence for most people reading this is blunt — GitNexus is the most analytically sophisticated of the three, and it is also the one you probably cannot ship at work without a conversation and a cheque. Evaluate it knowing that, not after.

## About those star counts

Graphify has 89,330 stars and its first commit was in **April 2026**. That is roughly three months. For scale, that trajectory would put it near the most-starred repositories in the history of GitHub, above tools that took a decade to get there. CodeGraph did 60k in six months. GitNexus went from about 1.2k to 42.9k between April and June.

I'm not accusing anyone of anything, and I have no evidence of manipulation. But I've been doing this long enough to state the boring version plainly: **stars measure attention, not production readiness, and in an AI-tooling hype cycle they measure attention very badly.** Three-month-old projects have three-month-old bug tails. Graphify carries 529 open issues; CodeGraph 310. Neither number is damning — they're both moving fast — but neither is the profile of a settled dependency either. Treat all three as promising, none as proven, and pin your versions.

## How fresh is the graph? (the question that decides everything)

**A stale code graph is worse than no code graph**, because the agent trusts it. If the index says `getUser` has three callers and you added a fourth ninety seconds ago, the agent will confidently tell you the blast radius is three. It has no way to know it's wrong, and neither do you until something breaks.

CodeGraph is the only one of the three that treats this as a first-class architectural problem, and its three-layer answer is worth stealing regardless of which tool you pick:

1. **Native OS file events** (FSEvents/inotify/ReadDirectoryChangesW) with a 2-second debounce, so a burst of edits collapses into one re-index rather than thrashing.
2. **A staleness banner** during the debounce window — tool responses explicitly flag pending files and tell the agent to read those directly. It admits what it doesn't know, which is exactly the property you want and almost never get.
3. **Connect-time reconciliation** — on reconnect it checks size, mtime, and content hashes against the working tree before answering the first query.

Graphify hooks git post-commit, which is coarser (your graph is only as fresh as your last commit) but has a genuinely clever wrinkle: a union-merge driver on the graph artifact, so two people rebuilding it on different branches don't produce a merge conflict. That's the kind of detail you only add after being burned.

The honest reading: if your agent works across uncommitted changes — which is most agentic coding — commit-triggered indexing is a real gap, and CodeGraph's watcher is the better model.

## Do the savings hold up?

**Yes, and more than I expected — but only on big repos.** CodeGraph publishes per-codebase benchmarks rather than one hero number, which is itself a credibility signal:

| Codebase | Size | Fewer tool calls | Fewer tokens | File reads |
| --- | --- | --- | --- | --- |
| VS Code | ~10k files | 81% | 64% | 0 vs 9 |
| Django | ~3k files | 77% | 60% | 0 vs 9 |
| Alamofire | ~110 files | 58% | 64% | 0 vs 9 |
| *Median across 7 codebases* | *58%* | *—* | *~zero* |  |

Note what the project says about its own numbers: the savings are "small and noisy on a modest codebase, and material only once a repo is large." A vendor volunteering the conditions under which its benchmark *doesn't* impress you is rare enough to be worth naming. It also matches the shape you'd predict — the graph's advantage is skipping exploration, and small repos have little to explore.

So the sizing rule is unglamorous: **under a few thousand files, this tooling is mostly ceremony.** Pack the context and move on. The graph earns its keep when the call chains are longer than the agent's patience.

## Which one, for what?

| If you… | Pick | Because |
| --- | --- | --- |
| Want the graph to just work, invisibly | CodeGraph | One file, one tool, a watcher that keeps it honest. |
| Ship commercial code | CodeGraph or Graphify | MIT. GitNexus is off the table without a licence. |
| Need real impact analysis before a risky change | GitNexus | Depth-grouped blast radius with confidence; nothing else is close. |
| Need taint / data-flow (source→sink) | GitNexus | `--pdg` + `explain`. This is proper program analysis. |
| Have docs, schemas, and papers that matter as much as the code | Graphify | The only one that treats non-code material as first-class nodes. |
| Work across many repos / microservices | GitNexus | Groups + contract registry for cross-repo edges. |
| Run a repo under ~1–2k files | None yet | The savings don't clear the setup cost. Revisit as you grow. |

My actual default for a commercial team: **start with CodeGraph.** Not because it's the most capable — it plainly isn't — but because the freshness story is the one that determines whether anyone still trusts the thing in month three, and because a single tool that's hard to mis-call beats a rich API the model picks wrong from. Add Graphify alongside if your architecture rationale lives in documents nobody reads. Reach for GitNexus when you have a specific analysis problem worth a licence conversation.

And they genuinely do compose. Graphify indexing the surrounding material while CodeGraph tracks the live code is not a contradiction — it's two different questions with two different answers.

## The part that generalizes

Underneath the feature lists there's one design lesson worth carrying to any [agent harness](agent-harness-design) you build: **the tools that win are the ones that make the model's job smaller, not the ones that give it more options.** CodeGraph hiding its own API behind a single call is the same instinct as precomputing at index time instead of letting the agent traverse — both are refusals to push work onto inference that could be done deterministically beforehand.

This is the reverse of how most MCP servers get built. The temptation, once you've done the hard work of building a graph, is to expose all of it — every edge type, every traversal, every filter — and let the model figure out the right combination. It won't. It'll pick the third-best tool, call it with slightly wrong arguments, and burn a turn discovering that. I made exactly this mistake when I first wrote about [building MCP servers](building-mcp-servers), and the measured result here is a useful corrective: expose the answer, not the API.

The same principle runs through [MCP versus Agent Skills](mcp-vs-agent-skills). What an agent needs is rarely more capability. It's less ambiguity.

## What to carry away

These three tools are not competing for the same slot. CodeGraph is infrastructure that disappears — one SQLite file, one tool, a watcher that keeps it truthful, and the best answer to staleness of the three. GitNexus is an analysis engine wearing an indexer's clothes, with impact and taint work nobody else attempts — and a noncommercial licence that puts it out of reach for most paid work. Graphify is the widest net, the only one that thinks your PDFs and schemas are part of the system, which they are.

Check the licence before the benchmark. Check the repo size before either — under a couple of thousand files none of this pays for itself. And treat the star counts as weather, not climate: three-month-old projects with tens of thousands of stars and hundreds of open issues are exciting, not settled.

The thing I'd want someone to take from this even if they adopt none of them: your agent doesn't need to read files to know what calls what. That information is derivable, deterministically, before the model ever wakes up. Every token spent rediscovering it is a token spent badly.