CodeNib speeds coding-agent repo-index updates up to 25x
Coding agents that work inside a codebase have to keep searching, navigating, and re-learning the repository as it changes, but researchers behind a new system called CodeNib argue that today's tooling makes this needlessly expensive: separate lexical indexes, language servers, and task-local histories are disconnected from each other, so agents repeatedly rediscover the same context and the true cost of keeping that context current stays hidden.
CodeNib, described by a team including Zhongming Yu, addresses this by building three kinds of reusable "views" of a repository at each commit: a lexical view, a dense (embedding-based) view, and a structural view. It maps the outputs of these views back to specific, repository-relative source ranges, keeps the selected views updated as the code changes, and serves ranked search, symbol navigation, and bounded context requests through a single runtime rather than several disconnected tools.
The team evaluated the system across 100 repository snapshots to chart the tradeoff between result quality and computational cost throughout a repository's lifecycle. Compared with rebuilding indexes independently from scratch, CodeNib's incremental graph and vector updates were 8.7 times and 25.4 times faster at the median while still matching the rebuilt output. On a subset of navigation requests where CodeNib's static index and normalized live-server results pointed to the same location (63% of 1,000 requests tested), the median request answered by the static index was 4.7 times faster than the equivalent live language-server query. Tested across five different models, agents using CodeNib's selected-context policies kept the same localization accuracy while using 50 to 87 percent fewer trajectory tokens than agents relying on paired grep-and-read searches.
Key facts
- CodeNib builds and maintains lexical, dense, and structural views of a repository at each commit, mapped to specific source ranges, for use by coding agents.
- Incremental graph and vector index updates were 8.7x and 25.4x faster at the median than rebuilding indexes independently, while matching the rebuilt output.
- On the 63% of 1,000 navigation requests where static and live results agreed, the static index answered 4.7x faster at the median than a live language-server query.
- Across five different models, CodeNib's context policies preserved localization accuracy while cutting trajectory tokens by 50 to 87 percent versus grep/read searches.
- The evaluation spans 100 repository snapshots to map quality-cost tradeoffs across the full repository-context lifecycle, not a single benchmark run.
Why it matters
Coding agents spend a large share of their effort just relocating context they have effectively seen before, because indexes, language servers, and per-task histories do not persist or talk to each other across a session or across edits. CodeNib's pitch is a single runtime that keeps per-commit views of a repository current and reusable, so agents stop paying the full discovery cost on every request.
Who it affects
Teams building or operating coding agents and AI developer tools, and anyone maintaining the code-search or context-retrieval layer those agents rely on. The system targets the infrastructure underneath agents rather than end users interacting with a product directly.
How to use it
CodeNib is presented as a research system, a runtime that builds lexical, dense, and structural views per repository commit and serves search, symbol navigation, and bounded context from them. The source text gives no pricing, license, or public release details, only the architecture and its measured performance.
How solid is it
The claims rest on a fairly structured evaluation: 100 repository snapshots to chart quality against cost across the lifecycle, a comparison against independent index rebuilds for the update-speed figures, 1,000 navigation requests for the latency comparison, and five different models for the token-savings result. That is a broader test matrix than a single benchmark, though it is the authors' own measurements rather than independently replicated results.
Risks and caveats
The headline speed figures are medians from the authors' own benchmarks, not third-party verification. The 4.7x latency figure applies only to the 63% of requests where the static index's answer matched a normalized live-server location, not to all navigation queries. The text gives no detail on how CodeNib behaves on repositories with unusually high churn, very large codebases, or languages outside whatever set was tested, and no information on production adoption or maintenance cost of running the system itself.