Serena vs Graphify vs CodeGraph vs repowise: Benchmarked on the Same Repos

Pick Serena for symbol-level edits with nothing to index, Graphify for a graph your team can open and share, CodeGraph for the fastest local call graph, and repowise when agents also need git history, ownership, docs and health from the same index. All four give a coding agent a better view of a codebase than grep and file reads, and in our benchmark all four were leaner than a bare agent on some measure.

Disclosure: we build repowise. Every measured number below comes from one public benchmark run on the same repositories in August 2026 (CodeGraph 1.5.0, Graphify 0.9.31, Serena 1.6.2.dev0). Tool facts are as of October 2026, from each project's own repository.

Serena vs Graphify vs CodeGraph vs repowise at a glance

Sources: Serena, Graphify, CodeGraph.

What each tool does well

Serena gives the agent the engines your editor uses for go-to-definition and rename. Because it stores no index, nothing goes stale, and its tools (find symbol, find references, replace symbol body) suit agents that edit a lot. Broad questions take many small lookups, so it made more tool calls than a bare agent in our run.

Graphify parses code with tree-sitter, with no model calls for code, and can add Markdown, PDFs and images through your assistant's model. It writes graph.html, GRAPH_REPORT.md and graph.json, so the graph is something a team browses as well as something an agent queries. It is the most-starred of the four (about 126,000 GitHub stars, against Serena's 30,000).

CodeGraph keeps a symbol and call graph in SQLite, with a file watcher to stay current, and exposes essentially one tool. That keeps its schema small and its answers cheap, and it was the second most-called tool in our Claude Code runs.

What repowise adds

repowise builds the same kind of call graph, then mines git history (hotspots, owners, files that change together), writes a page per module, extracts architectural decisions, scores code health and builds search embeddings. Agents reach all of it through ten tools such as get_overview, get_context, get_risk, get_why and get_answer.

repowise architecture map of the repowise repository, showing modules as clusters joined by weighted dependency edges

The architecture map repowise builds from the call graph, shown for the repowise repository: modules as clusters, import weight as edge width.

Agent loop: tokens and tool calls

We ran each tool against the same django questions with a freshly built index on one pinned commit and byte-identical prompts, plus a bare agent as the control. On Codex every tool was called on every question, so the comparison is like for like. repowise cut output tokens by 31.6% and CodeGraph by 24.4%; more than one tool in this group works well.

Every question in django's question set, six arms, byte-identical prompts, each tool's full advertised surface, and a freshly built index on the same pinned commit. Every tool was called on every question, so this is like for like.

Codex (gpt-5.6-sol) on django/django at one pinned commit. Correcting for testing five tools at once, three reductions are solid and two are marginal. 5 of the 48 questions are missing from every arm equally because the run hit an API usage cap, so the figures are over the 43 questions all six arms completed; because all arms lost the same 5, the paired comparisons are unaffected.

On Claude Code the result depends on whether the agent chooses to call the tool at all. Output tokens fell 15.9% for repowise, and adoption varied from day to day (15 of 15, then 4 of 15, then 3 of 15 across three identical runs). Treat any adoption number as a fact about one harness on one day, and add a line to CLAUDE.md saying when to use the tool.

Retrieval: finding the right files

Graphify, CodeGraph and repowise were also tested on ContextBench: a real GitHub issue goes in, and the score is how many of the files the actual fix touched come back. Grading is deterministic, with no model as judge. Serena was not run because it stores nothing to retrieve from.

repowise get_answer reached 0.876 coverage on 42 instances sealed before any work began, and search_codebase reached 0.742 with 8.2 files per question. Head to head against CodeGraph, get_answer went 19 wins, 1 loss, 22 ties.

File coverage on 42 ContextBench instances pinned before any of this work started and kept sealed until the final measurement. Grading is deterministic and no LLM judge is involved.

n = 42 sealed instances (41 for cocoindex, measured 2026-08-09 on the same instances and grading; one instance never answered and is excluded, not scored zero). Head to head against CodeGraph, get_answer wins 19, loses 1, ties 22, sign test p = 0.00004. The pooled 112-instance figure would be 0.835 and is deliberately not quoted: averaging the halves loses the only number that matters, which is how the tool does on instances it has never seen.

Coverage alone rewards returning more files, so read the files-served column beside it. Our first run of this benchmark scored 0.228; the cause was query-time shortcuts that returned early, which we fixed in ordinary releases. The full account is in we benchmarked ourselves and came last.

Call-graph accuracy

A call graph is only useful if its edges are real. We graded each tool's call edges against compiler-produced graphs, as precision (how many edges are correct) and recall (how many real edges were found). Serena is absent because it asks language servers at query time and stores no graph to grade.

Precision / recall against call graphs generated by the Go and TypeScript toolchains. Both numbers must be read together.

Precision / recall in every cell. Five tools, seven cells, 37,853 oracle edges. No tool that finds as much of the graph as Repowise gets more of it right in any cell. Repowise does not lead recall in the five Go cells and is most precise outright in only one cell.

Build cost

CodeGraph builds a call graph in seconds. repowise indexes django in 366.8s because the same pass also mines git history, extracts decisions and scores health, which makes it 22x CodeGraph's time like for like. Graph-only construction across 35 repositories:

Graph construction only across the same 35 repositories. Three timed runs per cell after a discarded warmup; 175 cells and no failures.

Memory is a clean sweep: Repowise is lowest on 35 of 35 repositories. Speed is level, not a win; CodeGraph is fastest on 16 repositories and Repowise on 14. Repowise builds this arm in memory without serialization, while CodeGraph writes SQLite.

All three indexers update after edits: CodeGraph with a file watcher, Graphify with a git hook or --watch, and repowise incrementally.

Which one to pick

• Pick Serena if your agent edits a lot of code and you want IDE-grade symbol operations with nothing to rebuild.
• Pick Graphify if you want a graph you can open, explore and share, with docs and PDFs in the same graph.
• Pick CodeGraph if a fast local call graph and a build measured in seconds is what you need.
• Pick repowise if agent questions are about history and risk as much as structure (who owns this, what changes with it, why is it built this way, what is safe to delete), or if you want one index in Claude.ai, ChatGPT, Cursor and Claude Code over hosted MCP.
• Use two together when edits and broad questions both matter: Serena for edits, one graph tool for orientation.

Our compare pages go through each pairing: CodeGraph, Serena and Graphify.

Try it on your own repo

pip install repowise
cd your-repo
repowise init

Point your agent at repowise, ask one structural question and one history question, and run the same two through the tool you use today. Raw data from our runs, including invalidated ones, is on the benchmarks page.

How we measured

Agent loop: django/django at one pinned commit, Codex on the questions all arms completed, Claude Code on a smaller set. Retrieval: ContextBench, 42 sealed Python and Go instances. Call graph: compiler output as ground truth. Index time: django on one machine. Each competitor was set up from its own docs; Serena needs explicit project activation, which we did. The agent loop covers one repository and short questions, retrieval measures finding the right files rather than writing a better fix, and all four projects ship often.