SuperAPI AI Directory

amux

amux is an open-source control plane for AI coding agents, implemented as a single Rust binary that provides a local-first, self-hosted management service with SQLite storage. It lets multiple parallel workers (Claude Code, Codex, Gemini CLI, OpenCode, Ollama) collaborate on the same board: atomic task claiming uses compare-and-swap to avoid duplicate card pickup, completion requires evidence, and verification requires peer review; workers can sense team status, view each other's terminals, and send messages with source tagging; it supports input into running sessions from the web or phone for mid-course correction, provides cron-style scheduled prompts and autonomous loops, groups and scopes, switching models while running, a message history ledger, and a self-healing watchdog that automatically compacts, restarts crashed sessions, and replays the last message. The install script checks for prerequisites such as the Rust toolchain and tmux, builds the workspace, and installs the server and CLI to ~/.local/bin, configuring launchd on macOS and creating a user service on Linux systemd distributions, generating the database, TLS, and auth token on first launch. Licensed under MIT + Commons Clause, it can be used, modified, and self-hosted for free; commercial resale requires a separate license.

Open website

About this tool

amux is an open-source control plane for AI coding agents, with the goal of organizing multiple parallel coding agents into a coordinated "AI engineering team" and operating it through a web dashboard or phone. The project uses a local-first, self-hosted architecture, stores data in SQLite, and is delivered as a single Rust binary.

The main capabilities revolve around shared collaboration. Task claiming on the shared board is an atomic operation using compare-and-swap, so two workers will not grab the same card; tasks require evidence to be "complete" and peer review to be "verified". Every worker can see who is online in the team, what each is responsible for, what they are doing, and can view a peer's terminal before interrupting them. Workers can @ each other with source-tagged messages, and the server records the real sender so the source can be verified. Users can input directly into any running session from the dashboard or phone, enabling mid-task correction without stopping the run. For scheduling, it supports cron-style recurring prompts (e.g., every day at 9 a.m., every 15 minutes) and self-paced autonomous loops for overnight runs. Workers can be organized into grouped channels that share memory, environment, and gates, with configuration resolution order card → worker → group → global. Running workers can switch models or providers, choosing a model per task while preserving context. All prompts, replies, and deliveries are stored as ledger records for later querying. A self-healing watchdog can automatically compact, restart crashed sessions, and replay the last message.

The system is built from eight foundational primitives: board (shared board with atomic claiming, type and status gates), workers (parallel agent sessions, using tmux by default, with persistent identity), schedulers (cron-style periodic and one-off tasks with audited run history), filesystem (browse, edit, and search worker working directories, including a file viewer and media pipeline), groups (worker tags used for scoping visibility, gates, memory, and environment), memories (hierarchical instructions and knowledge from global → group → worker), environment (similarly hierarchical environment variables controlling which third-party APIs workers can access), messages (text between workers and between humans and workers, delivered at turn boundaries). Scoped configuration read/write uniformly goes through GET/PUT /api/scope.

Usage centers on the single-command install script described above. The script checks prerequisites (Rust toolchain, tmux, prompting for confirmation before installing anything), builds the workspace, and installs the serverand the CLI are installed to ~/.local/bin, a launchd agent is loaded on macOS, ~/.amux is generated on first launch (database, TLS, auth token), it waits for /health to be ready, and prints the access address https://localhost:8824,接受一次自签名证书警告后即可从仪表盘添加第一个工作器。重复运行 install.sh upgrades in place without touching data; uninstall.sh removes the binaries and agent but keeps ~/.amux. Everyday commands include make run (rebuild the release and install after pulling code, with the launchd-managed service taking over automatically) and make dev (for migrations or feature development, avoiding impact on the production database). Requirements are tmux 3.2+, plus at least one of Claude Code, Codex CLI, or Gemini CLI. On Linux, on distributions with systemd (Ubuntu 22.04+, Debian 11+, Fedora 36+), the install script automatically creates and enables three user-level services: amux-server.service, amux-builder.service, and amux-builder.timer; distributions without systemd require running the services manually.

The project also provides .mdai computational Markdown files: these are DAG nodes whose values are produced by a model, connected via sources in YAML frontmatter to files, folders, other .mdai files, or amux:messages live sources, with each connection carrying its own prompt and the body serving as the synthesis instruction; opening a node runs the entire chain upstream-first and depth-first, with cycle detection and input hash caching, and each open records a run history. The default model is the fastest Claude model (currently Haiku 4.5), overridable per file via model: or via AMUX_HELPER_MODEL. The command-line client amux-rs looks up the server in the order --url, $AMUX_RS_URL, $AMUX_URL, falling back to https://localhost:8824;看板变更遵循状态门禁,遇到 409 prints a checklist and the exact retry command.

Limitations and caveats: the project uses the MIT + Commons Clause license, so it is free to use, modify, and self-host, but commercial resale requires a separate license. The herdr terminal backend is not covered by CI; its tests simulate process boundaries, so a green build only proves the backend selection rather than the integration itself; the long-term direction is to replace terminal scraping with a structured AgentProtocol. On macOS, several system app operations are gated by TCC permissions; without the corresponding authorization, features will hang or fail silently rather than raise an error. Commercial pricing, hosted services, or support for other platforms are not yet available.