EgentCodePlexus is not a drop-in replacement for GitNexus. Same conceptual model — a structural knowledge graph of a repo — different audience, different runtime, different output discipline. This document explains where the two projects diverge and why.
ecp exists because we wanted to use GitNexus's idea inside autonomous LLM coding workflows, and the original product was built for a different shape of consumer: humans in IDEs and long-running agent platforms with MCP wiring. The differences below are not "Rust is faster" — they are decisions about who the consumer is and what an honest answer to that consumer looks like. Where this file uses numbers, they are current ecp measurements from the repo's own benchmark/docs, not aspirational targets.
| GitNexus | EgentCodePlexus | |
|---|---|---|
| Primary consumer | Human developers + IDE integration | Autonomous AI code agents |
| Interaction loop | Developer reads UI, navigates, refines query | Agent emits a shell call, parses stdout, decides next action |
| Token budget per query | Effectively unbounded (humans skim) | Strict — each token eats the agent's context window |
The audience choice cascades into every other row of this comparison. GitNexus optimises for legibility and ergonomics; ecp optimises for predictable cheap calls that an agent can fire dozens of times per task without warm-up cost.
GitNexus runs as a long-lived MCP server. The graph is held in memory, the server stays warm, MCP tools route through host integrations (Claude Code, Cursor, Windsurf, Cline, Codex). The benefit: rich tool ergonomics, resources, prompts, hooks, generated skills — a full agent platform.
ecp is a stateless one-shot CLI. Every invocation is a fresh process that mmaps a zero-copy rkyv graph file off disk and answers one query. There is no server, no daemon by default, no state to manage between calls.
The tradeoff is real and goes both directions:
- GitNexus wins on rich session-aware features (cross-call memoisation, server-held caches, generated repo skills, MCP resources).
ecpwins on cost-per-call predictability. On the current.sample_repobenchmark, read queries sit in the ~140-170 ms cold band including process startup;summarycan be sub-2 ms because it is mostly registry mmap, while heavier traversals likecypherland around ~160 ms. An agent can fire 30+ queries per task without amortising a warm-up phase. There is no "server died, please restart" failure mode, no port allocation, no state synchronisation.
ecp ships an MCP server too (ecp admin mcp serve), but it is a thin shim over the same one-shot binary, not a fundamentally different runtime.
This is the most important philosophical difference.
When the analyser sees import { X } from 'unresolved-module' or getattr(obj, name)() or a dynamic dispatch site whose target can't be statically determined, the two projects make opposite choices:
GitNexus emits a heuristic-guessed edge (e.g. Jaccard string similarity over candidate names) so the graph stays connected and readable. This is the right call for human consumers — a graph with too many missing edges looks "broken" to a developer skimming a UI.
ecp emits a BlindSpot record, not an edge. The graph admits "I cannot tell what this call resolves to" instead of inventing a likely-wrong answer.
The reason is consumer-specific: an LLM agent acts on what the graph says. If ecp returns a guessed edge with 60% confidence, the agent treats it as a fact and may rewrite, refactor, or generate tests against that wrong target. A hallucinated dependency that an agent then commits is much more expensive than an honest BlindSpot the agent can route around with a clarifying question.
Rule of thumb: if the graph is read by humans who can ignore obvious nonsense, prefer GitNexus's "guess and keep connected." If the graph is read by an agent that will execute downstream actions, prefer
ecp's "I don't know" record.
| GitNexus | EgentCodePlexus | |
|---|---|---|
| Default format | Wiki / UI rendering | TOON (token-optimised) |
| Optional formats | MCP-rich responses, generated skills | --format text|json|toon per command |
| Format goal | Human readability | Bytes-per-fact ratio |
A symbol-context dump in MCP-rich form might be 800 tokens. The same dump in TOON is closer to 200, with no information loss for an agent that knows the schema. Multiplied across the 20–50 queries an agent fires per task, this saves multi-kilobyte chunks of context window per task — which an agent will spend on thinking instead of layout. This is a format choice, not a claim that TOON is universally better for humans.
ecp picks the cheapest format per command as the default: most read commands default to toon; find defaults to plain text (already minimal); cypher and summary default to json (structurally rich, expected to be parsed). Override anywhere with --format.
GitNexus parses 14 languages: TypeScript, JavaScript, Python, Java, Kotlin, C#, Go, Rust, PHP, Ruby, Swift, C, C++, Dart. Each gets the full 9-dimension treatment: imports, named bindings, exports, heritage, types, constructor inference, config, frameworks, entry points.
ecp parses 31: the same 14 plus Bash, Crystal, Cairo, Dockerfile, Docker Compose, GitHub Actions, HCL, Lua, Markdown, Move, Nim, Solidity, SQL, Verilog, Vyper, YAML, Zig.
This is breadth, not parity. The 17 extension languages get structural coverage (functions / classes / methods / imports / calls) but not the full 9-dimension matrix — see language-matrix.md for the per-language scorecard.
The motivation: modern repos are polyglot. A typical SaaS backend has Python service code, TypeScript frontend, SQL migrations, Dockerfiles, GitHub Actions workflows, Terraform (HCL) infrastructure. A Web3 project mixes Solidity, Move, Vyper, Cairo. A systems project mixes Rust, C, Zig, Bash. GitNexus answers structural questions only inside the 14-language code zone; everything else is a black hole. ecp extends the graph into the surrounding DevOps / infra / config / contract zone — still structural, but enough to answer "where does CI invoke this script" or "which contract calls this function" without leaving the tool.
The honest tradeoff: GitNexus knows more about any one of its 14 languages than ecp knows about, say, Bash or YAML. If your repo is monolingual and you need deep semantic analysis (full Heritage chains, Constructor Inference, Framework-specific bindings), GitNexus is the better fit. If your repo is polyglot and you mostly need "what calls what, across whatever languages", ecp is the better fit.
| LLM-facing area | GitNexus | EgentCodePlexus |
|---|---|---|
| Agent integration | MCP server, resources, prompts, setup, hooks, generated skills | Stateless CLI + optional MCP server (ecp admin mcp serve) |
| Core query commands | query, context, impact, detect_changes, rename, cypher, group tools |
inspect, find, impact, routes, cypher, summary, rename, contracts, diff |
| Workflow tools | rich MCP resources, generated repo skills | tool-map (egress calls), shape-check (response-shape drift), review (audit aggregator), peers (multi-session collab) |
| Search | BM25 + semantic + RRF hybrid (documented) | Tantivy BM25 + per-name substring fallback |
| Storage | Node.js + LadybugDB | Rust + rkyv zero-copy mmap |
The command vocabularies have similar shapes but the verbs differ in scope. GitNexus's context is similar to ecp inspect. GitNexus's detect_changes overlaps ecp diff + ecp impact --since. ecp adds workflow-specific verbs that don't have GitNexus equivalents — tool-map (where does my code touch external HTTP/DB/Redis/queue), shape-check (does the HTTP consumer's expected response shape match the producer's actual shape), review (one-shot audit over the change-set). These exist because they are common LLM-agent sub-tasks worth a dedicated verb.
GitNexus uses LadybugDB — a Node.js graph database — which gives it indexed property graph queries, transactions, and durable storage.
ecp stores the graph as a single rkyv-serialised binary file (.ecp/graph.bin) and mmaps it on every command. The on-disk layout is fixed at index time. Queries that need indexes (BM25 lexical search) maintain a separate Tantivy index alongside the graph file.
The tradeoffs:
ecpcannot do mid-graph mutations — every rebuild is a full or incremental re-serialisation. It compensates with an aggressive xxh3_64 content cache so the current.sample_repobenchmark shows a zero-dirty incremental pass at ~4.9 ms, while a cold full index is ~2.60 s.ecphas no concurrency control beyond an OS-level flock. Twoecp admin indexprocesses will serialise.ecpreads are zero-copy. Opening a graph and answering a read query is dominated by process startup, not graph access. On the current benchmark corpus,summaryis ~1.4 ms and heavier reads such ascypherare still in the ~160 ms range cold. This is the property that makes the one-shot-CLI model viable.
LadybugDB is the right pick if you want a persistent, mutable, multi-writer graph backend with rich query planning. rkyv + mmap is the right pick if you want zero-latency reads from a stateless CLI and can accept "regenerate the file" as the write model.
Choose GitNexus if:
- You're integrating into a Node-based agent runtime with strong MCP/editor support
- Your repo is one of the 14 supported languages and you need depth on every dimension
- You want the agent platform features (resources, generated skills, hooks)
- You're a human developer who wants to navigate the graph in a UI, not just programmatically query it
Choose EgentCodePlexus if:
- You're building LLM tooling that wants a small executable with few moving parts
- Your repo is polyglot (DevOps configs, Web3 contracts, infra-as-code, build glue) and you need at least structural visibility everywhere
- You value honest blind-spot records over heuristic-guessed edges (agent will act on the graph)
- You need sub-second per-query latency with no warm-up cost (agent fires many queries per task)
- You're shell-mediating an LLM and want token-cheap output (TOON / compact JSON)
The two are not mutually exclusive. Several teams run GitNexus as the human-facing MCP server and ecp as the agent-facing shell tool over the same repo — different consumers, different surfaces.
ecp is an independent Rust project inspired by GitNexus. The structural-graph concept and CLI surface were originated by Abhigyan Patwari; ecp is an independent reimplementation that reuses no GitNexus source code. ecp is not affiliated with or endorsed by the GitNexus project. See NOTICES.md for the full third-party attribution list.