# Graphify vs. Code Intelligence — Competitive Analysis
*April 22, 2026*

## What Graphify Is

Graphify (by Safi Shamsi, April 3, 2026 — 3 weeks old, 31k GitHub stars from viral Karpathy-post momentum) builds a **persistent knowledge graph** from a codebase, then at query time does a BFS traversal to extract a minimal subgraph rather than re-reading raw files. The "71.5x fewer tokens" claim is:

- **Baseline:** ~123k tokens/query reading raw files naively
- **With Graphify:** ~1.7k tokens/query
- **Corpus:** a single 52-file benchmark — **self-reported, no independent replication**

It's essentially a response to "LLMs waste tokens re-reading files every session." That's a real problem — but the comparison is against **the worst possible baseline** (naive full-file reads), not against RAG or any embedding-based system.

## How Graphify Works Technically

**Three-pass extraction pipeline:**
1. **AST pass (local, no LLM)** — Tree-sitter parses source code deterministically, extracting classes, functions, imports, call graphs, and rationale comments. Source code never leaves the machine. 25 languages supported.
2. **Local audio/video transcription** — faster-whisper runs locally; audio never sent externally.
3. **LLM semantic extraction** — Claude subagents process docs, PDFs, images, and transcripts in parallel. This is the only externally-networked step.

**Graph construction:** NetworkX graph, clustered with Leiden community detection (topology-based, no embeddings). Edges tagged with confidence: `EXTRACTED` (AST, deterministic), `INFERRED` (LLM-derived, scored 0–1), `AMBIGUOUS`. SHA256 cache means only changed files are reprocessed on incremental runs.

**At query time:** BFS traversal extracts the minimal relevant subgraph (~1.7k tokens) instead of full files.

**Output:** `graph.html` (D3 viz), `GRAPH_REPORT.md` (plain-language audit), `graph.json` (queryable persistent graph).

## The "70x Fewer Tokens" Claim — What It Actually Means

The precise figure is **71.5x**. Critical caveats:
- Baseline is **naive full-file reads** (~123k tokens), not RAG, not embedding search
- First run (graph construction) costs substantial API tokens upfront — savings compound on subsequent queries
- **Single self-reported benchmark** on one 52-file corpus — no independent replication, no comparison against RAG-based alternatives

## Apples-to-Apples Comparison

| Dimension | Graphify | Code Intelligence (mcp-vector-search) |
|-----------|----------|-----------------------|
| **Baseline compared to** | Naive full-file reads (123k tokens) | N/A — never stuff raw files |
| **Retrieval approach** | BFS on persistent NetworkX graph | 3-way RRF: vector + BM25 + KuzuDB KG |
| **Typical query token cost** | ~1.7k (subgraph snippet) | ~1-3k (chunks + metadata headers) |
| **Structural queries** | Yes (graph traversal) | Yes (Cypher KG, `trace_execution_flow`) |
| **Keyword precision** | No BM25 | Yes (BM25Okapi) |
| **Semantic similarity** | No embeddings | Yes (MiniLM / CodeBERT / CodeT5+) |
| **Call graph depth** | Unlimited (BFS) | 8 hops / 100 nodes cap |
| **Languages** | 25 (Tree-sitter) | AST via chunker (Python-focused) |
| **Scale ceiling** | Fails >5k nodes (documented bug) | Tested to 31k files (production-hardened) |
| **Maturity** | v0.4.2, 3 weeks old, 130 commits | v3.0.37+, production-hardened |
| **Privacy** | Code stays local; docs/PDFs go to LLM API | All local by default |
| **MCP integration** | No — skill/file generator only | Yes — 20+ MCP tools, native server |

## Where We Win Clearly

1. **Multi-modal fusion** — graph-only approach misses fuzzy semantic matches (renamed functions, docstring queries, "find all places that handle auth"). Our RRF fusion handles these.

2. **Scale** — specifically hardened for 31k+ files (SEGV fixes for large-batch deletes, compaction guards). Their 5k node ceiling is documented and only partially patched.

3. **MCP-native** — a proper MCP server with 20+ tools. Graphify is a skill/file generator, not an MCP server — it can't be invoked dynamically by an AI agent.

4. **Local inference on supported machines** — where Ollama is available, the full pipeline runs with zero API dependency (Ollama/Gemma path). Graphify's semantic extraction always requires an LLM API call for docs/PDFs.

## Their Real Insight (Worth Noting)

Graphify's genuinely smart observation: **graph topology + Leiden community clustering** gives a compact, human-readable codebase map without embeddings. Their `GRAPH_REPORT.md` is a natural-language audit of codebase structure that costs very few tokens.

We have `kg_ia` (IA topic tree) and `kg_ontology` as equivalents — but these aren't surfaced as prominently. The **D3 visualization output** (`graph.html`) is getting traction with users who want a visual map of their codebase — worth noting since we also have D3 viz infrastructure.

The **AST-first, no-LLM-for-code** philosophy is clean and worth emphasizing in our own docs: source code never leaves the machine for embedding.

## Known Graphify Limitations

- Single self-reported 52-file benchmark — no third-party validation
- First-run API cost can be significant for large doc-heavy repos
- Bug causing rebuild failures above 5,000 nodes (partially patched)
- Schema inconsistencies: AST vs. LLM node ID mismatches causing dropped edges
- Hardcoded `graphify-out/` path assumption
- SSRF risk in URL validation path
- Privacy nuance: code stays local, but docs/PDFs/images go to model API
- No MCP integration — not agent-callable

## Verdict

The 70x claim is **real but misleading** — it's 70x vs. the worst possible alternative (naive file stuffing), not 70x vs. us. In a fair comparison, both systems deliver similar token budgets per query (~1-3k). The difference is **what you can ask**: Graphify handles topology questions well; we handle semantic + structural questions with full MCP integration.

Their viral traction reflects genuine market interest in **compact, persistent code intelligence** — which is exactly our space. The threat isn't technical parity, it's mindshare. Worth watching their graph visualization angle.

---
*Research by mcp-vector-search team | Generated 2026-04-22*
