sysevol-ai/CodeNib: a local symbol graph your agent cites by file and line

The product path and the experiment are separate things

The headline number and the shipping feature are not the same system, and the README repeats the separation because it is easy to conflate them. At the top: 71.4% code-block Recall@5 on 100 real issues, and a model-planned grep to Jev route adding 12.8 percentage points over the same grep candidates without reranking, labelled an experimental result with a link to its method and limitations. What installs is something else: local search plus a typed symbol graph, connected to your installed agent clients, needing no model, API key or GPU because your agent uses its own model. The optional grep-to-Jev route exists in 0.2.4, uses OpenRouter for planning and reranking, sends selected code to remote models, and keeps authorization previews opt-in. Decide which one you are evaluating before you read any percentage.

Two tool names carry the navigation work

What an agent can ask is the point of comparison, and two names do most of the work. `explore_context` accepts a request in plain language and returns ranked source anchors with file and line references, which is what lets an answer cite evidence rather than paraphrase it. `dependency_subgraph` walks callers and callees in one call, with depth capped at 8, so a multi-hop question does not need to be decomposed into a chain of single-hop questions. The relationships behind both are resolved by SCIP and LSP indexers, which means compiler-resolved rather than text-matched. The workflow the README describes is to retrieve bounded context first, then follow callers, callees, definitions and references from what came back, so the graph is used to expand a retrieved answer rather than to search blindly for a symbol you already had to name.

The comparison is against local tools, checked on 2026-09-28

The capability table is dated, which is the right thing for a comparison to be, and it compares capabilities rather than benchmark scores. Against grep and read, the difference is that a plain-language question is not answerable and relationships beyond one hop do not exist, since matching is textual. Serena needs a symbol name or regex and returns one level per call, resolved by a live language server or IDE. The other CodeGraph, from colbymchenry, does take plain language through FTS5 full-text search and returns call paths, but resolves relationships by tree-sitter AST extraction and carries telemetry with an opt-out. DeepWiki's public MCP answers plain-language questions from a generated Wiki and runs hosted, with no structured graph tools at all. Four of the five run locally, and the README states that none of them needs its own model or API key.

Fourteen language entries, twelve with graph backends

The registry tracks 14 language entries, of which 12 have graph backends: Python, Go, Rust, C/C++, C#, Java, Ruby, PHP, Kotlin, Scala, JavaScript and TypeScript. Swift and Lua are listed with chunking and retrieval support only, which is a different tier rather than a smaller version of the same thing. Provider prerequisites and coverage differ by language, which is why a generated language matrix exists: it separates chunking, graph backends, incremental-backend support and decoder parity instead of collapsing them into a single supported flag. The honest limitation is stated in the same paragraph. The product currently reuses or rebuilds views, and file-level delta repair is not enabled, so a large edit invalidates more than strictly necessary rather than patching files individually.

The wheel build fails if the Wiki frontend is missing

setup.py is short and does one unusual thing: it makes the Python build depend on a JavaScript build. A custom build_py command stages the prebuilt Wiki frontend into the package, and if web/dist/index.html is not present it raises a RuntimeError telling you to run `cd web && npm ci && npm run build` before building the wheel. So a source build that skips the frontend fails with an instruction rather than shipping an empty panel. The same file declares an optional extension, workspace_owner, built from native/workspace_owner.c with Py_LIMITED_API set to 0x030A0000 and py_limited_api enabled, and the bdist_wheel option pins the same limited API for cp310. The result is a cp310-tagged wheel that can be installed on later Python versions.

One Makefile pins a toolchain per language

The build surface is a Makefile that keeps state under ~/.codenib, with separate directories for prebuilt assets, results and SCIP tools, and a companion setup-scip.sh. Every language backend arrives as a pinned version rather than a floating download: Go 1.26.4 with scip-go v0.2.7 and gopls v0.22.0, a Rust nightly-2026-02-22 toolchain, scip-clang v0.4.0, scip-python 0.6.6, scip-typescript 0.4.0 with TypeScript 6.0.3 and Yarn 1.22.22, basedpyright 1.39.8 and ty 0.0.51, pybind11 3.0.4, scip-java 0.12.3 with Gradle 8.14.2 and sbt 1.12.12, dotnet channels 8.0 and 10.0 with scip-dotnet 0.2.14 and a C# language server at 0.25.0, Bundler 2.6.9 with scip-ruby 0.4.7 writing into a per-project .codenib directory, scip-php pinned to davidrjenni/scip-php:0.0.2 with Composer 2, and OpenJDK 21 with OpenJDK 11 kept for compatibility.

Three entry points ship from the same package

pyproject.toml declares four console scripts: `codenib` bound to codenib.cli:main, `codenib-mcp` bound to an optional entry point, `codenib-web` for the web app, and a codenib-lsp-provider. The quickstart installs the extras rather than the bare package, then runs `codenib codegraph init` against a repository path.

python -m pip install "codenib[graph,mcp]"
codenib codegraph init /path/to/your/repo

That path needs Python 3.10 or newer, Git, a clean repository, and Claude Code or Codex already installed. Runtime dependencies are modest and mostly parsing and serving: fastapi, uvicorn, pydantic, filelock, pyyaml, rich, regex, rank_bm25, tree-sitter and tree-sitter-language-pack, the last of which is pinned below 1.9.0. The floor is Python 3.10, classifiers run through 3.14, the operating system is independent, and the development status is recorded as 4 - Beta, matching the README's own note that public interfaces may change before a stable release. Tags v0.2.4, v0.2.3 and v0.2.2 landed in September and August 2026.

Reproductions are pinned, and compatibility is not a score

The results table is built to be inspected rather than believed. The grep-to-Jev entry exposes a 100-issue retrieval comparison with candidate controls, model use and limitations. The agent integration matrix pins revisions for LocAgent, Agentless, CoSIL, OrcaLoca and RepoNavigator, with an explicit warning that compatibility does not imply reproduced paper scores, which is the sentence that stops the table from being read as a leaderboard. Dataset support covers CodeNib Base and Synthesis, SWE-bench variants, Loc-Bench and SWE-Explore. The SWE-Explore validation reports 1,020 of 1,020 real-output metric cells matching the pinned official evaluator on a fixed 20-case run. The DGX Spark entry is described as a deployment guide, not a token-saving benchmark. The examples/ directory matches that posture, carrying BM25, embedding and graph retrieval baselines next to the rerank scripts and a licensed selected_instance.csv.

Editorial conclusion

CodeNib fits a team whose agent needs compiler-resolved navigation rather than regex hits, and whose repositories are large enough that bounded, cited context beats reading files. Two things to settle first. Decide whether you want the model-free product path, where nothing leaves the machine, or the optional grep-to-Jev route, which plans and reranks through OpenRouter and sends selected code to remote models. Then check your language against the matrix, since twelve entries have graph backends and two, Swift and Lua, stop at chunking and retrieval, and file-level delta repair is not enabled. The package is at 0.2.4 and classified as beta.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes