GrapeRoot: an MCP context pre-loader for Claude Code, Cursor and Copilot
Compounding Context for AI Coding Assistants — MCP graph engine for Claude Code, Cursor, Copilot, Gemini, OpenCode
At a glance
- What is it?
- GrapeRoot ships Apache-2.0 launcher scripts around a proprietary Python graph engine that pre-loads code into the prompt before the assistant sees your question. The install path is short; the licensing split and the benchmark claims are the parts to inspect before you commit.
- Who is it for?
- Adopt GrapeRoot if your team already runs Claude Code, Cursor or Copilot on a large polyglot repository and you are willing to send your source graph through a proprietary pip package. Do not adopt it for air-gapped work, for languages outside the twelve listed, or if your organisation cannot accept a proprietary dependency inside an otherwise Apache-2.0 toolchain.
- Can I use it commercially?
- Yes. Apache-2.0 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 12 days ago.
- What is it written in?
- Mainly PowerShell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem GrapeRoot targets: assistants that burn turns exploring
An AI coding assistant working on a repository it has not seen has to find the relevant files before it can reason about them. The README frames this as the central cost: other graph tools give the assistant a graph and let it query, so the model calls search_symbol, get_callers or trace_route, reads the results, decides what to look up next, and only then answers. Those exploration turns are billed. GrapeRoot's pitch is that the graph should be consulted by the launcher rather than by the model, so the first prompt already contains the files that matter. The intended user is an engineer running an assistant against a codebase large enough that file discovery is a meaningful share of each session, and the README's benchmark table cites 7,700+ files as the scale it was measured at. Smaller projects, where the assistant can read most of the tree in one pass, are not the target.
Pre-loading versus pull-on-demand: the actual architectural difference
The mechanism the README describes runs in five steps. You invoke a launcher such as dgc with a project path. The project is scanned and a semantic graph is built from files, symbols, imports and call chains. When you ask a question, the graph identifies relevant files and packs them into the prompt. The assistant receives your question with the code already attached. The README claims the graph also records which files were read, edited and queried during the session, so later turns reuse that state rather than rescanning. That session memory is the part described as compounding. It is worth being precise about what this changes: the assistant is no longer the component deciding what to retrieve. Retrieval moves into the launcher, which means the quality of the answer depends on the graph's ranking rather than on the model's tool-calling judgement. That is a real trade. A model that would have queried for an unusual entry point now receives whatever the graph selected, and the README does not describe a mechanism for the assistant to override the selection or request additional files.
Install commands and the dgc wrapper
Installation is per-platform. On macOS and Linux the README gives a curl pipe into bash from the Codex-CLI-Compact repository, followed by sourcing your shell profile. On Windows it gives an irm pipe into iex, or a Scoop route using the dual-graph bucket. Prerequisites are stated as Python 3.10+, Node.js 18+, and one supported AI tool; the installer is said to detect missing tools and offer to install them. Usage is deliberately narrow. The README warns that you should run dgc rather than claude directly, because the MCP server needs to be running for context to be injected. Commands shown include dgc for the current directory, dgc /path/to/project for a specific one, and dgc /path/to/project "fix the login bug" to start with a prompt. Codex CLI uses dg with the same argument shape. The other integrations take a flag on the graperoot command itself: --cursor, --gemini, --opencode, --copilot, --openclaw, --kilocode, --mimocode, --antigravity, --kiro, --command-code. OpenCode additionally has a dgo alias. There is a MiniMax path that requires setting MINIMAX_API_KEY and selecting MiniMax-M3 or MiniMax-M2, though the README excerpt cuts off mid-sentence there, so the full configuration for that provider is not confirmable from the supplied material.
The licensing split is the first thing to resolve
The README states plainly that the launcher scripts in the repository are Apache 2.0 while the graph engine, distributed as the graperoot pip package, is proprietary. That is an unusual arrangement and it should drive your evaluation more than any benchmark number. The repository you can read, fork and audit is the thin part. The component that scans your source tree, builds a symbol graph and decides what gets packed into a prompt is the part you cannot inspect. For a tool that necessarily reads your entire codebase, that asymmetry matters: you are trusting a closed component with full source access, and the Apache-2.0 licence on the launcher tells you nothing about what the engine does with what it reads. The README does not describe the engine's data handling, whether graph data leaves the machine, or what the pip package transmits. Confirm that independently before running it against anything you would not paste into a third-party service. Nothing here is legal advice; the licence question is one for whoever signs off on dependencies at your organisation.
Language coverage and the cases where GrapeRoot is the wrong tool
The supported language list is TypeScript, JavaScript, Python, Go, Swift, Rust, Java, Kotlin, Scala, C#, Ruby and PHP. Twelve languages with no C, C++, Objective-C, Elixir, Haskell, Lua or shell. If your repository's core is in a language outside that list, the graph will be built from whatever it can parse and the pre-loaded context will be correspondingly thinner, which undercuts the whole premise. There is a second limitation in the design itself. Pre-loading is a hard-capped budget per turn, which the README presents as an advantage over letting the model decide. A cap is only as good as the ranking that fills it. On a task whose relevant code is spread across many small files, or where the important context is a build script, a migration file or a config outside the parsed language set, a fixed per-turn pack has no way to pull in what the graph did not rank. The pull-on-demand approach handles that case by letting the model keep looking. GrapeRoot's answer is that the model never has to look, which is faster when the graph is right and less recoverable when it is not. The README does not document a fallback path for when the pre-loaded context is insufficient.
Benchmark claims and what to verify in the methodology
The README's results table reports cost per prompt falling from $0.49 to $0.27, average turns per task from 11.7 to 3.5, average response time from 172s to 124s, and a scored quality figure rising from 76.6 to 86.6 out of 100, across what it describes as multiple real-world codebases of 7,700+ files and 50+ engineering prompts. The per-task-type breakdown claims reductions of up to 81% for migration and architecture design, 80% for performance analysis, 76% for testing, 73% for full-stack debugging, 71% for feature development, 55% for code explanation, and a 43% average on large codebases. These are vendor-published figures from the project's own site. I have not run them and cannot verify them. Two things are worth checking before you weight them: whether the comparison held the model, the prompt wording and the repository constant between arms, and whether the quality scoring was done by the same people who built the tool. The README also asserts that a token avoided on turn 3 skips cache re-billing on every subsequent turn. That is a claim about how provider-side prompt caching interacts with a shrinking context, and it depends on your provider's caching rules and cache lifetime, not on GrapeRoot.
Alternatives: CodeGraph, code-graph-mcp and plain assistant search
The README names CodeGraph and code-graph-mcp as the comparison class, and the difference it draws is real: those tools expose graph queries as MCP tools and let the assistant drive retrieval, while GrapeRoot moves retrieval into the launcher. If you want an inspectable pipeline, that difference cuts the other way. An MCP tool server is something you can read, log and modify; a pre-loading launcher backed by a closed engine is not. The third alternative is doing nothing: modern assistants already search and read files on their own, and on a mid-sized repository that may be adequate. The honest comparison is not GrapeRoot versus another graph tool, it is GrapeRoot versus your assistant's existing file discovery plus whatever prompt caching your provider already applies. If your sessions are short and your repository is small, the second option costs you nothing to evaluate and requires no new dependency.
Maintenance surface and upgrade cost
The repository is PowerShell-first, which is a signal about where the launcher work has gone, and the release history in the supplied material shows v1.0.1, v1.0.2 and v1.0.3 all landing on 2026-02-28 within roughly an hour of each other. That is a burst of patch releases rather than a long tail, and it tells you the project is young at the 1.0 line. The last push recorded is 2026-09-03, so the repository is active. Upgrade cost has two parts. The launcher scripts update through the install commands above, which are curl-pipe and irm-pipe forms, meaning each upgrade re-executes remote code from the default branch of the Codex-CLI-Compact repository. Pin or vendor those scripts if you care about reproducibility. The engine updates through pip independently, and because it is proprietary you are tracking a version number without a changelog you can read in the repository. The support matrix is also a maintenance liability: twelve integrations, each with its own flag, each tracking an assistant that ships on its own schedule. A breaking change in any one of them is a GrapeRoot release. Budget for that if you standardise on this across a team.
Editorial conclusion
Adopt GrapeRoot if your team already runs Claude Code, Cursor or Copilot on a large polyglot repository and you are willing to send your source graph through a proprietary pip package. Do not adopt it for air-gapped work, for languages outside the twelve listed, or if your organisation cannot accept a proprietary dependency inside an otherwise Apache-2.0 toolchain. Before installing, verify three things: what the graperoot package transmits and where, whether your licence review accepts the Apache-2.0 launcher plus proprietary engine split, and whether the benchmark methodology at graperoot.dev/benchmarks describes your codebase size and language mix. The launcher scripts are auditable; the engine is not.
Community notes