Archis documentation

A coding agent answers questions about your code by reading your code. It opens files, greps for names, opens the files that turned up, and every one of those bytes lands in the context window at full price. Most of what it reads is not the part it needed — it is the surrounding file.

Archis reads the repository once, ahead of time, and builds an index of what is actually in it: every declaration, where it lives, what it takes, what it calls and who calls it. When the agent has a question, it asks the index instead of the filesystem, and gets an answer sized to the question. Exact source is still available — it is just no longer the first thing bought.

Measured: across 20 paired tasks per repository on 20 real repositories in 8 languages, the full policy spends 89.4% to 95.0% less context than a full-source agent doing the same task — mean 92.0%. Those runs are fixed tool sequences over the real server surface with every exposure priced by a tokenizer, so no model sits in the loop to flatter the result. The method is on How it works, and chi measure reproduces the reduction on your own code.

Everything in this documentation is one of three things. Knowing which is which makes the rest of it navigable.

The index

A graph of your repository, stored in a .chi directory beside your .git. It is built by chi index, refreshed a file at a time as you work, encrypted with a key that never leaves the machine, and never uploaded anywhere. It is the only thing that knows about your code.

The server

An MCP server your coding agent calls. This is how Archis is actually used day to day: you keep working in Claude Code, Codex, Goose or whatever you already use, and it asks the index instead of reading files. Connecting one is chi agents on, and it is the subject of Coding agents.

The CLI

The same questions, by hand — chi search, chi symbol, chi symbol --refs — plus everything the server cannot do for you: setup, licensing, measurement, and the local dashboard. Every command is in the CLI reference.

Four commands take a repository from nothing to an agent answering from the graph. This is the whole install-to-working path; the quick start walks each step.

From then on the agent does the asking. Nothing about your workflow changes: you open the same tool and give it the same task, and it spends a fraction of the context arriving at the same answer.

The rest of the documentation, in the order it is meant to be read.

Three things hold across every page.

• Commands are shown without their output unless the output is the point. Where a transcript appears, the lines you type start with $.
• Every command accepts --json, and the JSON is the contract — script against it rather than against the human-readable text, which is free to change.
• Measured means measured. A figure described as measured comes from a published run and is reproducible. Anything illustrative says so.

The command reference is generated from the binary itself, so it describes the release you are running rather than the one somebody documented. The plain-text version at /docs/cli.md is the same content in one file, which is the convenient form to hand to an agent.