IRIS draws its completion menu inside your real terminal

The menu is drawn where your shell already is

The design decision that distinguishes IRIS from everything else in this space is stated in a single line, that IRIS is built on top of TTY, so it runs everywhere and it just needs a terminal. The consequence is that each suggestion menu renders directly inline inside your real terminal session, not in an app's imitation of one, so it never breaks full-screen terminal user interfaces or terminal formatting. That sounds like a small detail until you have used a completion tool that hijacks the alternate screen buffer, because the program you were in disappears and comes back wrong. The rest of the description follows from that choice. Run IRIS wherever you already work, your local machine, a remote server, or anywhere you can ssh, and it is a single local native Go binary, not an app, with no GUI, no Electron, no mac-only wrapper, no account and no telemetry.

Why the comparison table with Fig and with shell plugins

The README has two comparison tables, and they say more than the marketing copy does. Against Fig, the point is that Fig was officially sunset in September 2024 and migrated to Amazon Q Developer, which the project describes as requiring cloud authentication and proprietary bloat, and IRIS is positioned as the lightweight, open-source, zero-telemetry alternative built purely on native Go and TTY with no accounts, no GUI app and no background daemons. The feature rows make the same argument in a table: platforms, Linux and macOS against macOS only, a native Go TTY engine against Electron, an inline overlay against a GUI popover, TTY-native portable remote SSH against a macOS GUI-bound tool, working tmux and Linux virtual terminals against limited or unsupported, and a lightweight memory footprint against the Electron runtime. The second table compares against shell autocomplete plugins, where the differences are installation, a single binary against a plugin manager, shell support across most shells against something usually shell-specific, no shell initialization and no added startup time, one config across SSH rather than a per-shell config, and tmux and virtual terminal support that depends on the shell in the plugin case.

It learns from your aliases and your history

The feature that makes IRIS different from a static completions database is that it indexes your own environment. You can run it wherever you work, and it automatically indexes your aliases and shell history to suggest commands that match your actual workflow in real time. The comparison with a code editor's IntelliSense in the summary line is the right analogy, because the model is the same, a suggestion list that reflects the code you actually write rather than a vocabulary someone else guessed. The other half of the feature list is that you can change configurations and propagate them instantly without restarting your shell, which is the difference between a tool you configure once and a tool you stop using because editing it means opening a new terminal. And the AI suggestions exist alongside, with the screenshot caption noting that IRIS has AI suggestions like your code editor, using an API key or a local model.

Installing it, and the platforms that are excluded

The dependencies are short, and one of them is an exclusion. You need Linux or macOS, a terminal emulator with ANSI colour support, and Go 1.24 or newer if you build from source, and the warning is that Windows is currently not supported. The package manager route offers three options. On Arch Linux the AUR package is iris-autocomplete, installed with yay -S iris-autocomplete or paru -S iris-autocomplete. On macOS and Linux Homebrew taps the project directly with brew install versenilvis/iris/iris. And for Nix Flakes the module can be consumed without building it manually, by adding the input to your flake.nix:

iris.url = "github:versenilvis/iris/main";

The Flake path lets you consume the module without building it manually, and the AUR and Homebrew routes are the ones to use when you want to upgrade with the rest of your system.

The dependency stack says it is a TUI, not a terminal emulator

The go.mod is a good map of what the tool is. The interface is built with lipgloss and rendered with glamour, both from the Charm ecosystem, with the x/ansi and x/term packages for the terminal handling, and the cobra library for the command line, plus BurntSushi/toml for the configuration and the versenilvis/fuzzy package for the fuzzy matching of the suggestions. The history index is a database, with modernc.org/sqlite as a pure Go SQLite build, which keeps the promise of a single static binary with no cgo dependency, and the test stack includes creack/pty for pseudo-terminal tests and goleak for goroutine leak detection. The optional entries in the go.mod show how deep the Charm stack goes, with ultraviolet, termios, conpty, xpty, cellbuf and colorprofile, which is the price of rendering an overlay in a way that works on Linux, macOS and Windows terminals, even though the tool itself does not run on Windows.

A repository organised around a just file

The repository layout is modern and it is organised around a just file rather than a Makefile. The justfile sets dotenv-load, which means the environment comes from a .env file, and then imports six sub-files, justfiles/build.just, dev.just, test.just, gen.just, pkg.just and debug.just, so a newcomer runs just -l to see the command list, as the comment at the top of the file says. Around that are the directories you would expect, cmd/ and cli/ for the command line, internal/ for the implementation, commands/ for the command definitions, spec/ and tests/ for the test suites, integration/ for the end to end tests, themes/ for the appearance, packaging/ and scripts/ for the release plumbing, and a docs/ directory. The build and release are handled by goreleaser, with the .goreleaser.yaml at the root, and the version scheme is visible in the tags, with v0.7.2, v0.7.3 and a nightly build named v0.7.4-nightly.38215d, which suggests a continuous release channel alongside the tagged ones.

What IRIS is, and where it stops

The honest scope is a completion tool that learns from your own machine, not a completions database. That is the whole bet, and it cuts both ways. It means IRIS is immediately useful with no catalogue to download, and it means the suggestions are limited to the commands you have actually used, so a tool you need once will not be in the list. The second limit is the TTY approach itself, which requires a terminal that will let another process draw an overlay, and the README's requirements of Linux or macOS and ANSI colour support are the boundary of that. The third is that it is marked beta, with a beta badge in the header, and the licence is 0BSD, which is a very short permissive licence with no attribution requirement, so vendoring it into a product is easy. The repository carries AGENTS.md, CLAUDE.md, a _typos.toml, a cliff.toml for the changelog and a hk.pkl, which is the configuration for a hook runner.

Editorial conclusion

IRIS is worth trying if you spend the day in a terminal and want completion that behaves like an editor rather than like a shell plugin, because the TTY-native design is the part that survives tmux, SSH and virtual terminals, and the history-based suggestions are the part that teaches you your own commands back to you. It is the wrong tool on Windows, which the README says is not supported, and the wrong tool if you want a completions database maintained by somebody else, since this learns from your machine rather than shipping one. Before you install it, read the configuration guide rather than the install section, because a tool that indexes your shell history deserves an explicit look at what it stores, and check the version, since the project is marked beta and ships nightly builds alongside its tagged releases.

Frequently asked questions

Official sources

1. Issues
2. License: 0BSD
3. README
4. Releases
5. versenilvis/IRIS on GitHub