numtide/llm-agents.nix: Nix packages for AI coding agents, updated daily

What the flake actually solves for people running coding agents

Coding agents are usually distributed as npm globals, curl-to-shell installers or self-updating binaries. Each one picks its own install path, its own update cadence and its own way of leaving files in your home directory. numtide/llm-agents.nix replaces that with a single flake whose outputs are Nix packages, one per tool. The README describes the project as "Nix packages for AI coding agents and development tools. Automatically updated daily." The audience is narrow and specific: engineers who already keep their machines or CI runners on Nix and want an agent installed the same way as ripgrep. If you are not a Nix user, nothing here helps you, because the entire interface is a flake reference.

The scope is wider than terminal agents. The generated package list covers CLI agents such as claude-code, codex, copilot-cli, cursor-agent, droid and crush, desktop applications such as chatgpt and claude-desktop, and an agentic IDE, bb-app. Some entries are built from source, others are repackaged binaries, and a few are described as bytecode. That mix matters when you evaluate how a given package will behave, because a source build and a vendor tarball are not the same supply chain.

How the packages are built: source, binary and bytecode entries

Every package lives in its own directory under packages/, with a package.nix file and, for at least claude-code, a README with detailed usage. The README's generated documentation lists a Source field per tool. agentty, claw-code, code, codex, crush and dsh are marked source, meaning Nix builds them from upstream code. amp, antigravity-cli, bb-app, chatgpt, claude-desktop, cline, copilot-cli, cursor-agent and droid are marked binary, meaning the derivation fetches a prebuilt artifact. command-code is marked bytecode. That distinction is the most useful thing on the page, and it is also the least explained: the README does not say how binary artifacts are verified, which upstream release channel is followed, or what happens when a vendor changes its download URL.

The daily update claim is backed by tooling rather than by hand editing. The repository root contains scripts/, a pyproject.toml for a project named llm-agents-nix described as a "Nix package updater library and tools", checks/, lib/, overlays/ and patches/. The Python configuration targets 3.13 and runs mypy in strict mode with explicit_package_bases and namespace_packages enabled, and the comment in the mypy section says each update.py is treated as a separate script rather than a module. Ruff is configured with select = ["ALL"] and a short ignore list. In other words, the update machinery is written in Python with unusually strict typing, and it regenerates package definitions. The repository also carries AGENTS.md and CLAUDE.md at the top level, which suggests the maintainers run coding agents against this repository itself.

The patches/ directory is worth knowing about before you assume a package is a clean repackaging. It exists for a reason, and the README does not enumerate which packages need patches or why.

Running claude-code, codex or crush without installing anything

The documented entry point is nix run against the GitHub flake reference. The README gives this exact form for every package, using agentty as the example:

nix run github:numtide/llm-agents.nix#agentty -- --help

The trailing `--` separates Nix's arguments from the program's, so `--help` reaches the agent, not Nix. Running it this way builds the package into the Nix store and executes it without adding anything to your profile. Substitute the attribute name for the tool you want; claude-code, codex, crush, copilot-cli and cline are all listed with the same usage pattern.

For a persistent install, add the flake as an input and reference the package from your own configuration. The README does not print a full flake snippet, so the shape below follows the standard Nix flake input pattern rather than a quoted example:

{
  inputs.llm-agents.url = "github:numtide/llm-agents.nix";
  # then reference inputs.llm-agents.packages.${system}.claude-code
}

Two things will bite you on the first attempt. Several packages are marked unfree in the README, including claude-code, copilot-cli, cursor-agent, droid, amp, chatgpt and claude-desktop. Nix refuses to evaluate unfree packages unless you allow them, so a plain `nix run` on those attributes fails until you set `NIXPKGS_ALLOW_UNFREE=1` and pass `--impure`. Second, the flake reference pulls from GitHub each time unless you pin it in flake.lock, which is the whole point of using it from a flake input rather than ad hoc.

For claude-code specifically, the README points to packages/claude-code/README.md for detailed usage. That file is where you should look for anything beyond `--help`, because the top-level README only gives the one-line invocation.

The unfree licence split is the real adoption constraint

The project itself is MIT licensed, and the LICENSE file at the repository root covers the packaging work. That licence does not extend to the tools being packaged. The README labels a large share of entries unfree: amp, antigravity-cli, chatgpt, claude-code, claude-desktop, command-code, copilot-cli, cursor-agent and droid. Others are permissively licensed, with agentty, bb-app, claw-code and crush under MIT, and cline, code, codex and eca under Apache-2.0.

This is not a packaging defect, it is a property of the upstream tools. But it has practical consequences that the README does not spell out. A NixOS configuration or a CI image that builds a closure containing claude-code needs the unfree allowance enabled, and a binary cache will not serve you a prebuilt path for something the builder refused to evaluate. If your organisation forbids unfree dependencies, the usable subset of this flake is the source-built, permissively licensed tools: codex, crush, cline, claw-code, dsh, agentty. That is still a reasonable set, but it excludes the most widely used agents on the list.

There is also no statement in the README about redistribution terms for the binary packages. Whether you may mirror a fetched artifact inside your own cache is a question for each upstream licence, not for this repository.

Where llm-agents.nix is the wrong tool

The flake packages a fixed list. If the agent you want is not in the generated package documentation, there is no generic mechanism described in the README for wrapping an arbitrary npm package or binary through this flake. You would write your own derivation, at which point the value of depending on llm-agents.nix drops to whatever you get from its update scripts, which are not exposed as a documented public interface.

Version pinning is the second weak point. The README states the packages are updated daily, and the only release listed is a static assets release dated 2025-10-28, not a versioned package release. There is no documented per-package version matrix, so if you need codex at a specific upstream version, the flake's main branch is not the right source. You would pin a commit and accept that you are now maintaining that pin yourself.

The third case is anyone who does not use Nix. Installing Nix to obtain a coding agent is a large dependency for a small gain, and the agents themselves ship their own installers. This project exists to make agents fit an existing Nix workflow, not to make them easier to obtain in general.

How this differs from installing agents with npm or Homebrew

The obvious alternative is the upstream installer each vendor provides, or a package manager like Homebrew on macOS. The difference is in what gets managed. An npm global install of a coding agent puts the tool in a Node version-specific prefix and updates it when you run the update command; Homebrew tracks its own formulae and updates on `brew upgrade`. Both leave the agent's runtime dependencies to the host system.

llm-agents.nix instead builds each agent as a Nix derivation with its dependencies closed over. The result is reproducible in the sense that the same flake revision and lock file produce the same store path, and rollback is a matter of switching to an earlier generation rather than reinstalling a previous version. The cost is that you inherit Nix's evaluation model: unfree packages need explicit permission, binary artifacts are fetched at build time, and the flake's own update cadence decides when you see a new upstream release. With npm or Homebrew you get the vendor's release the moment it ships; with this flake you get it once the daily updater has run and you have refreshed your lock file.

Neither approach is strictly better. If you already have Nix, the flake removes a class of version drift between machines. If you do not, npm and Homebrew are less machinery for the same binary.

Maintenance, updates and what the repository tells you

The last push to main was on 2026-09-10, and the repository is not archived. The README's claim of daily updates is consistent with that recency, though the README does not describe the update schedule beyond the phrase itself. There is no changelog in the repository, and the only release entry is a static assets release from 2025-10-28, so release notes are not a useful signal here. Track the flake lock and the commit history instead.

The upgrade cost sits with you, not with the maintainers. Because packages are regenerated from upstream, a `nix flake update` on your side can move several agents at once, and the README does not document rollback, per-package pinning or a way to hold one agent back while updating the rest. In practice you would pin the flake input to a commit and move it deliberately. The strict mypy and Ruff configuration in pyproject.toml suggests the update scripts are held to a high standard, which is a reasonable proxy for how carefully the generated derivations are produced, but it is not a guarantee about any individual package's correctness.

On licensing, the MIT licence covers this repository's packaging code only. The unfree entries carry their own terms, and nothing in the README suggests the project takes a position on them beyond labelling the field. If your use depends on redistribution or on running these in a commercial CI image, read the upstream licence for the specific tool. This is not legal advice, and the repository is not the authority on those terms.

Editorial conclusion

Adopt it if you already run Nix and want claude-code, codex, copilot-cli or crush installed and rolled back the same way as the rest of your toolchain. Skip it if you do not use Nix, or if you need an agent the flake does not package, since there is no generic wrapper here. Before committing, run the flake once with nix run and check the licence field of the specific package you plan to depend on, because several entries are marked unfree and will not evaluate under a default configuration.

Frequently asked questions

Official sources

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