Gortex: A local graph engine that cuts AI agent token use by indexing code, not reading files

The problem: agents read too much code

AI coding agents waste context by reading entire files when they only need a function signature or a call site. A 500-line file consumes tokens even if the agent only needs one symbol. Gortex addresses this by indexing code into a graph and exposing only the relevant nodes. The README claims up to 50x fewer tokens per response, a figure backed by a reproducible benchmark file. This matters for anyone using agents like Claude Code, Cursor, or Copilot, where context windows fill quickly and costs scale with token usage. The tool is for developers who want their agents to ask for specific graph queries instead of raw file contents.

How the graph is built: tree-sitter and compiler-grade resolvers

Gortex parses code using tree-sitter ASTs for 257 languages. The documentation describes three tiers: bespoke tree-sitter, regex, and forest-backed signatures, plus support for Jupyter and Databricks notebooks. For a subset of languages, including Python, TypeScript, Go, Rust, and C++, it uses in-process resolvers enhanced with 'compiler-grade resolution.' The result is a persistent, provenance-tiered knowledge graph containing functions, classes, call chains, HTTP routes, and cross-service contracts. The graph is stored in an on-disk SQLite store, and a long-living daemon serves it to all IDE windows. This architecture allows blast-radius queries to run as O(seeds × reach) map lookups, thanks to a precomputed depth-3 reach index. The design is fundamentally different from file-based retrieval: you query relationships, not text.

Installation and first run: commands that work

Installation uses a curl script on macOS and Linux, or a PowerShell command on Windows. The README shows: `curl -fsSL https://get.gortex.dev | sh`. The installer detects the OS and architecture, verifies SHA256 and cosign signatures, and installs to PATH. After installation, the quick start is four commands: `gortex install` for machine setup, `gortex daemon start --detach` to run the background daemon, `gortex track ~/projects/myapp` to add a repository, and `gortex init` inside the repo to generate `.mcp.json` and hooks. The daemon is long-living and uses fsnotify for live file watching. The README mentions a 15-minute onboarding walkthrough. The single static binary for macOS, Linux, and Windows means no dependency chain, which is a genuine advantage for teams that avoid runtime installs.

The MCP surface: 175 tools, but configurable

Gortex exposes between 100 and 175 MCP tools, depending on configuration. The README lists symbol lookup, call chains, blast radius, dataflow, clone detection, and refactoring tools. It also provides 16 resources and 3 prompts. The key design choice is that tools are configurable: you 'use only what you need,' which keeps the agent's tool list manageable. The MCP server supports 2026 Streamable HTTP, and the project integrates with 19 coding agents out of the box. A single `gortex init` command configures every detected assistant on the machine. This is a practical approach, but the sheer number of tools can be overwhelming if you do not curate them. The documentation suggests you can disable unused tools, but the README does not show the exact configuration key.

Token savings: the 50x claim and the wire format

The headline claim is up to 50x fewer tokens per response. The mechanism is graph-native lookups: agents receive only the relevant nodes, not the surrounding file. The README also describes the GCX1 wire format, a published, round-trippable binary format that claims an additional 27% token reduction compared to JSON at the same fidelity. The benchmark file is reproducible, which is a point in favor of the claim, but the actual savings depend on your repository size and how you query. If you ask for a whole file, you will not see savings. The claim is specific to graph queries. The README does not provide benchmark numbers, so you cannot verify the exact reduction without running the benchmark yourself.

Cross-repo contracts and multi-repo analysis

Gortex supports multiple repositories in a single graph by default. The README describes auto-detection of API contracts across repos, matching providers to consumers. Contract types include HTTP routes from framework annotations like gin, Express, FastAPI, and Spring. The `contracts` MCP tool and the web UI Contracts page surface these matches. The graph also includes call chains and references that span repository boundaries, with evidence-gated resolution and per-session isolation. This is useful for microservice architectures where a change in one service breaks another. The impact analysis feature answers 'what breaks if I change this?' across repos. The README mentions merge-order conflicts via shared communities in the PR review feature, which suggests the graph supports community detection.

Limitations: where Gortex is the wrong tool

The documentation is honest about some limitations, but not all. The 257 language support includes regex-based tiers, which are less precise than the compiler-grade resolvers. For languages in the regex tier, the graph may miss complex relationships. The README does not list which languages fall into which tier, so you must check the languages documentation. Another limitation: the token savings claim applies to graph queries, not to all agent interactions. If your workflow involves reading large files for context, Gortex will not help. The daemon is long-living, which means it consumes memory and CPU, though the README claims zero external dependencies. The telemetry is off by default, but if you enable it, it sends anonymous tool counts, not code or paths. The README does not mention any failure modes, such as what happens when the SQLite store becomes corrupted or when the daemon crashes.

Alternatives: file-based retrieval vs. graph-based

The main alternative is file-based retrieval, where an agent reads a file or a chunk of a file. Tools like Continue.dev or Cursor's built-in codebase search use embeddings and vector databases to find relevant files, then pass the file content to the model. Gortex differs by storing relationships, not just text. A vector search returns a file that might contain a function, but it does not tell you what that function calls or who calls it. Gortex answers those questions directly. Another alternative is using the language server protocol (LSP) directly for symbol resolution. LSP gives you go-to-definition and find-references, but it is per-file and per-language, and it does not build a persistent graph across repos. Gortex's graph is precomputed, so queries are fast, but the index must be kept up to date with the daemon.

Maintenance and licensing

Gortex is licensed under Apache-2.0, which permits commercial use, modification, and distribution with attribution. The project is actively maintained, with three releases in the last two days as of the last push. The README mentions signed binaries and SLSA build level 3, which is a supply chain security consideration. Upgrading is done by re-running the install script. The project uses a daemon, so upgrades require restarting the daemon. The README does not describe a migration path for the SQLite graph store between versions, which is a potential upgrade cost. The documentation mentions incremental restart, but not schema migrations. You should test an upgrade on a non-critical repository first.

Editorial conclusion

Adopt Gortex if you run AI coding agents that frequently read large files and you want a local, dependency-free way to cut token usage. Skip it if you work primarily with unsupported languages or need real-time accuracy on unsaved buffers without speculative execution. Before adopting, verify that your language's resolution tier matches your needs, test the 50x claim against your own repository, and confirm the MCP tool count you actually use. The project is under active development with frequent releases, so pin a version and review the changelog for breaking changes.

Official sources

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