Your AI coding agent is choking on context bloat. Every time Claude Code, Cursor, or Aider reads a 500-line source file just to inspect a single helper function, your token bill spikes and response latency collapses. Naive file reads force large language models to re-parse noise, hallucinate call sites, and lose context across repository boundaries.

Gortex fundamentally changes this operational pattern. Built in Go (requiring Go 1.26+ and CGO for tree-sitter C bindings), Gortex is a single static binary code-intelligence engine. Instead of dumping raw disk files into prompt context, Gortex parses 257 languages and grammars into an on-disk SQLite knowledge graph. It exposes this graph via a background daemon, CLI, HTTP server (/v1/* endpoints), and MCP Server (Model Context Protocol).

By replacing brute-force file reads with graph-native depth queries, agents retrieve only the exact nodes, references, and cross-repo API contracts they need. The result is a 50x reduction in tokens per response.

+-----------------------------------------------------------------------+
|                             GORTEX BINARY                             |
|                                                                       |
|  CLI (Cobra)  ---> MultiIndexer -------> Graph Store (SQLite)         |
|  MCP (stdio)  ---> Query Engine --------> Repo/Project/Ref Scoping    |
|  HTTP /v1/*   ---> Graph / Events -----> MCP 2026 Streamable HTTP     |
|  Daemon       ---> MultiWatcher --------> Live fsnotify Events        |
|                    CrossRepoResolver ---> Type-Aware Cross-Repo Edges |
+-----------------------------------------------------------------------+

The Structural Core: Go, SQLite, and Tree-Sitter Resolution

Gortex operates as a zero-dependency, long-living daemon that supervises filesystem updates via fsnotify. The engine uses a MultiIndexer pipeline backed by an on-disk SQLite graph store.

Because compiler-grade accuracy requires deterministic syntax processing, Gortex relies on CGO to link tree-sitter C bindings directly in-process. It processes 257 grammars across three distinct resolution tiers:

1. Bespoke Tree-Sitter AST Analysis: Deep syntax parsing with compiler-grade resolution for Go, Python, TypeScript/JavaScript, C, C++, C#, Java, Kotlin, Swift, Zig, Rust, Ruby, Elixir, PHP, OCaml, and Haskell.
2. Regex Patterns: Fallback structural indexing for unparsed text formats.
3. Forest-Backed Signatures: Dynamic resolution across notebook formats like Jupyter and Databricks.

Parsing accounts for 65% to 80% of total wall-time during initial indexing. Reference resolution and search index creation scale sub-linearly.

Precomputed Depth-3 Reach Index

To compute blast radius during code edits, traditional tooling recursively scans directory trees, executing dozens of tool calls. Gortex eliminates this bottleneck by precomputing a depth-3 reach index directly within SQLite. Asking "what breaks if I touch this signature?" converts a dynamic tree traversal into an $O(\text{seeds} \times \text{reach})$ map lookup.

go
// Conceptual reach representation inside Gortex graph engine
type ReachIndex struct {
    SeedNodeID string
    Depth      int
    Targets    []GraphNode
}

For workspace search, Gortex embeds a lightweight 3.8 MB GloVe-50d model directly into the binary. It couples this with store-native FTS5/BM25 and vector search using adaptive alpha fusion, delivering hybrid semantic search without external network calls or local model downloads.

Cross-Repo HTTP Contracts and Routing Resolution

In distributed architectures, services communicate over HTTP endpoints, message queues, and RPC stubs. Single-repo tools fail at service boundaries. Gortex links multiple repositories inside a unified graph, establishing evidence-gated resolution across repo boundaries.

It automatically extracts, matches, and surface API contracts through the contracts MCP tool and the Gortex Web UI.

Contract Type	Detection Method	Provider (Source Node)	Consumer (Target Node)
HTTP Routes	Framework annotations (gin, Express, FastAPI, Spring)	Route Handler	HTTP client calls (fetch, http.Get)
gRPC	Proto service definitions	Service RPC	Client stub calls
GraphQL	Schema type/field definitions	Schema	Query/mutation strings
Message Topics	Kafka, RabbitMQ, NATS, Redis pub/sub	Publish calls	Subscribe calls
WebSocket	Event emit/listen patterns	emit()	on()
Env Vars	.env files, system calls	Setenv / .env	os.Getenv / process.env
OpenAPI	Swagger / OpenAPI spec files	Spec paths	Linked HTTP routes
Temporal Workflows	Go / Java SDK annotations	Activity / workflow function	ExecuteActivity / ExecuteChildWorkflow

Gortex normalizes HTTP routes across framework boundaries into canonical string identifiers:

http
http::GET::/api/users/{id}

When a Go backend built with gin defines a route handler, and a TypeScript frontend invokes fetch('/api/users/123'), Gortex pairs provider and consumer nodes. If an engineer changes an HTTP route signature in the Go service, Gortex immediately flags the orphaned consumer in the TypeScript repository before integration testing.

Real-World Scale and Performance Benchmarks

Engineered for massive enterprise monorepos and multi-repo workspaces, Gortex processes multi-gigabyte AST graphs while maintaining low memory footprints.

The following benchmarks were measured on an Apple Silicon laptop using standard CGO release builds:

Repository	Total Files	Graph Nodes	Graph Edges	Index Time	Parsing Throughput	Peak Heap Memory
torvalds/linux	70,333	1,690,174	6,239,570	~3 minutes	300 files/s	5.07 GB
microsoft/vscode	10,762	204,501	808,902	~1 minute	143 files/s	580 MB
zzet/gortex (self)	430	5,583	53,830	3.4 seconds	127 files/s	52 MB

Token Payload Efficiency: GCX1 vs JSON

To optimize transport efficiency when streaming graph snapshots to LLM agents, Gortex uses GCX1, a published, fully round-trippable wire format. Compared to standard JSON formats containing identical AST metadata, GCX1 reduces wire payload size by an additional 27%.

Combined with graph-native symbol lookups, agents avoid loading full files entirely.

Standard File Read Workflow:
  Agent ---> Requests user_service.go (850 lines) ---> Parses 18,000 tokens ---> Extracts 1 function signature

Gortex Graph Lookup Workflow:
  Agent ---> Query Engine (GCX1 wire format) --------> Returns 360 tokens ------> Exact node + callers

Developers can track cumulative context optimization using the built-in savings command:

bash
gortex savings --verbose

Output:

text
Gortex Token Savings
====================
Cost avoided:   $168.69 (claude-opus-4) across 1,878 calls · 11,246,094 tokens saved

Today       ████████░░░░░░░░   50.0%  saved 9,200 / 18,400 tokens   $0.14
Last 7 days ██████████░░░░░░   62.5%  saved 60,100 / 96,200 tokens  $0.90
All time    ███████████████░   93.3%  saved 11,246,094 / 12,050,716 tokens  $168.69

Agent Adapter Integration and MCP Workflows

Gortex automatically detects and configures up to 20 AI coding agents on a developer's machine using gortex init. It supports Claude Code, Cursor, Windsurf, VS Code / Copilot, Continue.dev, Cline, OpenCode, Antigravity, Codex CLI, Gemini CLI, Zed, Aider, Kilo Code, OpenClaw, Hermes, Oh My Pi, Pi, and Kimi.

The system exposes over 100 MCP tools, 16 resources, and 3 prompt patterns. Key tools include:

• contracts: Inspects provider and consumer call sites across microservices.
• preview_edit and simulate_chain: Executes speculative edits against a live editor overlay (shadow graph) without altering disk state.
• verify_change and check_guards: Validates static call contracts before staging code changes.
• pr_risk and get_pr_impact: Analyzes merge order conflicts and compute graph blast radius during pull request reviews.

Speculative Execution with Shadow Graphs

When an agent proposes an edit, modifying files on disk to test correctness consumes I/O and risks corrupting git state. Gortex introduces speculative execution through shadow graphs.

+-------------------------------------------------------------+
|                     SPECULATIVE ENGINE                      |
|                                                             |
|  Unsaved Buffer  ---> Live Editor Overlay (Shadow Graph)    |
|                               |                             |
|                               v                             |
|  MCP Tools       <--- Read-Through Layer (Base + Overlay)   |
+-------------------------------------------------------------+

Unsaved buffers are streamed to the daemon as a transient shadow layer. Tools like preview_edit query through this shadow graph, allowing AI agents to test refactoring impact, check broken callers, and verify contract stability before touching a single line of real disk storage.

Developer Quick Start Setup

Gortex installs as a single static binary with no runtime dependencies.

Installation

For macOS and Linux environments:

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

For Windows (PowerShell):

powershell
irm https://get.gortex.dev/install.ps1 | iex

Initializing a Project

1. Perform machine-level integration:

bash
gortex install

2. Start the background daemon:

bash
gortex daemon start --detach

3. Register target repositories with the multi-repo engine:

bash
gortex track ~/projects/backend-service
gortex track ~/projects/frontend-app

4. Initialize agent hooks and MCP routing inside your active working directory:

bash
cd ~/projects/backend-service && gortex init

Once initialized, all detected local AI tools communicate directly with the daemon through standard stdio or the HTTP /v1/* endpoint (including MCP 2026 Streamable HTTP).

Telemetry is strictly opt-in and turned off by default. It respects environment flags like DO_NOT_TRACK and never transmits source code, file paths, or symbol identifiers.

bash
# Check or toggle telemetry status
gortex telemetry status

By substituting raw text file ingestion with SQLite-backed AST graph indexing, Gortex solves the context degradation bottleneck inherent in AI-assisted software engineering.

References

• https://github.com/zzet/gortex