Ix builds a queryable graph of your repository so agents stop re-reading it

The problem Ix targets: agents that re-derive your architecture every session

The failure mode Ix is aimed at is specific. A coding agent needs to answer a question like what calls this function, and the only tools it has are search and file reads. So it greps, opens the file, opens the files that file imports, and pastes all of it into a prompt. The answer is correct and expensive, and the next session starts from zero because nothing was written down. The README frames the same contrast in a table: without Ix, finding things means search, read, search again, and architecture is re-derived every session.

The intended user is not a person browsing unfamiliar code once. It is someone running an agent against the same repository repeatedly, where the cost of re-deriving structure is paid on every run. The secondary user is a human who wants to ask what breaks if a particular function changes without opening six files. Both cases assume the repository is large enough that structure is not obvious from the directory listing.

Map, structure, retrieve, remember: what actually gets built

The pipeline has four named stages. Map runs tree-sitter over the repository and extracts symbols, calls and imports. Structure turns those into nodes and edges, so the graph records what calls, contains and imports what. Retrieve returns bounded answers about one symbol or flow rather than whole files. Remember means the graph is stored locally and survives across sessions and agent runs.

The storage backend is the part worth pausing on. According to the README, the graph is persisted in ArangoDB plus a memory layer, run for you in Docker, and the backend ships as a released Docker image rather than being built from the repository. Three clients read that same graph: the ix CLI, the ix mcp server, and Compass, the visualizer that ix view opens. All three share the endpoints documented in the HTTP API reference under docs/api.

That is a real architectural commitment. A code graph is a graph problem, and a document store would be a poor fit, so the choice is defensible. But it means Ix is not a self-contained binary that reads a local index file. The graph lives in a database process, and the CLI is a client of it.

The four commands and what each one returns

The README shows the working set directly. ix map . builds the graph for the current repository. ix explain AuthService answers what a symbol is and what it touches. ix trace user_login_flow follows how something actually flows. ix impact verify_token answers what breaks if that symbol changes.

Each of these is a bounded query against the graph, not a file dump. The distinction matters for agent use: ix explain returns that symbol and its immediate relationships, and the README's own framing is that answering the same question by reading the file and the files it imports costs far more, and costs it again next session. The persistence is what changes the economics, not the query itself.

One thing the material does not settle is how ix trace defines a flow. Nothing in the README says whether flows are named entities you declare, inferred call chains, or something else. If you need trace to follow a specific user journey, confirm how flows are identified before you build a workflow around it.

Getting it running: installer, map, then MCP registration

On macOS and Linux the install is a single shell pipeline: curl -fsSL https://ix-infra.com/install.sh | sh. On Windows you install Node.js 22+ and Docker Desktop first, then run irm https://ix-infra.com/install.ps1 | iex in PowerShell. The installer checks for and installs missing pieces: Node.js 22+, Git, ripgrep (which powers ix text), and Docker plus Docker Compose for the local backend.

After that, two commands: ix map . and ix mcp install. The MCP installer detects installed clients and registers ix mcp with each. ix mcp install --dry-run shows what would change and writes nothing, and ix mcp doctor checks each client's registration. The installer knows Claude Code, Codex, Cursor, VS Code, Gemini CLI, OpenClaw and opencode. It writes through each client's own MCP command where one exists, never overwrites a server name it does not own, and accepts --force to replace one or --host <id> to limit the run.

If you register a client by hand, the README gives the shape: codex mcp add ix-memory -- ix mcp. There is also an agent skill under skills/ix/ that follows the Claude Code skill format and the agents.md standard, deployed with bash scripts/install-skill.sh, which takes --dry-run to preview. Optional native plugins exist for Claude Code, Codex, OpenClaw, Gemini, OpenCode and Cursor, each with a Windows PowerShell installer as well.

The Docker dependency is the constraint that decides adoption

Ix requires Docker and Docker Compose on the machine where you run it, because the ArangoDB backend runs in a container. That is the sharpest limitation in the material, and it is a policy problem as often as a technical one. On managed corporate laptops, Docker Desktop is frequently disallowed or licensed per seat. On CI runners it is usually available but adds startup cost to every job. On a remote development box it may be fine.

There is a second consequence. Because the backend is a released image rather than something built from this repository, you cannot read the server code to understand a query result, and you cannot patch it. You are a client of a service whose implementation is not in front of you. That is a normal arrangement for a database, but it means debugging a wrong answer in the graph is harder than debugging a wrong answer in a parser you can read.

The repository also carries a second product in the same README. Kartr is described as an agent platform built on the same memory engine, extended to docs, email and calendar, meetings and notes, and team chat, and it is in alpha with early users being onboarded through a signup form. That is a different product with a different maturity level. Do not read Ix's release history as evidence about Kartr.

Where the numbers come from, and where they do not

The README reports that querying the graph instead of feeding files into the prompt cut token use by 30 to 99.7 percent across the project's own development work. It also states plainly that these are internal measurements and not a published benchmark, and that the range varies widely with the task and the size of the repository.

That caveat is doing a lot of work, and it should be read literally. A spread from 30 to 99.7 percent is wide enough that the number tells you almost nothing about your own case. The mechanism behind it is not mysterious: a bounded query returns less text than a file, and the saving repeats because the graph persists. Whether you land near 30 or near 99.7 depends on how much of your question the graph can answer without a file read. Treat the figure as a direction, not a target, and measure on your own repository before you make a claim internally.

Alternatives: language servers, and what they answer instead

The closest comparison is a language server. A TypeScript language server, driven through an editor or an LSP client, already resolves definitions, references and call hierarchies for a single language, using the compiler's own type information. That is more precise than a tree-sitter parse for the languages it covers, because it understands types rather than syntax.

The difference is in scope and persistence. A language server answers questions about one language in one workspace, usually inside an editor session, and it does not build a cross-language graph or a durable store that an agent can query between runs. Ix parses with tree-sitter, which is the reason it can cover a polyglot repository at all, and it persists the result so a later agent run reads the same edges. If your repository is a single TypeScript package and your questions are all go-to-definition, the language server you already have is the better tool and costs you no container. If your repository spans several languages and your agent needs the same structural answer twice, the graph is the thing the language server does not give you.

Licence, maintenance, and what to check before you commit

Ix is Apache-2.0. That permits commercial use and modification and includes a patent grant, with the usual conditions around preserving notices and stating changes. It does not extend to the backend Docker image, which is distributed separately from this repository, so the licence covering that image is a separate question from the licence covering the code you can read. This is not legal advice; if the distinction matters to your organisation, read both licences rather than assuming the Apache-2.0 file covers the whole system.

On maintenance, the observable signal is release cadence. Versions v0.10.6, v0.10.7 and v0.10.8 were all published on 2026-09-06, and the last push to main is 2026-09-10. A burst of patch releases on one day is consistent with active work and also with a period of churn; the material does not say which. The version numbering, still on 0.10.x, is the more useful signal: the project has not declared a 1.0, so interfaces and command behaviour can change between minor versions.

Before adopting, check three concrete things. Run ix mcp install --dry-run first and read the list of clients it intends to touch, since it writes into other tools' configuration. Run ix explain against a symbol whose relationships you already know, and see whether the returned edges match your mental model or merely look plausible. And confirm the released backend image starts on your platform, since the installer's Docker check confirms Docker is present, not that the image runs under your daemon's configuration. If those three pass, the persistence argument holds and the container is worth the cost.

Editorial conclusion

Adopt Ix if you already run Docker on developer machines, work in a repository large enough that re-reading files is the bottleneck, and use at least one MCP-capable client such as Claude Code, Codex or Cursor. Do not adopt it for a single-package project, a machine where Docker Desktop is not allowed, or a team that expects a hosted service with no local daemon. Before committing, verify three things: that the released backend image runs on your platform, that ix mcp install --dry-run lists exactly the clients you expect and nothing else, and that ix explain on a symbol you know well returns relationships you recognise rather than a plausible-looking superset.

Official sources

1. ix-infrastructure/Ix on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases