When a coding agent answers a question about a large repository, most attention goes to the model. In July we showed that a small Qwen model inside the CodeAlive harness can outscore Sonnet. This time we kept the model fixed and changed only the agent around it.
The experiment
We used DeepSeek V4.1 Flash at maximum reasoning effort in every configuration. The questions come from RepoContextBench v2: 20 on Microsoft Agent Framework (about 680K lines, the Lite track) and 20 on Sapling (about 1.6M lines, the Hard track). An LLM judge scores each answer from 0 to 100 against weighted reference claims.
We compared three setups:
- OpenCode, a general-purpose open-source coding agent, with its built-in
read,grep,globandlistover a local checkout. - The same OpenCode with CodeAlive's search, fetch and graph tools connected over MCP, and an
AGENTS.mdthat tells it to use them. - The CodeAlive harness: our own research agent, built for answering questions about code, with the same CodeAlive tools in-process.
Results
With the same model, the harness added 18.7 points overall: 24.7 on Lite and 12.8 on Hard.
It also got there with less work. On the Hard track:
That is 2.5 times fewer tool calls and almost three times less time per task. OpenCode spent its steps grepping and reading whole files. The CodeAlive agent found the relevant symbols through the index and read only those.
On Lite the picture is different: the CodeAlive harness took 50 seconds per task against OpenCode's 42. It did more research on the smaller repository, and the answers were 24.7 points better for it.
Why the tools alone are not enough
The MCP row is the most instructive one. OpenCode received the same CodeAlive tools and used them heavily: on Lite it made 186 CodeAlive grep calls, 112 fetches and 74 semantic searches. Its score rose by 3.7 points, a fraction of what the full harness gained.
The tools are the same. What differs is the loop around them. Our agent starts from semantic search and artifact identifiers instead of walking directories. It reads by symbol: fetch_artifacts returns the function or class it asked for, together with its callers and callees, not a 2,000-line file. Tool results end with next-step hints that tell the model what to do with the result, which matters most for smaller models. Repeated identical calls are caught and redirected before they eat the step budget. And the agent finishes the research explicitly when it has enough evidence, instead of running until a limit.
OpenCode is built to edit code, run commands and read files in one loop. Our harness does one job, finding the right code and answering from it, and its prompt and tools are tuned for that.
Caveats
These are internal diagnostic runs with one run per configuration, not a published leaderboard entry. A repeated identical run moved scores by about ±2 points, well below the differences above. The judge is an LLM with a fixed rubric; the few tasks where the main judge (Muse Spark 1.3) returned no verdict were scored by a backup judge (GPT-5.6 Luna).
If you already use a coding agent, CodeAlive over MCP is the quickest way to give it repository context. In our runs, most of the gain came from handing the research itself to a dedicated agent. What the call graph contributes is covered in GraphRAG for code, and the quality of the graph itself in How accurate are open-source code graph indexers?.