Code-Graph-RAG: two models, one Cypher hop, three version lines
The ultimate RAG for your monorepo. Query, understand, and edit multi-language codebases with the power of AI and knowledge graphs.
At a glance
- What is it?
- Code-Graph-RAG parses a multi-language repository into a knowledge graph with Tree-sitter, then answers questions and edits code by generating Cypher. Two separate model endpoints do the work, and the PyPI release lags the newest tag by tens of patch versions.
- Who is it for?
- Code-Graph-RAG suits a team that wants questions answered against real parsed structure rather than chunks of text, and that is willing to configure two model endpoints. Decide first whether you need the newest code or the newest release, because the two ship on different cadences.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on November 13, 2026, and from our analysis. They are not legal advice.
Star history
- vitali87/code-graph-rag5,354 ★ · +2,888
| Repository | 2026-08-02 | 2026-11-13 |
|---|---|---|
| vitali87/code-graph-rag | 2.5k | 5.4k |
2,888 Stars in the last 103 days, measured from the daily GitHub snapshot. Compare with other projects
Editorial analysis
The pipeline is a parser, a graph, and a Cypher generator
The architecture is a straight line, and knowing it tells you where a bad answer comes from. Source code goes through a Tree-sitter parser and AST analysis into a knowledge graph, stored in an embedded SQLite file by default, with Memgraph and Neo4j as opt-in backends. A user query goes to an AI model that generates Cypher, the Cypher runs against the graph, and the result becomes the response. Each stage has its own failure mode. If the parse is thin, the graph is thin and no Cypher can recover missing nodes. If Cypher generation drifts from the schema, a correct graph returns nothing. The component split is explicit in the tree: the RAG system lives under `codebase_rag/`, with `cgr/` and `codec/` directories beside it. The stated pipeline is:
Source Code -> Tree-sitter Parser -> AST Analysis -> Knowledge Graph
|
User Query -> AI Model (Cypher Gen) -> Cypher Query -> Graph Results -> ResponseThe design point is that the language model never reads your source directly. It reads the graph.
Three frontends sharpen Tree-sitter, and each covers a different slice
Tree-sitter is the backbone, but the project layers compiler-grade frontends on top where a toolchain happens to be available. libclang handles C and C++, `go/types` handles Go, and Roslyn, `javac` and Jedi are opt-in additions for C#, Java and Python. The framing in the documentation is honest about the limits of both layers. A trace only sees code that ran, and a compiler frontend only covers what its toolchain can build. That sentence is the one to hold on to, because it defines a coverage gap you will not see from the outside: a file the toolchain cannot compile never gets its exact facts, only its parsed structure. Runtime behaviour is the third layer, added through `cgr trace`, which traces a test run or pulls production eBPF profiles and merges the calls that actually happened into the graph. The claim attached to that feature is specific: it exposes dispatch that static analysis cannot see.
Thirteen languages are full support, eight are structural only
The support tiers are not marketing buckets, they are a statement about what lands in the graph. Python, TypeScript, TSX, JavaScript, Rust, Go, Java, C, C++, C#, PHP, Lua, Dart and Julia are described as fully supported. Scala is in development. Ruby, Kotlin, Swift, Elixir, Haskell, Solidity, Bash and Nix have structural support only, arriving through the pluggable ast-grep tier, which covers modules, functions, classes where the language has them, and imports. Structural support means the nodes exist but the depth does not, so a question about call chains or type flow in a Kotlin service will be answered from a thinner graph than the same question in Go. A per-language matrix is referenced for the exact capabilities, which is the document to check before you pick this for a mixed monorepo. The parser grammars come from the `treesitter-full` extra, and the structural-tier languages from the `ast-grep` extra.
Two model endpoints, and the example config pairs them freely
The `.env.example` file reveals the shape of the configuration, and it is not one model. There are two independent blocks, `ORCHESTRATOR_*` and `CYPHER_*`, and the orchestrator drives the editing and optimisation side while the Cypher side drives query generation. Each block takes a provider, a model, and a credential. The shipped examples cover a fully local setup on Ollama with `qwen2.5-coder`, all-OpenAI and all-Google hosted setups, a Google Vertex AI setup with a project id and region, and two mixed arrangements where the orchestrator and the Cypher model come from different vendors. A local endpoint is written as `http://localhost:11434/v1`, which is the Ollama OpenAI-compatible route. Two consequences follow. First, you can keep query generation on a local model while sending edits to a hosted one, or the reverse. Second, the example file ships every line commented out.
PyPI ships every fiftieth version, so pip installs lag the tag
Three release channels exist and they deliberately track different things. Git tags cover every version, one per merge. GitHub Releases, with binaries and signatures, cover every fiftieth version plus any security fix, breaking change or merge labelled `release now`. PyPI matches that same cadence. The consequence is stated plainly: the newest tag on `main` usually runs ahead of the newest release, often by tens of patch versions, and the two coincide only just after a release. Nothing is stuck, the cadences differ by design, and a security fix does not wait, since it ships a release and a PyPI upload immediately. So the version you get from a package manager is the newest release, not the newest code, and interim tags exist only so every merge is addressable. If you need newer than the release, install straight from git. Upgrading follows the same split.
uv tool install "code-graph-rag[treesitter-full,ast-grep,semantic]"
pipx install "code-graph-rag[treesitter-full,ast-grep,semantic]"The package file currently records version 0.5.0, matching the newest release, v0.5.0.
The first run needs a container stack and a parse pass per repository
The graph lives in an embedded SQLite file by default, so there is no database server to run: no Docker and no `cmake`. The prerequisites beyond the package are Python 3.12+ and `ripgrep`. One command parses a repository into a knowledge graph, and after that `cgr start` answers questions and edits code, grounded in that graph:
cgr start --update-graph
cgr startThe extra named `semantic` installs the vector search side. Edits are applied through AST-based surgical patching with a diff preview, so nothing changes on disk before you see it.
Editorial conclusion
Code-Graph-RAG suits a team that wants questions answered against real parsed structure rather than chunks of text, and that is willing to configure two model endpoints. Decide first whether you need the newest code or the newest release, because the two ship on different cadences. Check the language support matrix before committing: Scala is still in development and eight languages get structural coverage only. If a compiler frontend matters for your stack, make sure its toolchain is available, and note the package requires Python 3.12 or newer.
Frequently asked questions
What is a graph RAG system?
In Code-Graph-RAG the flow is a parser into a graph, then a generated query against that graph. Source code goes through a Tree-sitter parser and AST analysis into a knowledge graph, a user query goes to an AI model that produces Cypher, the Cypher runs, and the result becomes the response. The language model reads the graph rather than the source text.
How do I make a graph RAG with Code-Graph-RAG?
Install the package with the extras, then parse a repository. `uv tool install "code-graph-rag[treesitter-full,ast-grep,semantic]"` or `pipx install "code-graph-rag[treesitter-full,ast-grep,semantic]"`, then `cgr start --update-graph`. You need Python 3.12+ and ripgrep; the graph lives in an embedded SQLite file by default, so no Docker or cmake is needed.
Is graph RAG better than vector RAG?
What it states is what its own graph adds: real parsed structure including call and reference edges from entry points, structural search and rewrite by AST pattern with ast-grep, and runtime traces merged from `cgr trace` that expose dispatch static analysis cannot see.
Is Neo4j a graph RAG?
In this project the graph is stored in an embedded SQLite file by default, and Memgraph and Neo4j are opt-in backends that run the same Cypher. The RAG system under `codebase_rag/` is an interactive CLI that turns natural language into Cypher queries, retrieves matching code, and drives editing and optimisation.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/vitali87-code-graph-rag)Star history chart for your README
[](https://hysenlabs.com/projects/vitali87-code-graph-rag)Was this useful?