ctx-optimize vs the field — an honest comparison

the landscape · mid-2026

The category converged on one pattern: a local graph, served over MCP.

A year ago "give your agent codebase context" meant embeddings and a vector DB. It doesn't anymore. The tools that broke out — CodeGraph (~47K stars, MIT) and GitNexus (~42K stars) — both pre-compute a structural graph on-device and expose it to agents over the Model Context Protocol (MCP): no cloud, no embeddings API, no code leaving the machine. graphify popularized the central-store idea; potpie took the funded, Neo4j-backed platform route; Serena skips the graph entirely and wraps live language servers. We share the local-first, deterministic half of that consensus — and we make one deliberately contrarian choice, spelled out below.

Numbers are approximate, mid-2026, and move fast. Star counts and feature lists here are from public repos and third-party write-ups (linked at the bottom), not our benchmarks. The head-to-head performance harness is still being built (proof/compare/) — when it lands, the measured rows replace the claimed ones, wins and losses alike.

the table

Where everyone stands, as honestly as we can draw it.

	ctx-optimize	CodeGraph	GitNexus	graphify	potpie	Serena
Adoption (approx)	new	~47K★	~42K★	~82K★	funded	established
Runtime	one static Go binary	SQLite	embedded DB	Python	Neo4j service	language servers
Setup deps	zero	zero (1 file)	zero	model key	DB + infra	LSP per lang
Distribution	agent skill + hook	MCP (42 tools)	MCP (16 tools)	skill	API	MCP
Agent reach	CC / Codex / Copilot / Devin	8 hosts via MCP	MCP hosts	skill	API	MCP hosts
Determinism	no model, ever	structural	structural	model-assisted	LLM in loop	LSP-exact
Extraction engine	tree-sitter AST	AST	AST	AST	AST	language server
Call-edge precision	AST + conservative name-resolve	AST name-resolve	AST name-resolve	AST name-resolve	AST name-resolve	LSP type-exact
Freshness / staleness gate	git-HEAD gate	auto-sync	sync	static dump	re-index	live
Routes / deps / k8s as graph	yes (v0.3)	routes+bridges	partial	no	no	no
Extensible without forking	packs (4 axes)	config	config	plugins	no	no
Module = scattered folders (src/ + tests/)	yes (v0.3.5)	one graph	one graph	one graph	—	—
Team clone → prebuilt graph in one step	init auto-pulls	rebuild	rebuild	rebuild	re-index	re-warm
License	MIT	MIT	noncommercial	open	open-core	MIT

green = a genuine strength, amber = partial / caveated, red = a real weakness. Notice ours has red in it. The most important red is MCP — see "our bet."

performance · where we beat

Two kinds of numbers: what we measured, and what's structurally true of everyone.

1. Setup & footprint — true for every rival, by architecture

You don't need a benchmark to count dependencies. This is the win we hold against the whole field, not just one tool — the deterministic single binary carries none of the runtime cost a graph-DB, a model, or a language-server does:

	ctx-optimize	CodeGraph	GitNexus	graphify	potpie	Serena
Services to run	0	SQLite (embedded)	embedded DB	Python runtime	Neo4j	LSP / language
Model / API key	none	none	none	for labeling	LLM in loop	none
Install	1 static binary	binary + index	binary	pip + deps	containers	server + LSPs
Works fully offline	yes	yes	yes	not for labeling	no	yes
Cold start → first answer	seconds	seconds	seconds	index + model	DB bring-up	LSP warmup

2. Measured head-to-head — graphify (the one we've fully run)

The cross-tool harness (proof/compare/) that runs CodeGraph, GitNexus, potpie and Serena on the same repos is still being built — so for a real, apples-to-apples number today we only claim graphify, on the deterministic core both tools share (M5 Pro, cold shell, raw data):

operation	corpus	ctx-optimize vs graphify	note
Cold gather	graphify source, 12,484 files	13.3× faster	store 8.3 MB vs 30.1 MB — 3.6× smaller; nodes within 1%
Cold gather	gin, 159 files	2.2× faster	graphify finds slightly more nodes here — shown as-is
Query latency	12k-file corpus, median of 5	~4× faster	3.8–4.1× across three questions, 2,000-token budget

Honest caveats, same as on the benchmarks page: graphify was timed on its fastest deterministic path (no clustering, no LLM); on gin and its own source it finds a few more nodes than we do, shown as-is; and it does things we deliberately don't (LLM community labeling). This is the shared core, not a claim we win at everything.

3. Our absolute numbers + their published claims

ours (measured)	result	theirs (their claim)
Cold gather, 12,484 files	0.67 s	CodeGraph: 58% fewer tool calls, 22% faster
Query, 1.49M-node Chromium store	< 1 s	GitNexus / graphify: large token savings
Federated query, 188K-node monorepo	≈ 0.6 s	(measured their way, not ours)

When the full harness lands, every rival gets a measured row here — including the ones where we lose. Until then we won't fake a head-to-head we haven't run. Raw data behind ours: proof/agent · bench/results.json.

each rival, straight

What each competitor is genuinely better at — and where we'd pick ourselves.

CodeGraph

~47K★ · MIT · SQLite + MCP · 38 languages

theirsThe one to beat. MCP-native with 42 tools across 8 agent hosts, a VS Code extension, auto-sync on change, and framework-route + cross-language-bridge extraction we're only now matching. Easiest thing in the category to adopt.

oursA SQLite file is still a store format; our single static binary has literally zero moving parts, and our pack doctrine lets a team add routes/manifests/languages without a fork. But today, honestly: they reach more agents than we do.

GitNexus

~42K★ · noncommercial · zero-server DB · 16 MCP tools

theirsThe deepest Claude Code integration going — 16 MCP tools including impact detection and PR triage, plus skills and hooks. Temporal / git-aware analysis is their strength.

oursTheir license is noncommercial — a real blocker for company use; we're MIT. And we ship git co-change edges in the same deterministic binary. Their MCP depth still beats our reach today.

graphify

~82K★ · open · Python · central store

theirsThe star magnet and the idea's popularizer — community detection, the central-store layout, a big plugin ecosystem, huge mindshare.

oursIts output is a static dump that goes stale silently, it leans on a model, and multi-repo merge is weak — the exact gaps we built fresh, determinism, and mirrored per-module stores against. We adopted its best idea (community subsystems) without the staleness.

potpie & Serena

potpie: funded, Neo4j · Serena: LSP-as-MCP

theirspotpie: a funded platform with task-specific agents on a real graph DB. Serena: language-server-exact symbol precision — genuinely more accurate call edges and rename-safety than any static index, ours included.

ourspotpie's Neo4j is infra we refuse to require; a single binary is the opposite bet. Serena has no persistent graph and no cross-language/route/dep view — and needs an LSP per language. Their precision is the thing we most want to close (exact call edges are on our roadmap).

our bet — and our one honest gap

A single deterministic binary you extend, not a service you run.

Strip away the scoreboard and the difference is philosophical. Everyone else is a store format + a server (SQLite, LadybugDB, Neo4j) or a live service (LSP). We're a single static Go binary — no database process, no embeddings, no model, no network except a remote you configure — whose artifacts are plain, sorted, git-diffable files. What that buys:

+Truly zero setup. npm i -g or one binary, works offline, nothing to stand up — not even a local DB daemon.
+Extend without forking. Routes, manifests, languages, and any data source are drop-in packs/adapters — commit the file, the whole team's agents inherit it. No other tool here lets you add a framework recognizer as a committed JSON file.
+Honest provenance + freshness. Every edge is EXTRACTED (parsed) or INFERRED (name-matched); fresh gates answers against git HEAD so the agent never trusts a stale graph.
+More than code. Routes→handlers, dependencies that federate across build tools, k8s topology, git co-change, community subsystems — in one graph, one query.
±Agent skill over MCP — a deliberate bet. The leaders distribute over MCP; we bet on the agent-skill + hook + committed pointer path instead. A skill is richer than a fixed MCP tool list — it teaches the agent when and how to use the store, carries the query-craft rules, and drives onboarding and customization end-to-end. The tradeoff, stated plainly: on MCP-only hosts (Cursor, Kiro, Gemini CLI) you'd wire the CLI in yourself — there's no MCP server, by choice, and there won't be one. On Claude Code, Codex, Copilot and Devin the skill lands the moment you run install --skills.
−Call edges are conservative, not LSP-exact. We parse with tree-sitter (real ASTs, same engine class as CodeGraph/GitNexus/graphify) and resolve a call to its declaration by unique name — dropping ambiguous matches rather than guessing, so there are no false edges. That's the same precision tier as the other graph tools; only Serena's language server is genuinely type-exact (it knows the exact overload). Closing that last gap (go/x/tools first) is on the roadmap.

The honest summary: if you want the most-adopted, MCP-everywhere tool today, that's CodeGraph or GitNexus. If you want a company-safe license, avoid GitNexus. If you want symbol-exact refactors, add Serena. If you want one zero-dependency binary that indexes code + routes + dependencies + infra deterministically and lets your team extend it without a fork, delivered to your agent as a skill rather than an MCP server, on Claude Code / Codex / Copilot / Devin — that's us. We'd rather earn the comparison than hide from it.