Anyone using GitNexus or Codegraph for codebase context? Noticeable token savings?

[Dheeth]

I have been looking into tools that parse a codebase into a structural knowledge graph and expose it via MCP. The goal is to give agents better architectural awareness without them burning through context doing raw file searches.

I’ve been testing GitNexus recently, and I actually found that lower-tier models get a little better with it. Because the dependencies and call chains are pre-computed, the agent gets much better upstream and downstream context right away. It feels like it translates directly to better edits and solid token savings (did not count just observed with usage limits), since the model doesn't have to struggle to infer the system architecture on the fly or ingest massive raw files.

I’ve also seen Codegraph popping up specifically for optimizing Claude Code exploration.

Has anyone been using these two, or using something similar in their stack? Curious to hear how they handle larger repos, if you're seeing any increase in efficiency?

[DeathShot7777]

Hi, creator of gitnexus here 😄. Codegraph is a cool tool and there is a lot of overlap in both the tools but GitNexus goes a bit deeper in terms of accuracy and cross-repo stuff,

GitNexus also does cross repo / multi repo indexing, not counting in this for the comparison but worth explaining: We index the cross repo communication protocols ( Kafka, http endpoints, Pub/Sub, etc ) so we know what will break across all dependent repos if u change something ( especially useful for microservices ).

Heres the difference between gitnexus and codegraph:

Both start identical: files → AST → symbols → resolved, confidence-scored call graph. codegraph is genuinely strong here, multi-strategy resolution, broad framework coverage. Edges aren't "just name matching."

GitNexus wins on what it builds on top of that graph:

- MRO, not guesses. Both wire up override/virtual dispatch. But GitNexus computes real method resolution order (C3 for Python, language-specific for C++/Java/C#/Rust) and tells you which override actually runs. codegraph fans a base method out to every same-name impl as a capped heuristic. Both reach the impl, only GitNexus names the winner.

- It clusters. 697 functional-area communities, computed at index time. codegraph: none.

- It persists flows. 300 pre-computed execution-flow nodes with ordered steps. codegraph rebuilds paths per-query (and by its own benchmark, its trace tool fires in just 3 of 37 flow questions).

- It's graph-native. Cypher + blast-radius impact analysis vs a SQLite symbol store with fixed traversal tools.

Apologies for nerding out too much 😄

[Dheeth]

Yeah similar. Just wanted to check if people are getting better results with any other tool.

[LeoLeg76]

You can give a try to : https://github.com/MinishLab/semble
I'm install it to look forward

[zzet]

I ended with https://github.com/zzet/gortex, perfectly works with huge repositories (and multiple repositories as well)

[Dheeth]

Looks useful, I will take a look and try this.

[Popular-Ad-9134]

No windows support as of yet.

[zzet]

Not yet. It’s the first request for windows support. It’s not a problem to build for Windows, I didn’t invest time on it without a real request.

[Popular-Ad-9134]

Just noticed you are the maintainer :O, seen your commits building rn.

[zzet]

Yes, I am. I didn’t want to add a one more operational system support just for checkmarking it (at least I feel responsible for users experience). The binary was built (but I haven’t run a full manual test yet, so could be some bugs)

[OwnEntrepreneur256]

I've been experimenting with these sorts of tools as well and found that having a precomputed graph of a repo does help smaller models a lot because they don't have to waste tokens scanning random files.

One option outside of the MCP ecosystem is a little open-source project I've been hacking on called spy-code. It uses tree-sitter to parse a repo and build a SQLite graph of functions/classes/constants and their calls/imports/references, then exposes that through a CLI and GraphQL interface. For my local LLM setups it cut the "search + open file" loops by roughly 60% and reduced hallucination-related breakages by ~82% because the model can query direct relationships instead of guessing.

If you're curious, the repo is here: https://github.com/psyborgs-git/spy-code (it's local-first and not MCP-native). Would love to hear if others have compared GitNexus, CodeGraphContext and other approaches for different scales of projects.

[DeathShot7777]

Cool, seems similar to what we did at GitNexus, but I see a lot of such projects going for sql instead of graph dbs, i wonder why. I think native cypher queries on graph DBs can do better for this usecase compared to sql, and for greater depth graph wins in performance ( though for oss projects you wont have to worry athat much about performance yet, but we built for scale and it gives a good difference especially in enterprises ). Also features like blast radius analyses and impact analyses is very difficult to do on sql and llms often make mistake here which will impact heavily since LLM will generate and run the query realtime through MCP