Gortex states three different tool counts and two different agent counts on one page

Three numbers for the tool surface and two for the agent integrations

The opening paragraph says 175 configurable MCP tools. Three bullets later the same page says 100+ MCP tools, 16 resources and 3 prompts. Those cannot both describe the same surface, and the difference matters operationally: an agent's tool budget is a real constraint, and a number stated twice with two values is a number nobody has counted. The agent integrations have the same problem. The line above the list enumerates 19 coding agents, naming Claude Code, Kiro, Cursor, Windsurf, VS Code with Copilot, Continue.dev, Cline, OpenCode, Antigravity, Codex CLI, Gemini CLI, Zed, Aider, Kilo Code, OpenClaw, Hermes, Oh My Pi, Pi and Kimi, and the paragraph above it says plug and play across 19 coding agents. A later bullet then says agent integrations, 20, and attributes the work to gortex init configuring every detected assistant on the machine. So one page states both the count and the full list, and then contradicts the count once.

257 languages is a dependency count, and every grammar carries its own version

The language claim is explained by go.mod. The module requires github.com/alexaandru/go-sitter-forest as one Go module per grammar, and the visible list runs ada, agda, aiken, al, apex, asciidoc, astro, awk, beancount, bibtex, bicep, bitbake, blade, c3, caddy, capnp, cedar, cel, circom, clarity, clojure, cmake, cobol, commonlisp, cooklang, crystal, cuda, cue, d, dataweave, dbml and desktop, and onward to the 257 total. The versions are not uniform: ada and agda sit at 1.9.0, al at 1.9.14, apex at 1.9.8, c3 at 1.9.25, crystal at 1.9.29, desktop at 1.9.4. So the language support is a dependency graph with dozens of independently versioned modules, which is the honest reason coverage grows quickly and also the reason an upgrade is not one bump. Parsing itself is layered: three tiers, bespoke tree-sitter grammars, regex, and forest-backed signatures, with notebooks for Jupyter and Databricks handled separately. The page also misspells its own adjective here, introducing a bullet titled Extreamly fast analysis.

A precomputed depth-3 reach index is what makes the blast-radius question cheap

The performance story is a specific data structure rather than a benchmark table. A precomputed depth-3 reach index turns a blast-radius query into map lookups costed as O(seeds times reach), which is what lets the page invite the question what breaks if I change this on every edit without dozens of tool calls to assemble context. The graph stores functions, classes, call chains, HTTP routes and cross-service contracts, and it claims a provenance-tiered structure with a confidence model, which is how a resolver records that one edge is certain and another is inferred. Two features keep an agent from touching the disk while it thinks: preview_edit and simulate_chain answer what would change if a workspace edit were applied, using the LSP edit type, and live editor overlays push unsaved buffers as a shadow graph that tools read through, with branching for parallel speculative sessions. The daemon behind this is long-lived, serves every IDE window from one process, watches the filesystem with fsnotify, and keeps its graph in an on-disk SQLite store.

Zero network by default sits next to ten optional model providers

Two claims about the runtime sit next to each other. One bullet says zero external dependencies, a single binary with everything in-process, no network and no model download to get started: install, start the daemon, use it. Semantic search supports that, with GloVe-50d baked into the binary at 3.8 MB, store-native FTS5 and BM25 plus vectors fused with an adaptive alpha, and MiniLM, Ollama or OpenAI left opt-in. Another bullet then lists 10 optional LLM providers: local llama.cpp, Anthropic, OpenAI, Ollama, Claude or Codex CLI subprocesses, Gemini, Bedrock, DeepSeek and Requesty. So the no-network property holds for indexing and search and not for the parts that call a model. Those parts are concrete: gortex prs triages open pull requests with per-PR blast radius, merge-order conflicts through shared communities, an AI-ranked queue and reviewer suggestions, and gortex review emits line-anchored findings with a BLOCK, REVIEW or APPROVE verdict from a graph-grounded rulepack, with MCP tools including pr_risk, get_pr_impact, review, review_pack and post_review.

Install pipes a remote script and then claims SHA256 plus cosign verification

The install commands are one line each:

# macOS / Linux
curl -fsSL https://get.gortex.dev | sh

# Windows (PowerShell)
irm https://get.gortex.dev/install.ps1 | iex

The sentence after them is the supply chain claim: the installer detects OS and architecture, verifies SHA256 and cosign, installs to PATH, and re-running it upgrades. The page carries badges pointing at a supply chain verification section of the installation document, at SLSA build level 3, at a VirusTotal URL report and at a scorecard entry, and the repository root carries a .goreleaser.yml, so the release pipeline and the verification story are both in the repository. Alternatives are listed for people who will not pipe: Homebrew, .deb, .rpm and .apk packages, scoop, signed binaries and from-source builds. Whether the cosign check happens before or after the script has already run is the part the page does not spell out, so read the installation document before trusting the pipe on a machine with production credentials.

Telemetry is specified to the byte and the HTTP server's bind address is not

The privacy story is the most precisely written paragraph on the page. Telemetry is off by default; opting in sends anonymous tool and command counts only, explicitly no code, no paths, no names and no exact counts; nothing is transmitted unless you configure an endpoint; the switch is gortex telemetry on, off or status; and DO_NOT_TRACK is honoured. Compare that with what the page says about the network surface: an HTTP server with a versioned /v1/* API plus MCP 2026 Streamable HTTP, and a standalone Next.js 15 web UI with five 3D graph modes. Neither the default bind address nor any authentication for those endpoints appears on the page. For a daemon that writes a SQLite graph of your repositories to disk and accepts requests that can read symbols and call chains, that is the gap worth closing before first run, and it is a larger one than the telemetry defaults suggest. The same page also installs hooks into repositories: gortex init writes .mcp.json, hooks and community routing per repo.

Four build variants, three embedding backends and Raspberry Pi benchmarks

The Makefile shows what the project is actually built for. The default target compiles with the llama build tag; build-onnx adds embeddings_onnx; build-gomlx adds embeddings_gomlx with XLA; and build-hugot is kept as a compatibility alias, with a comment saying Hugot is bundled by default now and that the target exists so the dependency stays recorded in go.mod. So three interchangeable embedding backends ship behind build tags, and one target is a fossil. Tests run with the race detector, and the benchmark targets include bench-rpi, bench-rpi-quick, bench-rpi-profile and bench-compare, which says the daemon is expected to run on a Raspberry Pi class machine rather than only on a workstation. Versioning is stamped through ldflags: VERSION from git describe or dev when there is no checkout, COMMIT as the short SHA, DATE in RFC 3339, with main.commit filling the +build slot so gortex version prints canonical semver. The comment still gives v0.1.0 as the example tag while the releases are at v0.64.x. go.mod declares go 1.27.0.

The cross-repo contract table stops after three frameworks

Cross-repository work is the feature the page argues hardest for: N repositories in one graph, with contracts, references and call chains crossing repo boundaries under evidence-gated resolution, contract matching, impact analysis and per-session isolation, all documented separately for multi-repo setups. The mechanism for that is contract auto-detection, matching providers to consumers, surfaced through a contracts MCP tool and a Contracts page in the web UI. The table that would tell you which contracts are detected and how stops partway through its first row: the HTTP routes entry names framework annotations for gin, Express and FastAPI and then ends, with no closing cell and no second row on the page. So the contract types you can actually enumerate from here are one, named and incomplete. The same pattern shows up in the benchmark story: the 50x token reduction and the further 27 percent for the GCX1 wire format are stated on the page with up to as the qualifier, while the method lives in BENCHMARK.md and BENCHMARK-SWE.md at the repository root.

Editorial conclusion

Gortex is a serious piece of engineering with a documentation page that has not caught up with it. The parts you can rely on are concrete: 257 grammars as individual pinned modules, a single static binary with cosign and SHA256 verification at install, telemetry that is off by default and defined down to what is not collected, and a build with four variants and Raspberry Pi benchmark targets. The parts to hold loosely are the headline numbers. Three tool counts, two agent counts, a 50x token reduction qualified as up to, and benchmark methodology that lives in two files rather than on the page. Before you wire it into an agent loop, check three things yourself: what the default bind address and authentication story are for the versioned HTTP API and the Streamable HTTP MCP endpoint, since the page is silent on both; what gortex init writes as hooks into each repository's agent configuration; and whether the depth-3 reach index is deep enough for the blast-radius questions your team actually asks.

Frequently asked questions

Official sources

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