# Your AI Coding Agent Is Blind: Gortex Gives It a Map of Your Codebase > Source: > Published: 2026-09-27 12:04:38+00:00 Your AI coding agent reads your codebase like a tourist reads a city: one street at a time, no map, asking for directions after every turn. Every task starts with the same ritual. The agent runs a grep, opens a file, reads 400 lines to find one function, follows an import, opens another file. By the time it writes a line of code, half of your context window is gone, and you are paying for every token of it. A project trending on GitHub right now attacks exactly this problem. It is called [Gortex](https://github.com/zzet/gortex), an open-source code-intelligence engine that indexes a codebase into a persistent knowledge graph and exposes it to AI agents through MCP. Instead of dumping whole files into context, the agent asks the graph for the three functions it actually needs. The project claims up to 50x fewer tokens per response. Full disclosure before we go further: I have not run Gortex on my own projects. Everything here comes from the project's README, its documentation, and its published benchmark tables, which I dug through while the project was trending this week. I will label what is a claim from the project versus what is a structural fact about how this class of tool works. **It parses your code with tree-sitter and stores the result as a graph.** Gortex is a single static binary written in Go, licensed under Apache 2.0, with 1.8k stars and 164 forks at the time of writing. When you point it at a repository, it parses every file through tree-sitter AST analysis and builds a persistent knowledge graph in an on-disk SQLite store: functions, classes, call chains, HTTP routes, and cross-service contracts. No cloud, no model download. The README states the tool is 100% local, and telemetry is off by default. **It supports 257 languages through three parsing tiers.** This is the detail that separates it from the toy versions of this idea. About 30 core languages (Go, Rust, TypeScript, Python, Java, Kotlin, C++, and more) get hand-tuned tree-sitter queries with compiler-grade resolution, listed as Python, TypeScript / JavaScript, PHP, C#, Go, C, C++, Java, Kotlin, Swift, Zig, Rust, Ruby, Elixir, OCaml, and Haskell. Another roughly 60 languages get regex-based scanning, and around 165 more get generic signature-based extraction. That means agents stop hallucinating structure in files a narrower tool would skip. **The agent talks to the graph through MCP.** Gortex ships a long-lived daemon plus an MCP server with 175 configurable tools (the README also references 100+ MCP tools, 16 resources, and 3 prompts, so the tool catalog is large either way). Your agent can ask things like find usages, get callers, get call chains, or blast-radius queries. A precomputed depth-3 reach index turns "what breaks if I change this?" into map lookups instead of a chain of greps. The README claims this is safe to run on every edit. **It handles multiple repos as one graph.** This is the feature I find most interesting for anyone working in a microservice world. Gortex auto-detects API contracts across repositories: HTTP routes (it recognizes framework annotations from gin, Express, FastAPI, and Spring), gRPC services, GraphQL schemas, Kafka and RabbitMQ topics, WebSocket patterns, environment variables, and OpenAPI specs. Contracts are normalized to canonical IDs like `http::GET::/api/users/{id}` and matched across repo boundaries to detect orphan providers, orphan consumers, and mismatches. If you have ever traced which service actually calls which across six repositories, this is that job automated. The following numbers are from the Gortex README and its docs, measured by the project itself. Treat them as the project's claims, not independent measurements. The scale numbers are the most verifiable kind, because you can reproduce them on your own machine: Parsing dominates wall time at 65 to 80 percent, and reference resolution and search-index build scale sub-linearly. Those are plausible numbers for a tree-sitter-based indexer, and the fact that they publish a benchmark harness ([BENCHMARK.md](https://github.com/zzet/gortex/blob/main/BENCHMARK.md)) in the repo is a good sign. On token savings, the project is oddly honest about the limits of its own metric, which deserves credit. The savings ledger: The README shows a cumulative dashboard example: $168.69 of cost avoided on claude-opus-4 across 1,878 calls, 11.2M tokens saved, a 93.3% efficiency ratio. That number is the project's own ledger example, not an audited figure. The structural point stands on its own, though: a graph lookup that returns one function signature is dramatically cheaper than reading the 500-line file around it, and anyone who has watched an agent burn $2 tracing a bug through four files knows the difference is real. The install is deliberately boring. From the README: ``` # macOS / Linux curl -fsSL https://get.gortex.dev | sh # Windows (PowerShell) irm https://get.gortex.dev/install.ps1 | iex ``` The installer detects your OS and architecture, verifies SHA256 and cosign signatures, and installs to PATH. Releases are Sigstore signed with SLSA Level 3 provenance, which is a supply-chain posture most developer tools still lack. Then three commands: ``` gortex install # one-time machine setup (MCP, skills, slash commands) gortex daemon start --detach # background daemon gortex track ~/projects/myapp # add a repo ``` Running `gortex init` inside a repo generates the per-repo config: `.mcp.json`, hooks, and community routing. The project claims `gortex install` configures every detected coding assistant on the machine, with support for 19 to 20 agents out of the box. The README's list includes Claude Code, Cursor, Windsurf, VS Code / Copilot, Codex CLI, Gemini CLI, Zed, Aider, Cline, OpenCode, and Kilo Code. One install, every agent on the machine pointed at the same shared graph, with per-session isolation so two agents do not fight over state. Graph-based code intelligence is not new. Sourcegraph has done code search and navigation for years, and the research side has papers like LocAgent and RANGER building repository-level graphs for agents. What is new in 2026 is the packaging: local-first, single binary, MCP-native, multi-repo, and free. That combination did not exist a year ago, and it explains why this category is suddenly crowded with new entrants on GitHub. A checklist for deciding whether you need one: Three open questions before betting a workflow on this: `gortex install` actually wrote into each tool after running it. The pattern to remember: agents that navigate a graph instead of reading files change the economics of AI coding. The context window is the scarcest resource in your AI workflow, and the tools that win in 2026 are the ones that stop wasting it. Gortex is one implementation, trending this week, but Sourcegraph, the MCP ecosystem, and every serious agent vendor are converging on the same idea. Watch this category, and if you run agent-heavy workflows across multiple repos, it is worth an hour of your time to try one of these engines on your own code. I write about developer tools, AI infrastructure, and backend engineering every week. Subscribe, it is free. Have you tried a code-graph tool with your AI agent, Gortex or otherwise? What did it do to your token bills? Tell me in the comments.