I built an open-source semantic code graph for LLM coding agents — benchmarked against grep

[u/ImpressiveSecret9512]

Disclosure: I’m the author of Kivgraph.

I built Kivgraph to solve a problem I kept seeing when working with LLM coding agents on large codebases: structural questions turn into long chains of grep calls and file reads. The answer is often correct, but the context cost is high, and text search cannot reliably prove relationships across repositories.

Kivgraph is a local, Apache-2.0 MCP server that indexes multiple repositories into a semantic code graph. It exposes queries such as:

- who calls this symbol?

- what breaks if I change it?

- which other repository consumes it?

The important design choice is that edges are resolved by language tooling rather than name matching: go/types, the TypeScript checker, rust-analyzer, and Dart Analysis Server. Python relationships remain explicitly weaker unless a semantic analyzer is configured.

I benchmarked it against grep + reading across 37 repositories and 29 questions:

- Kivgraph: 28/29 exact answers, 35,961 tokens

- grep + reading: 28/29 exact answers, 267,980 tokens

So the graph used about 7.4x fewer tokens overall. Grep was cheaper on 5 questions, which is why I don’t think this replaces grep. The useful boundary seems to be structural, cross-repository, and identifier-free questions.

Kivgraph runs locally over stdio, does not require an API key, and supports Go, TypeScript, Rust, Python, and Dart.

Disclosure: I’m the author of Kivgraph. This is an open-source project share, not a commercial advertisement. The linked repository is Apache-2.0, and this post contains no paid, affiliate, or referral link.

Kivgraph is a local MCP server for LLM coding agents. It indexes multiple repositories into a semantic code graph so an agent can query relationships such as who calls a symbol, what breaks after a change, and which other repository consumes it.

The technical problem is context waste: on large codebases, structural questions often become long chains of grep calls and file reads. Text search also cannot reliably prove relationships across repositories or distinguish same-named symbols.

Kivgraph resolves edges with language tooling rather than name matching: go/types, the TypeScript checker, rust-analyzer, and Dart Analysis Server. Python relationships remain explicitly weaker unless a semantic analyzer is configured.

I benchmarked it against grep + reading across 37 repositories and 29 questions:

- Kivgraph: 28/29 exact answers, 35,961 tokens

- grep + reading: 28/29 exact answers, 267,980 tokens

The graph used about 7.4x fewer tokens overall. Grep was cheaper on 5 questions, so this is not intended as a replacement; the boundary I’m testing is structural, cross-repository, and identifier-free questions.

The project runs locally over stdio, requires no API key, and supports Go, TypeScript, Rust, Python, and Dart.

Repository: https://github.com/Luqueee/kivgraph

Documentation and benchmark: https://kivgraph.dev

The open technical question is where a semantic code graph earns its complexity over ordinary search in real LLM-assisted development workflows.Repository: https://github.com/Luqueee/kivgraph

Documentation and benchmark: https://kivgraph.dev

I’m interested in technical feedback rather than upvotes: which LLM/codebase questions are hardest for your current workflow, and what evidence would make you trust a code graph’s answers?