# zzet/gortex: a graph code-intelligence engine for AI coding agents

> Gortex indexes repositories into a persistent knowledge graph and exposes it over MCP, CLI and HTTP. It is built for teams whose agents burn context on file reads, and it is not a linter or a type checker.

**zzet/gortex** — High-performance code-intelligence engine for AI agents and IDE, supports 257 languages, multi repositories, based on graph, with access via CLI, MCP Server, and API. AI coding agents teammate - expose only needed information, cutting token usage up to 50x. 100% local. Discord:.

- Repository: https://github.com/zzet/gortex
- Website: https://gortex.dev/
- Stars: 1,779 · Forks: 164
- Language: Go
- License: Apache-2.0
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/zzet-gortex

## The context budget problem gortex is aimed at

The failure mode gortex targets is not bad code search. It is that an agent answering "what breaks if I change this function signature?" has no cheap way to ask that question, so it reads files. A 500-line file costs tokens whether or not the answer is in it, and a call chain that crosses four files costs four reads. The README frames the pitch as agents reading "just what they need", and claims up to 50x fewer tokens per response, with reproducible benchmarks in BENCHMARK.md. Treat that number as a claim with a methodology attached, not a constant. It will depend on how much of your repository is reachable by the graph and how the agent was reading files before.

The intended user is a team running a coding agent against more than one repository. Multi-repo is the default here, not a plugin: the README describes N repos in one graph, with call chains and HTTP contracts resolved across repository boundaries. That is a specific shape of user. A solo developer with one small project will not feel the problem this solves, because a whole-repo read is already cheap.

## From tree-sitter ASTs to a provenance-tiered graph

The pipeline has four visible stages. Parsing uses tree-sitter grammars for 257 languages, with three tiers: bespoke tree-sitter grammars, regex fallbacks, and forest-backed signatures. go.mod shows the grammar set as one module per language from go-sitter-forest, which is how the count gets that high without vendoring a C toolchain. Second, resolvers run in-process and are described as compiler-grade for Python, TypeScript/JavaScript, PHP, C#, Go, C, C++, Java, Kotlin, Swift, Zig, Rust, Ruby, Elixir, OCaml and Haskell. Third, the result is written to a persistent, provenance-tiered knowledge graph of functions, classes, call chains, HTTP routes and cross-service contracts, stored on disk in SQLite. Fourth, that graph is served over MCP, CLI and a versioned /v1 HTTP API.

The provenance tiering is the part worth understanding before you trust an answer. A call edge resolved by a real resolver and an edge inferred from a regex tier are not the same evidence, and the README says the graph carries a confidence model. The practical consequence: on a language outside the compiler-grade list, expect lower-confidence edges, and expect blast-radius queries to be correspondingly weaker. The documentation does not publish per-language accuracy figures, so that boundary has to be found on your own codebase.

Blast-radius queries are answered from a precomputed depth-3 reach index rather than a graph walk at query time, which the README describes as turning them into O(seeds x reach) map lookups. That is the mechanism behind "safe to ask on every edit". It is also a constraint: reach is precomputed to a fixed depth.

## Installing gortex and wiring it into an agent

The README gives a one-line installer for macOS and Linux that detects OS and architecture, verifies SHA256 plus cosign, and installs to PATH. Re-running it upgrades in place. Windows uses a PowerShell installer, and Homebrew, .deb/.rpm/.apk, scoop and from-source builds are documented in docs/installation.md.

```bash
curl -fsSL https://get.gortex.dev | sh
```

After the binary is on PATH, the quick start is four commands. The first is a one-time machine setup that writes MCP configuration, skills and slash commands for every coding assistant it detects, which the README says covers 19 agents out of the box.

```bash
gortex install
gortex daemon start --detach
gortex track ~/projects/myapp
```

The daemon is the long-lived process that holds the graph store, watches the filesystem with fsnotify and serves every IDE window, so it is started once in the background rather than per project. gortex track registers a repository with that daemon. Then, from inside the repository, per-repo state is written:

```bash
cd ~/projects/myapp && gortex init
```

The README states that gortex init produces .mcp.json, hooks and community routing for that repository. After that, the assistant queries the graph instead of reading files. The repository also ships a .gortex.yaml at its root as an example of project configuration. If you want to check what the daemon is doing before you trust it with a large monorepo, docs/onboarding.md is described as a 15-minute walkthrough, and docs/cli.md as the complete CLI reference.

## Where gortex is the wrong tool

Gortex is not a compiler. The compiler-grade resolvers cover a named list of languages, and everything else falls back to regex or signature tiers. If you need a type checker's answer about an overload set in a language outside that list, this is the wrong layer, and adding it will not fix that.

Second, the architecture assumes a long-lived daemon. One process serves every IDE window, holds a SQLite graph store on disk and watches the filesystem. That is efficient on a developer laptop and awkward in environments where background processes are not permitted, where the filesystem is not local, or where each CI job would have to start, index and tear down its own daemon. The README does not document rollback or downgrade behaviour for the installed binary, and it does not describe what happens when the on-disk graph store is corrupted; those are the operational gaps to probe before a fleet-wide rollout.

Third, the token-saving claim is conditional on how your agent was reading code before. An agent that already uses LSP or a symbol index is not reading whole files, so the 50x figure will not transfer. The benchmark methodology is published in BENCHMARK.md and BENCHMARK-SWE.md; read the setup before quoting the number internally.

Finally, breadth has a cost. 257 grammars and 175 configurable MCP tools mean a lot of surface. The README says to use only the tools you need, which is a hint that exposing all of them to a model has its own context price.

## How gortex differs from LSP servers and Sourcegraph

The closest functional neighbour is a language server. An LSP server answers editor questions about one language in one workspace, live, with compiler-grade accuracy, and it is driven by the editor. Gortex answers cross-language, cross-repository graph questions and is driven by an agent over MCP. The README links docs/lsp.md, which describes using LSP as an enhancement to resolution rather than replacing it. So the honest split is: LSP for exactness inside one language, gortex for reach across many repositories and for blast-radius queries an editor would never ask.

The other comparison is a code search and navigation platform such as Sourcegraph, which indexes repositories and serves search plus code intelligence through a server. The difference in approach is where the intelligence lives. Sourcegraph is a service you host and query; gortex is a single static binary with an embedded SQLite store and no external dependency chain, and it also pushes editor overlays, so unsaved buffers become a shadow graph that tools read through. That overlay feature is the clearest technical distinction: an LSP-backed or search-backed index generally sees what is on disk. The trade-off is that gortex is per-machine and local by default, so it does not give you a shared index across a team the way a hosted platform does.

## Licence, telemetry and the cost of upgrades

The project is Apache-2.0, with LICENSE.md, NOTICE and THIRD_PARTY_NOTICES.md in the repository root. Apache-2.0 permits commercial use and modification and includes an explicit patent grant; the practical obligation is preserving notices and stating changes. The bundled GloVe-50d embedding file and the grammar modules carry their own upstream licences, which is what THIRD_PARTY_NOTICES.md is for. Read that file before shipping a modified binary. Nothing here is legal advice.

Telemetry is off by default. The README states that nothing is transmitted unless you configure an endpoint, that the payload is anonymous tool and command counts with no code, paths, names or exact counts, and that the DO_NOT_TRACK environment variable is honoured. The control is gortex telemetry on|off|status. For teams with a data-egress review, that default is the difference between a trial and a procurement ticket.

Upgrade cost is low by design: re-running the install script upgrades in place, and the release cadence is fast, with v0.63.8 on 2026-08-20 following v0.63.7 the same day. Fast patch releases on a 0.x version mean the CLI and MCP tool surface can still move, so pin a version in CI rather than tracking latest. The last push to main was on 2026-08-20.

## Conclusion

Adopt gortex if your agents already work in a multi-repo codebase and you want symbol-level answers instead of whole-file reads; the single static binary and the default-off telemetry make it easy to try without a data-egress review. Skip it if your work is greenfield single-repo editing, if you need a compiler-accurate type checker, or if you cannot run a long-lived background daemon on developer machines. Before rolling it out, verify one thing on your own code: run gortex init in a repository whose language is not in the compiler-grade resolver list, then ask a call-chain or blast-radius question and check whether the provenance tiers in the answer are good enough for the decisions your agents make.

## FAQ

### What exactly is zzet/gortex?

It is a code-intelligence engine that parses repositories into a persistent knowledge graph of functions, classes, call chains, HTTP routes and cross-service contracts, then exposes that graph to AI coding agents through an MCP server, a CLI and an HTTP API. It ships as a single static binary for macOS, Linux and Windows.

### Does gortex send my source code anywhere?

No. The README states that the engine is 100% local with everything in-process, and that telemetry is off by default and transmits anonymous tool and command counts only, with no code, paths, names or exact counts, and only if you configure an endpoint. It also honours DO_NOT_TRACK.

### Which AI coding agents does gortex work with?

The README lists 19 agents supported out of the box, including Claude Code, Cursor, Windsurf, VS Code/Copilot, Continue.dev, Cline, OpenCode, Codex CLI, Gemini CLI, Zed and Aider. The gortex install command configures every assistant it detects on the machine, and docs/agents.md covers the details.

### How do I install gortex on macOS or Linux?

The README gives a one-line installer, curl -fsSL https://get.gortex.dev | sh, which detects OS and architecture, verifies SHA256 and cosign, and installs the binary to PATH. Re-running the same command upgrades an existing install, and Homebrew, .deb/.rpm/.apk and scoop packages are documented in docs/installation.md.

### Which languages does gortex resolve accurately?

Parsing covers 257 languages and grammars through tree-sitter, but compiler-grade resolution is limited to a named list: Python, TypeScript/JavaScript, PHP, C#, Go, C, C++, Java, Kotlin, Swift, Zig, Rust, Ruby, Elixir, OCaml and Haskell. Other languages fall back to regex or forest-backed signature tiers, which the README describes as lower-fidelity tiers.

## Sources

- [Official documentation](https://gortex.dev/)
- [Official README](https://github.com/zzet/gortex#readme)
- [Project repository](https://github.com/zzet/gortex)
- [Release notes](https://github.com/zzet/gortex/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zzet-gortex