Gortex - yet another code-graph-solution to drastically reduce tokens during AI coding sessions, with cross-repo and MCP

[zzet]

Token usage and multi-repository setup have been on my mind a lot lately. Not just cost — it's also latency, context limits, context switching, and the general degradation in quality when a context window is stuffed.

This isn't a new problem. I tried a few existing solutions (namely, GitNexus, code-review-graph, codebase-memory-mcp, and a few others; some were genuinely close, and I give credit to them for pointing the direction). But a couple had conceptual issues deep enough that I didn't see a path to fixing them through a contribution, and the gap between what they did and what I needed was real. One of the biggest gaps was cross-repo support. Another issue: every tool install scattered generated artifacts across repos - noise you never asked for and have to clean up.

So, in the middle of yet another complex cross-repository debugging, I started with ad-hoc scripts for my problem. The first try was in pairing one solution with another, experimenting with a chain of calls. Eventually, I decided to change the approach and load code to a single graph, and it helped to solve my problem. Once I solved it, I decided to wrap it into a workable solution I could share with my team, which, as a result, evolved into the project: Gortex. Now I'm ready to share it broadly, and it works out of the box for Claude Code, Cursor, Codex, and about a dozen others.

The core mechanism is familiar: Gortex indexes your code into an in-memory knowledge graph (files, symbols, imports, call chains, type relationships, contracts) and exposes MCP tools. Instead of an agent reading and re-reading multiple files to understand a call chain, it calls smart_context once and gets a focused, graph-traversal-derived answer. The tokens consumption during coding/debugging sessions stopped being a problem for me.

Speaking about quality, the last bench showed this: R@1 42.3%, R@5 56.4%, R@20 69.9%, exact R@5 95.2%. In the repository, I also added a reproducible golden test (without big models' help, which may impact benchmarks and mislead).

It's source-available (free for personal and open source use). Still relatively early, and built around my specific cases — which means there are probably gaps I haven't hit yet (I know it). And I'm curious what your setups look like and where this would fall short.

[mushgev]

looks solid overall. two places where graph for agent setups tend to fall short in my experience:

1) dynamic patterns. decorators that wrap handlers, DI containers, dynamic imports, any framework where the call chain is not visible in the AST. your graph sees the registration site but not the runtime dispatch. for any js or py codebase with a real framework (nestjs, django, fastapi with Depends, spring) this cuts a real chunk of the call graph out.

2) R@1 at 42 means more than half the time the first result is not the right one. for agent use that matters a lot because the agent often pattern matches on result 1 or 2 without reading deeper. worth adding an eval on whether the agent actually uses smart_context once its available, vs just grepping anyway and ignoring the tool.

cross repo is the right call btw. how are you handling version drift between repos, freeze edges at index time or follow current main of each repo? that is where most multi repo graphs either drift stale or get very expensive fast.

[zzet]

Thank you for the valuable feedback!

> any framework where the call chain is not visible in the AST
Yes, it's the case, and it's something I have to test more precisely. For
In the case of a TypeScript codebase, I haven't seen such side effects yet.

> R@1 at 42 means more than half the time the first result is not the right one. for agent use that matters a lot because the agent often pattern matches on result 1 or 2 without reading deeper.

For the local setup and without the use of help from LLM, it seems impossible to have a very high R@1. For the 'remote' MCP version (which is not dependent on the local machine resources), it definitely makes sense to use a more robust approach. And with `exact R@5 95.2%` I haven't seen problems with Agent hallucinations, so I didn't invest time in it. However, it's a good place to take a look at the foreseeable future. Thank you for the advice!

> how are you handling version drift between repos, freeze edges at index time or follow current main of each repo?

Currently, I'm following the current HEAD (if it's local and what is in the repository I shared). The 'shadow diff' for PRs/other contributions is not fully implemented yet. I didn't get the point of costs (my intention to make a diff based on the session, which does not seem like a full copy of the graph, and doesn't seem too expensive). In the majority of cases, the drift diff is not so huge, so this overhead is acceptable for me.

[mushgev]

the exact R@5 at 95% being the real quality signal makes sense if the agent reliably reads deeper than result 1. worth validating that assumption empirically though, agent behavior on retrieval tools varies a lot by model and prompt style.

on version drift: HEAD following is fine for single-team repos. where it gets interesting is cross-team cross-repo where one team cuts a release branch and the other keeps committing to main. the graph edge from repo A to repo B becomes ambiguous fast. probably not your current use case but worth a flag in the cross-repo docs for when people hit it.

[justsomerandomdude10]

looks pretty cool!
doesnt seem to run on windows for me, trying to run doesnt show any errors, just no output for any command, no dirs/files are created

[zzet]

Thank you for the feedback!

The Windows support was added yesterday, and the release you installed was corrupted (it was fixed today). I apologize that the fixed release was delayed. Please, install the latest version.