Every version, and what it changed for you.
63 releases since 25 Jul 2026. Breaking changes say what to do about them, and a version that rebuilds your index says so at the top.
Archis updates itself: chi update checks what is published, verifies the release hash before writing anything, and puts the previous binary back if the new one does not start. chi update --check installs nothing.
0.42.0
One storage engine. Archis now keeps every repository's graph in the partition store, which is smaller on disk, holds branches and file history, and no longer makes one agent wait for another's index.
Before you upgrade — Your index rebuilds itself the first time you run a command in each repository. Nothing else is needed, and nothing is lost — a graph is built from your working tree. On this project 125 MB of index became 22 MB, in under a second.
- BreakingYour index rebuilds. Archis used to be able to keep a repository's graph in either of two storage engines, and only one of them is left. The two write different bytes and neither reads the other's, so there is nothing to migrate: the first command you run in a repository builds the graph again from your working tree. It is fast — under a second on a repository of eight hundred files — and the result takes a fifth to a third of the disk the old one did.
- BreakingEach
git worktreebuilds its own index again. 0.41.0 let a linked worktree start from the primary checkout's graph, and that only ever worked on the engine that has now been removed: this one keys everything in a graph by the repository it was indexed from, so a copy taken from another checkout describes that checkout and not yours. A worktree indexes itself, which is what every checkout did before 0.41.0. Sharing one index between the worktrees of a repository is the work that replaces it. - ImprovedA question is answered while another process is indexing, instead of waiting for it. Reading used to take the same exclusive lock that writing does, held for as long as the connection was open — so
chi overviewduring a full index waited 7 seconds on a mid-sized repository, 14 on a large one, and on the largest it ran out of retries and failed. A read now takes no such lock: during an index it costs about 25 milliseconds more than a quiet one. Twenty agents asking at once are served in 1.4 seconds where they took 3.7. - ImprovedSearching after you edit a file is roughly thirty times faster: 13.9 seconds down to 470 milliseconds. The search index used to be rebuilt from nothing every time the graph changed, and every old copy was kept — 866 MB of them on one repository. It is now carried forward from the previous version with only the files you changed patched into it, and the copies are pruned.
- ImprovedRepeated questions in one session are much cheaper. Archis kept re-opening the graph for every call, which threw away everything it had warm; it now holds the graph open between calls and brings it up to date in place rather than replacing it. Measured over twelve searches on a large repository: a median of 4.7 milliseconds against 63.
- ImprovedThe first question of a session starts faster. Scanning your working tree now uses several cores, and a question opens the graph once where it used to open it twice — read-only, which skips work only a write needs and which was costing 70 milliseconds at every session start for a connection that was dropped immediately.
- ImprovedA small repository stopped paying for two
gitsubprocesses on every command. When your checkout is not on a branch — which is how most benchmark corpora and some CI checkouts sit — Archis asked git twice and got no useful answer either time, about a quarter of a second per invocation. - FixedContext packages were missing the code around what you asked about.
chi contextand the compact selection grow a neighbourhood outwards from the best matches — the callers, the callees, the sibling sections of a specification — and on the current storage engine that expansion silently found nothing, so an answer was the search results and no more. It now reaches the neighbourhood it was built to reach: on a mid-sized Go repository, a thousand candidates considered where there had been a couple of dozen. - FixedAn edit package now says who calls the symbol you are about to change, and what it calls. Both lists came back empty, which are precisely the two questions a patch has to answer before it is safe.
- FixedAsking for a name that several files declare now says so. You used to get one of them, with nothing to indicate a choice had been made — and following the outline's own advice that names work as ids, you could be told about a different file's function and have no way to notice. The answer now names the rival declaration and where it is.
- FixedA file you have already been shown comes back as what changed, not as the whole outline again. This shipped in 0.41.0 and never once took effect on the current storage engine, because the two halves of it disagreed about how to name a version of a file. Re-reading a large file after an edit is now a few dozen tokens instead of about fifteen hundred.
- FixedDocument titles no longer crowd real declarations out of an answer. A task whose words appear in a dozen section headings could push the function it was actually about out of the budget entirely.
- FixedA section of a document can be asked for by name again on the current storage engine, which is how one document links to another and how anything Archis handed you refers to it.
- FixedThe MCP server now stops when it finds an index written by a newer Archis than itself, so whatever supervises it starts the version you installed. It used to report the mismatch on every call and keep running — and the index must not be deleted, since the newer build reads it perfectly well.
- Fixed
chi-mcpnames the index it is actually serving. Its startup line printed a path it had not written and a size of zero for a file that was not there. - FixedThe hook that records what an agent read with its own tools no longer needs Archis to have been used first. It gave up when the session store did not exist, and nothing creates that store except an Archis tool call — so the one measurement that shows an agent ignoring Archis could not be taken until the agent stopped ignoring it. A directory Archis has never indexed is still left alone.
- Fixed
chi hookaccepted--dband--sessionsand ignored them. A hook reads and writes the stores of the repository it is working in, found from its working directory, which is what lets one registration serve every project. The flags are now refused with a message saying where a hook does get its stores from.
Run the current release
Archis Free is the whole local engine, with no card. Everything semantic runs on your machine — there is no endpoint that accepts source.