llm-agents.nix
A Nix flake that packages dozens of AI coding agents and dev tools behind one uniform nix run command.
- Source repo
- numtide/llm-agents.nix
- Stars
- ★ 2.2k
- Last updated
- today
- License
- MIT
- Primary language
- Nix
- FA score
- 30/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platform
- Cost
- Free software; you pay for model usage
- Setup effort
- Low · running in minutes
- You'll need
- Typical use
- A developer who wants to try a new terminal coding agent before committing, e.g. nix run …#crush -- --help, without touching the system package manager.
- Not a fit if
- Teams that don't run Nix with flakes — every documented path is a nix run command
- Teams that require every packaged tool to be open source — many entries are marked unfree or ship as binary/bytecode
- Users who need documented version pinning — the repo updates daily but documents no pinning or flake-input workflow
- Source review
- 30/100 · Major gaps 7 safety controls not found
What does this agent do, and when should you use it?
llm-agents.nix is a Nix package set maintained by Numtide that wraps AI coding agents — Claude Code, Codex, Gemini CLI, opencode, crush and many others — together with adjacent tooling for code review, task orchestration, memory and code intelligence, sandboxing, and token-usage analytics. Each entry lives in packages/<name>/package.nix and is built either from source, from an upstream prebuilt binary, or from bytecode; the README is generated from that metadata and lists source type, license, homepage and the nix run invocation for every package. The repository itself is MIT licensed and described as automatically updated daily, so upstream releases keep flowing in. It is a distribution layer rather than an agent: you address any packaged tool by its flake attribute from a terminal. For developers already on Nix, it collapses "which coding agent should I try today" to a single command, and it gives reproducible pinning for teams standardising on several agents at once.
The repo is organized as a Nix flake: packages/<name>/package.nix defines a derivation per upstream tool, fetching and building from source, unpacking a vendor binary, or handling a bytecode distribution. The generated "Available Tools" section groups entries into AI Coding Agents, AI Assistants, Claude Code Ecosystem, ACP Ecosystem, Usage Analytics, Workflow & Project Management, Code Review, Voice & Transcription, Memory & Code Intelligence, Sandboxing & Isolation, Skills & Plugins and Utilities, and prints each entry's Source (source/binary/bytecode), License (including unfree), Homepage, Usage and package.nix path. Running nix run github:numtide/llm-agents.nix#<attribute> -- --help evaluates the flake, realizes or fetches that derivation, and forwards the remaining arguments to the upstream CLI. A handful of packages ship extra docs at packages/<name>/README.md (claude-code, forgecode, kandev, qmd). The repository makes no model calls and stores no data; its output is a runnable command.
- A developer who wants to try a new terminal coding agent before committing, e.g. nix run …#crush -- --help, without touching the system package manager.
- A Nix-using team that wants Claude Code, Codex and Gemini CLI pinned inside one devShell or flake instead of three ad-hoc install scripts.
- Someone comparing vendor agents across OpenAI, Anthropic, Google, xAI, Mistral and Qwen with an identical invocation pattern.
- Engineers building multi-agent workflows who need task orchestration and workspace tools such as beads, vibe-kanban, gastown or herdr.
- Security-minded users who want to run agents inside nono, sandbox-runtime, claudebox or fence rather than on the bare host.
- People auditing spend and sessions who want ccusage, tokscale, agentsview or mindwalk for local analysis.
How do you install or deploy this agent?
The only documented prerequisite is a working Nix installation with flakes; every example in the README is a nix run. There is no non-Nix install path, and the README does not document adding this repo as a flake input or overlay.
nix run github:numtide/llm-agents.nix#claude-code -- --helpSwap the attribute to get a different tool:
nix run github:numtide/llm-agents.nix#codex -- --help
nix run github:numtide/llm-agents.nix#opencode -- --helpNot documented: how to nix build the whole set, how to reference the flake from your own flake.nix, and what configuration is needed for packages flagged unfree.
How do you use this agent?
Call the attribute name shown in the generated table; anything after -- is forwarded to the upstream CLI:
nix run github:numtide/llm-agents.nix#gemini-cli -- --help
nix run github:numtide/llm-agents.nix#beads -- --help
nix run github:numtide/llm-agents.nix#vibe-kanban -- --helpclaude-code, forgecode, kandev and qmd have their own packages/<name>/README.md with detailed usage; the rest expose only source type, license, homepage and the one-line nix run command. Accounts, subscriptions and API keys are whatever the upstream tool requires — this repository neither documents nor manages those credentials.
What are this agent's strengths and limitations?
- Unusual breadth: coding agents, code review, task orchestration, memory/search, sandboxing and usage analytics all live in one flake with predictable attribute names.
- One invocation pattern covers all three delivery types — source builds, vendor binaries and bytecode — via nix run github:numtide/llm-agents.nix#<name>.
- Machine-readable per-entry metadata (source type, license including unfree, homepage, package.nix path) with docs generated from it, so the catalogue stays auditable.
- Automatically updated daily, so upstream releases land without waiting on manual packaging pull requests.
- The flake itself is MIT licensed and built on Nix derivations, so results are reproducible and composable with other Nix environments.
- Hard dependency on Nix with flakes; no Homebrew, npm or Docker path is documented.
- A large share of entries are unfree, binary or bytecode distributions, so you trust vendor-built artifacts instead of compiling from source.
- No documented flake-input or version-pinning workflow, while the repo refreshes daily — long-term reproducibility is left to the user.
- Beyond claude-code, forgecode, kandev and qmd, most entries get only a one-line nix run command with no configuration or auth guidance.
- No stability guarantees or version matrix from the repo; behaviour and licensing of each tool are entirely upstream concerns.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| llm-agents.nix This agent | 30 · Major gaps | CLIFree + model costs | ★ 2.2k | today | Nix | — |
| Foremerge | 77 · Good | CLIFree | ★ 534 | 6d ago | Rust | Codex · Claude Code |
| pitwall | 70 · Some gaps | — | ★ 18 | today | Go | Codex · Claude Code |
| acpx | 57 · Major gaps | CLIFree + model costs | ★ 3.4k | 3d ago | TypeScript | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
README lists source, license, homepage, and Nix path per package, so source_attribution earns 2, though upstream provenance is not verified. least_privilege is 0: the auto-merge workflow grants contents:write and pull-requests:write on pull_request_target and uses unpinned Mic92/auto-merge@main. user_confirmation is 0: dependency updates are auto-merged without human confirmation. data_flow_transparency, sensitive_data_handling, and rollback are undocumented, scoring 0. dependency_security is 0: no lockfile or pinned action is shown, and updates are daily/automatic. external_effects is 0: auto-merge writes to the repository and packages pull external binaries/source without consent or recovery notes.
self_consistency is 1: generated README docs and pyproject are broadly consistent, but flake.nix, package.nix, and lockfile evidence are absent, so package definitions cannot be checked. dependency_availability is 1: availability is only inferred from nix run commands; flake inputs and dependency pinning are not shown. failure_messages is 0: no runtime code or error-handling evidence.
audience_and_scenarios is 2: clearly aimed at Nix users, covers many coding agents, and gives per-package usage. capability_boundaries is 1: it states this is a package collection rather than a single agent, but platform, permission, and capability limits are not described. trigger_precision is 0: no trigger mechanism or selection guidance. environment_fit is 1: Nix fit is evident, but Linux/macOS and unfree configuration requirements are not explained.
information_architecture is 2: README has generated package docs and clear grouping. install_notes is 1: only nix run commands are given; Nix installation, unfree licensing, and flake usage are missing. naming_stability is 1: renames/aliases are visible but no naming policy is stated. examples_and_faq is 1: usage examples exist, no FAQ. known_limitations is 0: no limitations are listed. license is 3: the MIT LICENSE is complete and per-package licenses are labeled. versioning_changelog is 1: pyproject shows only 0.1.0 and no changelog. maintenance_responsibility is 1: Numtide copyright and a check-maintainers workflow exist, but no explicit maintainer list is shown and the publisher is unverified.
output_usability is 2: runnable nix run commands and package paths are provided. marginal_value is 2: aggregating many AI coding agents is useful for Nix users. cost_benefit is 1: many unfree/binary/bytecode packages, auto-merge, and unpinned actions add usage and supply-chain costs that offset the benefit.
claim_traceability is 2: README links package.nix and upstream homepages, making key claims traceable. cross_source_corroboration is 1: evidence is limited to README, LICENSE, pyproject, and two workflows; package definitions and tests are absent, so cross-checking is weak. fact_inference_separation is 1: generated descriptions and factual inference are not clearly separated, and some package descriptions appear to be upstream marketing text.
- Not found in source: least-privilege scopingGrant only what the task needs: a dedicated account or read-only token, scoped to specific directories and repos.
- Not found in source: confirmation before actingTurn on (or add) a confirmation step before it acts, and try it in a sandbox or test environment before real data.
- Not found in source: data-flow disclosureWatch which external services it contacts (proxy or firewall logs) and keep sensitive data out until you know where it goes.
- Not found in source: sensitive-data handlingUse dedicated, low-privilege, revocable API keys — never production credentials — and keep secrets out of logs.
- Not found in source: dependency securityPin versions and run a dependency audit (npm audit, pip-audit) before installing; prefer running it in a container.
- Not found in source: disclosed external effectsEstablish which external systems it writes to, sends to or changes, and verify with test accounts or repos before production.
- Not found in source: rollback or recovery pathBack up first, or work on a git branch or snapshot, so its changes can be undone.
- The auto-merge workflow has write permissions on pull_request_target and uses an unpinned action, creating supply-chain and mis-merge risk.
- README lists many unfree, binary, or bytecode packages without sandboxing, data-flow, sensitive-data, or rollback documentation.
- Evidence lacks flake.nix, package.nix, and tests, so buildability, dependency pinning, and update correctness cannot be verified.
- The publisher is unverified, and maintenance responsibility and upstream provenance are not clearly confirmed.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
assets Static Assets