LLM Cheburnexus

LLM Cheburnexus is a full compiler-grade code engine. It runs fully automatically. In Claude Code the engine connects by itself and a search hook steers the search to it. In other editors the assistant sees grep_compiler next to its own search. Works across the whole VS Code family: VS Code, Cursor, Windsurf, VSCodium.

You work as usual and change nothing. Your assistant searches code with one tool — grep_compiler. It is the same familiar search, with hints from the engine.

• Where the engine is stronger than plain search, it helps and drops the noise. It shows right away who calls a method, who inherits a class, who implements an interface. Without it, the agent needs several rounds of searching for this.
• When a search hits a single method, the answer includes the method body.
• Where plain search is enough, it stays silent.

One tool, so the assistant doesn't have to choose between two searches. Usually the cost is the same. Sometimes there is an extra move, or the answer is a bit longer than plain search. On relation questions it saves moves.

The engine has a separate core for C#, TS/JS, Python and Java. Accuracy on C# is close to 100%. You can check this on the fully open benchmark: cheburnexus-bench.

I'm into game development, so most testing was done on C#. There the benefit is proven.

I compared the assistant with and without the engine. On questions about relations in code, the engine saves moves:

• Who calls a method. Especially when different classes have methods with the same name. In one test it took 5 moves instead of 14 and cost half as much.
• Subclasses, including indirect ones. Plain search often misses them.
• Who implements an interface, who depends on a class.

On the Drevo benchmark (C#) the assistant makes about 12% fewer moves overall, and more on relation questions. Answer quality is no worse than with plain search.

TypeScript has been checked by hand on large open-source projects. Java is checked on spring-petclinic and RxJava; Python works but is not tested. For these languages the engine also answers who calls a function and what it depends on. The assistant does not get a project overview; the Project Graph below shows the map of the project. How many moves this saves has not been measured yet.

The project is built on enthusiasm and is completely free. I can't keep developing it alone for now: I have neither the time nor the resources. Python will most likely stay untested unless someone helps. Any help is welcome: runs on your projects, feedback. And if you need a developer, write: t.me/cheburnexus.

Project map

The engine can build a map of your project, and you can view it on the site. In VS Code: click the Project Graph row (or the graph icon in the title bar) in the Cheburnexus panel, or run Cheburnexus: Open Project Graph from the Command Palette. The map opens in your browser at graph.cheburnexus.tech. It needs an index. The engine builds it by itself, so if you see "no index yet", wait a bit and try again. Your data never leaves your machine — the page reads the map from a local server on your computer (127.0.0.1).

Using it

Just ask normally — but point the model at Cheburnexus. It works for far more than search:

• Finding code — "Use Cheburnexus to find where user authentication is handled."
• Before editing — "Check with Cheburnexus who calls PaymentService.refund before you change it." The model sees the blast radius instead of discovering it after breaking something.
• Subclasses — "Use Cheburnexus to list every subclass of BaseHandler, including indirect ones."
• Refactoring — "Use Cheburnexus to find who implements IPayment and where Order is used as a type before we change it."
• Tracing a bug — "Find with Cheburnexus who calls Save on OrderRepository."

When the index is older than your code, the engine rebuilds it by itself in the background.

If the model forgets

Language models are probabilistic — yours may drift back to hand-walking grep for a "who calls this" question instead of reaching for grep_compiler. That is normal, and you fix it in one line:

"Use grep_compiler for that name before you go looking by hand."

Worth saying once at the start of a session, and again whenever you notice it grepping its way through a relation question.

To make it stick permanently, put the instruction in your assistant's project rules file — it is then loaded into every session automatically:

• Claude Code — CLAUDE.md in your project root
• Codex / Cursor — AGENTS.md in your project root

For "who calls X" / "who implements Y" questions, use Cheburnexus's grep_compiler tool
instead of grepping by hand. For everything else, either grep or Cheburnexus is fine.

Install

1. Install the extension.
2. On first run it downloads the analysis engine — one time, verified by checksum. It is not bundled in the extension, so the download is not instant; progress is shown in the status bar.
3. Open your project. The MCP server registers automatically; there is nothing to configure.
4. Ask your assistant something from Using it above.

The Cheburnexus panel in the activity bar shows engine status.

Free for everyone — no key, no daily quota, no trimmed output.

Settings

Search tool: cheburnexus.searchTool

Two modes:

• grep_compiler (default) — our grep_compiler tool is visible to the assistant, and in Claude Code specifically its built-in Grep tool is also turned off, so the session has one search tool, not two competing ones. This is the setup we benchmarked.
• grep — grep_compiler is hidden and the assistant's own built-in search works as normal (in Claude Code, Grep is turned back on).

How to switch it: open Settings (Ctrl+, / Cmd+,), search for cheburnexus, and set Search Tool — or edit settings.json directly: "cheburnexus.searchTool": "grep_compiler" or "grep". It takes effect on the MCP server's next start: restart your assistant's session, or run Cheburnexus: Show MCP Servers from the Command Palette and press Start again.

What actually changes, per client:

Only Claude Code's own search tool actually switches off. For Codex and Cursor this setting only changes whether grep_compiler is visible — turning off their own built-in search from outside is not yet supported by the plugin; we found no documented setting for it in either. We're looking into whether that can change; no promises yet.

Why Claude Code only: Claude Code has a documented setting for this — permissions.deny in .claude/settings.local.json (a project-local file, not committed by convention) — where listing a built-in tool name turns it off for the session. In grep_compiler mode we add "Grep" to that list; in grep mode we remove it again, but only the entry we added ourselves — if you already had Grep denied before touching this setting, we leave it denied. Codex and Cursor have no equivalent documented setting that we could find, so there is nothing for the plugin to flip there.

What gets written to disk: only in Claude Code, only the string "Grep" inside permissions.deny in .claude/settings.local.json — added when you pick grep_compiler, removed when you pick grep, only if we added it ourselves. Anything you put in that file yourself is left alone.

Does grep mode cost you anything? Yes: you lose the engine's hints. On C# they are proven and compiler-checked. On TypeScript, Python and Java grep_compiler adds an approximate list of callers; the savings there are not measured.

Which mode to pick: grep_compiler is the setup we actually benchmarked — on the Drevo benchmark (C#) it took about 12% fewer tool calls overall, and more on relation questions ("who calls this?", "who implements this?"), with answer quality on par with plain grep. The benchmarked benefit is proven on C# only. If you'd rather keep your assistant's native search untouched, grep mode is a fine choice.

Support & feedback

Questions, bugs, feature requests: t.me/cheburnexus.

If something misbehaves, do not just say "it doesn't work" — the plugin can gather the evidence for you. Run Cheburnexus: Collect Problem Report from the command palette (or click Report a Problem in the Cheburnexus panel). It assembles the analysis log, versions and your scope settings into one file.

That file is opened locally for you to review and is never uploaded. It contains paths and folder names from your project — read it, delete anything you would rather not share, then send it.

Privacy

All analysis runs locally on your machine. Your code is never uploaded anywhere. See PRIVACY.md for details.

Contributing

Building, packaging, and the extension's internals are documented in CONTRIBUTING.md.