Variant TechnologiesEvery other agent dumps your files into a context window and hopes. Benzi compiles your codebase into a resolved map first — calls, data flow, references — then navigates it with real tools. One compiler, ten languages, one map.
How Benzi is different
Most AI coding agents dump a repository into a context window and hope the model finds what matters. Benzi compiles it instead: a real compiler, built on tree-sitter, parses every file, resolves every import, builds class ancestry, and traces every identifier to its definition — one precise, queryable map, built before a single question is answered. Call flow and data flow are joined at every call site, so a bad value traces to its origin in one tool call.
Claude Code greps; Cursor embeds; Aider maps signatures; Benzi resolves — and answers in O(1). Every language runs its own tree-sitter grammar into that same compiled map — ten so far, plus a second engine for markup (HTML, CSS, DOM-JS).
SWE-bench Verified · 500 instances · one attempt each
swebench.harness.run_evaluation
The full SWE-bench Verified set — 500 real GitHub issues from twelve Python repositories — run end to end through Benzi on DeepSeek v4-flash, graded by the official SWE-bench harness inside its own per-instance Docker images. Network access to GitHub and PyPI was blocked inside every container, so nothing could look up an answer.
Try Benzi
Three ways to see it work, not screenshots. A whole app Benzi built from a single chat, a real essay on what querying a codebase actually finds, and the same agent taking apart VS Code’s own source, live. One code intelligence layer built on tree-sitter, a dedicated grammar per language, ten languages deep: Python · JavaScript · TypeScript · Java · C# · C++ · C · Go · Rust · Ruby — plus a second engine for markup: HTML · CSS · DOM-JS.
A dating app for horses, greenfielded in one chat session. Procedural SVG portraits (no image is a file — every horse is drawn in code), a swipe deck, and live AI chat where every match flirts back through a real model. Frontend, backend, and the prompts — all written by Benzi. (If the app bugs out, please open it in a new tab.)
!! interactive — try clicking around !!
Everyone says DOOM’s engine was ahead of its time. Almost nobody has opened
z_zone.c to see why. So we pointed Benzi at it. A few things were worth
writing down.
There is no malloc() during gameplay. id (the developer) wrote
their own memory allocator — one big arena grabbed once at startup, sliced into
blocks tagged by how precious they are (PU_STATIC, PU_LEVEL,
PU_CACHE…). The genius part: allocating new memory can silently evict
old “cache” blocks it walks past along the way — no one calls
free(), the allocator just decides your cached texture is cheap to
regenerate and reclaims the space on the spot. That’s cache-eviction policy baked
directly into the allocation path itself. malloc/free still
can’t do that today.
There’s no floating point math, anywhere, in the renderer.
tables.c is a 2,000+ line file that is almost entirely one thing: every
sine, tangent and arctangent value the engine will ever need, precomputed at compile
time into lookup tables. Movement, angles, rendering — all fixed-point integer
math against these tables. Not every ’93 machine had an FPU, and even where it
did, table lookups beat live trig every time.
The whole screen is just a byte array — and “UI” isn’t a
system, it’s a coincidence. screens[0] is a flat 320×200
buffer, one byte per pixel. The 3D world gets drawn into it column by column. Then the
HUD gets stamped on top using the exact same pixel-blitting function used to draw
monster sprites and gun sprites. There is no UI toolkit, no widget tree, because there
was nothing to build one on top of: the game owns the entire display, full stop. A
health digit and a demon sprite are the same kind of draw call.
Collision detection has its own hand-rolled spatial index.
p_maputl.c splits the map into a grid (the “blockmap”) so hit
detection only checks nearby geometry instead of scanning every wall in the level
— a spatial hash, built from scratch, years before that was a common technique
people talked about.
None of this was over-engineering. Every one of these systems exists because the
standard answer (malloc, floats, a GUI library, brute-force collision)
either didn’t exist on the target hardware or would have been too slow.
Explored with Benzi — reading a codebase directly, instead of guessing from memory.
The real repo is 1.8M lines — this indexes 923k of them: the editor core
(src/vs/editor + src/vs/base), the platform services layer, and workbench’s
shell/API/browser plumbing (not the 747k-line grab-bag of individual built-in features in
workbench/contrib) — all TypeScript, VS Code’s own language. Built once, in
just over two minutes, then cached — it updates incrementally once loaded, like on this website.
Loading. Wait time: 30 seconds.
!! interactive — try asking questions !!
The architecture · one compiler, one agent loop
Everything that falls out of actually resolving the code — from the index itself to the gates on every write.
Every file parsed, imports resolved, class ancestry built, every identifier traced to its definition — before a single question is answered. Call flow and data flow are joined at every call site, so a bad value traces to its origin in one tool call. Claude Code greps; Cursor embeds; Aider maps signatures; Benzi resolves — and answers in O(1). Every language runs its own tree-sitter grammar into that same compiled map — ten so far: Python · JavaScript · TypeScript · Java · C# · C++ · C · Go · Rust · Ruby — plus a second engine for markup: HTML · CSS · DOM-JS.
Every write passes syntax and semantic gates against the real language parser — a broken parse auto-reverts. The model checks blast radius before it changes anything, not just after: the same analysis — the changed symbol, its callers, its holders, the selectively relevant existing tests — runs both going in and once a write lands.
A sample of 16 of Benzi's 35+ tools.
get_callersEvery call site that reaches a function — the code that will feel a change.
call_treeThe transitive call closure from one function, forward or in reverse.
trace_pathThe call chain connecting two functions, and the data carried along it.
external_callsWhich libraries a scope leans on, and where it calls into them.
forwardflowWhere a function's return value ends up, everywhere it has to match.
backflowWhere a wrong value came from, without opening every caller.
profileThe full 360 on one symbol in a single call.
get_definitionThe declaration card — signature, docs and location.
search_symbolsCase-insensitive substring search across every symbol in the repo.
get_hierarchyA type's resolved bases and its direct subclasses.
skim_sourceA body's one-level outline, so you know which lines are worth reading.
execute_fromRuns a file under the call tracer and records what actually happened.
check_last_executionReads back the last recorded run's facts, no re-run needed.
execute_generated_testcaseWrites a self-contained repro and runs it to debug its own change.
rollback_editUndoes the last writes by snapshot reload, not by re-editing.
upgrade_to_proEscalates itself to a larger reasoning budget mid-task.
24-bug cross-harness benchmark · each point is one bug
| Harness · model | Lines read | vs Benzi |
|---|---|---|
| Benzi · Sonnet | 9,125 | — |
| Benzi · DeepSeek | 16,407 | 1.8× |
| Claude Code · Sonnet | 20,704 | 2.3× |
| DeepSeek Harness · DeepSeek | 43,598 | 4.8× |
Lines read counts only what came back from file-read calls — grep and shell output are search, not reading. It is the one figure that means the same thing in every harness, which is why it is the one compared here.
From the 24-bug cross-harness benchmark: every harness opens more source as bugs get harder — the question is the slope. Each point is one bug, laid out easiest to hardest, left to right. Hover any point for the bug and its count.
Difficulty is Claude Code's turn count on that bug — a third-party yardstick, so no harness sets its own position on the axis. Lines read counts only what came back from file-read calls; grep and shell output are search, not reading. The figure beside each line is its slope: how many extra lines that harness opens per step of difficulty.
The same 24 bugs in the same order, with wall clock in place of lines read.
Wall clock is raw — Benzi's per-repo index build is not subtracted. Each point is that harness's most recent solved run for that bug; unsolved and unfinished runs are left out rather than plotted as fast. Benzi on Sonnet never solved http-parser and the DeepSeek harness never ran nats-server, so those two points are absent and neither enters its fit.
And the same again with dollars on the vertical axis.
Priced at the published per-token rates, same run selection as the chart above. The two DeepSeek series run an order of magnitude cheaper than the two Sonnet ones, so at this scale they sit close to the baseline. What the axis does show is the slope: Claude Code's cost climbs with difficulty faster than any other series here. Full tables behind every point live on the benchmark page.
Links · everywhere Benzi lives