llm-agents.nix: a Nix flake that packages AI coding agents for reproducible installs

The problem is install drift across a dozen agent CLIs

Coding agents ship as npm globals, curl-pipe-bash installers, Homebrew formulae and standalone binaries. Each one has its own update path. If you use three or four of them across a laptop and a CI runner, you end up with versions that differ between machines and no record of what changed when. The README describes the repository as "Nix packages for AI coding agents and development tools. Automatically updated daily." That single sentence is the whole pitch: instead of tracking each vendor's installer, you track one flake and let Nix resolve the set. The audience is narrow and specific. It is people who already have Nix installed and already treat their shell environment as a build artifact. If your machine does not have Nix, this project adds a package manager before it adds a single agent, and that is a bad trade for one tool. If you run NixOS or nix-darwin and keep a home-manager configuration, the value is immediate: the agents become ordinary inputs you can pin and roll back.

What the package list actually contains

The generated package docs cover a wide spread. There are terminal agents such as claude-code, codex, cline, crush, cursor-agent and droid. There are desktop applications: chatgpt, claude-desktop and bb-app, described as an "Agentic IDE for orchestrating coding agents". There are less obvious entries too, including agentty (a C++ terminal pair programmer), claw-code, dsh from DeepSeek AI, eca, forgecode, copilot-cli, amp, antigravity-cli and command-code. The list is long enough that the README generates it rather than hand-maintaining it, which is a signal the maintainers expect churn. Each entry carries a Source field with values like source, binary and bytecode. That field matters more than the summary line. A source entry means Nix builds the tool from its upstream repository. A binary entry means the package wraps a prebuilt artifact downloaded from the vendor. The first is auditable through the Nix build log. The second is not, and the trust boundary sits with whoever published that binary.

How the flake is structured and how updates flow

Every tool gets its own directory. The README links packages/agentty/package.nix, packages/amp/package.nix, packages/claude-code/package.nix and so on, with claude-code additionally pointing at packages/claude-code/README.md for detailed usage. That layout means the repository is a collection of independent derivations behind one flake output, not a single monolithic build. The daily update claim in the description implies an automated job that refreshes upstream versions and hashes, which is the only way a list this size stays usable. What the material does not show is the updater itself: there is no workflow file or script quoted in the README, so how a version bump is proposed, reviewed and merged cannot be confirmed from what is provided here. Treat "automatically updated daily" as a statement about intent and cadence, not as a guarantee about any individual package. The practical consequence for you is that the flake input moves under your feet. You pin it in flake.lock, and you decide when to advance that pin.

Running a tool without installing anything

The README gives one usage pattern, repeated for every package: nix run github:numtide/llm-agents.nix#<name> -- --help. For the Codex CLI that is nix run github:numtide/llm-agents.nix#codex -- --help. For Claude Code it is nix run github:numtide/llm-agents.nix#claude-code -- --help. The double dash separates Nix's own arguments from the arguments passed to the wrapped program, which is why it appears in every example. Two things follow from this form. First, it resolves against the repository's default branch unless you supply a ref, so the version you get is whatever main held at that moment. Second, it downloads and builds on demand, which is fine for a trial and wasteful for daily use. For a persistent setup you would add the flake as an input and reference the package from your own configuration; the README does not spell that out, so the exact attribute path is something to read from the flake output rather than assume. Note also that several entries are marked unfree, including claude-code, cursor-agent, droid, copilot-cli, amp and chatgpt. With a stock Nix configuration those will refuse to evaluate until you permit unfree packages, so a first nix run against one of them can fail for a reason that has nothing to do with the package being broken.

Unfree licences and binary sources are the real constraint

This is the part worth reading twice. The repository itself is MIT, but that says nothing about the tools it wraps. The package docs mark a large share of entries as unfree: claude-code, claude-desktop, chatgpt, cursor-agent, droid, copilot-cli, amp, antigravity-cli and command-code all carry that label. A Nix package for unfree software is a distribution convenience, not a licence grant. You still need whatever entitlement the vendor requires, and redistributing a cached binary may be restricted in ways the MIT licence on this repository does not cover. The Source field compounds this. Entries marked binary or bytecode, such as copilot-cli, cursor-agent, droid and command-code, wrap vendor artifacts rather than building from source. You are trusting the download and the hash recorded in the derivation. That is a normal pattern, but it is a different trust model from a source package, and the README does not present it as a distinction worth noticing. It is. If your organisation has rules about provenance for executables on developer machines, the Source field is where you check compliance, one package at a time. None of this is legal advice; it is a description of what the metadata says.

Where a plain npm or brew install is the better answer

The honest alternative is not another Nix flake. It is the vendor's own installer, or npm i -g for the JavaScript agents. Compare the two on a single machine with one agent. npm gives you the tool in seconds, updates with npm update, and requires nothing else. llm-agents.nix gives you the same tool plus a Nix store, a flake.lock to maintain and an unfree-package setting to toggle. On that machine the flake is overhead. The calculus flips at the point where you have several machines or several agents. With npm globals, reproducing your exact set on a second laptop means remembering which packages you installed and at which versions. With the flake, the lockfile is the answer, and rolling back a bad agent release is a change to one input. There is a middle option worth naming: run the vendor's own container image if the vendor publishes one. That also pins a version, but it isolates the tool from your shell and your dotfiles, which is the opposite of what most terminal agents want, since they read your repository and your config. Nix sits between the two: pinned like a container, integrated like a native install.

Maintenance cost sits with the maintainers, not with you

Your ongoing cost is the flake input. If you add it to a configuration and never touch it, you stay on whatever revision you pinned, which is stable and slowly stale. If you update it, you inherit whatever landed in the repository that day, across every package you consume, not just the one you care about. That is the usual Nix trade and it is manageable, but it argues for pinning per project rather than globally if you depend on a specific agent's behaviour. The maintainers' cost is the harder one. A repository that tracks dozens of fast-moving agent releases has to keep up with upstream version schemes, hash changes and the occasional package that disappears or renames. The README's generated package docs are clearly a response to that churn. The single recent release listed is assets, tagged as Static Assets, which suggests releases are not the primary distribution channel; the flake output is. That is consistent with how Nix projects usually work, and it means there is no changelog to read before you update. You diff the lockfile and read the commit log instead.

Editorial conclusion

Adopt llm-agents.nix if you already run Nix and want claude-code, codex, crush or cline pinned in a flake.lock instead of installed by curl scripts. Do not adopt it if you have no Nix on the machine, or if you need a package the README does not list. Before you commit, check the Source field for the tool you want, confirm whether its licence is listed as unfree, and verify that the packages/<name>/package.nix file actually exists on main.

Official sources

1. License: MIT
2. numtide/llm-agents.nix on GitHub
3. Project website
4. README
5. Releases