One typed client, two multiplexed planes. Pick the agent; the router places it on your primary sandbox and fails over to backups. Runs stream as normalized events, terminals attach as real PTYs.
Every agent installs through the substrate's own exec and PTY primitives, so a new sandbox inherits all four agents and a new agent inherits all four sandboxes.
01
Install the package
One dependency. Substrate SDKs load lazily, only for routes you use.
npm i agent-machines
02
Drop in one JSON
Keys and routes in agent-machines.json. Missing keys just narrow the route.
Primary first, backups on transient failure. Every attempt is recorded.
mux.create({ agent, sandbox: "auto" })
04
Stream everything
Normalized events from any agent, or a real PTY when you want a terminal.
for await (const event of machine.run(prompt))
ACTIVITY -- 6 MONTHS
148 active days
→tap a cell . click a chip to filter
FEB
MAR
APR
MAY
JUN
JUL
AUG
→filter by agent . 6
lessmore
→filter by service . 23
FAQ
Common questions about Agent Machines.
13 answers
01
Can I run multiple agents for different jobs?
Yes. Provision specialist machines from opinionated presets: Hermes for memory and scheduled work, OpenClaw for browser work, Claude Code or Codex for coding tasks. Each preset bundles runtime, model path, memory, and loadout. One dashboard supervises activity, chat, cron, logs, usage, and artifacts.
02
What is Agent Machines?
Agent Machines is the product layer above sandboxes: a control plane that provisions a persistent agent worker as one unit — runtime, model path, skills, MCP, integrations, cron, observation, and fleet management — on the machine provider you choose. Pick Hermes, OpenClaw, Claude Code, or Codex, then pick E2B, Sprites.dev, Dedalus Machines, or Vercel Sandbox. Provision specialist workers from opinionated presets (Hermes, OpenClaw, Claude Code, Codex). Each preset is runtime + model path + memory bundle + loadout, visible from one fleet dashboard. The dashboard supervises the fleet. The long-term control surface is dashboard for humans, MCP/CLI for agent-to-agent orchestration.
03
How is this different from a regular chatbot?
A regular chatbot mostly returns messages. Agent Machines gives the agent a machine record, runtime root, terminal, filesystem, logs, usage, cron schedules, sessions, artifacts, and installable tools. State lives with the worker instead of disappearing after one request.
04
Which agents can I run?
Hermes, OpenClaw, Claude Code, and Codex are supported. Hermes is the default memory, cron, sessions, and MCP-native runtime. OpenClaw is the computer-use runtime. Claude Code and Codex are task-driven CLIs. All persist state under ~/.agent-machines/.
05
Which providers can host the machine?
E2B Sandbox, Sprites.dev, Dedalus Machines, and Vercel Sandbox are live provider implementations. Each plugs into the same MachineProvider abstraction for provision, state, lifecycle, command streaming where available, and public URLs where supported.
06
How is this different from a sandbox like E2B or Daytona?
Those are machine substrates. Agent Machines is the product layer above them: pick E2B, Sprites.dev, Vercel Sandbox, or Dedalus and get runtime install, loadout, gateway, cron, logs, usage, artifacts, and the browser console in one worker. Provider-specific features like sleep, snapshots, and public URLs are surfaced when the selected lane supports them.
07
How do I get my own machine today?
Sign in with Clerk, add provider credentials in /dashboard/setup, pick the agent, provider, spec, and model, then provision the machine record. The browser flow creates the provider machine and stores it in your fleet; the reliable agent bootstrap path is still the matching root CLI deploy command until browser-driven bootstrap lands.
08
What tools and skills come pre-installed?
The harness ships 161 SKILL.md files, 27 ranked service lanes (MCP → CLI → skills per vendor), 39 MCP catalog entries (2 core + 32 bundled + 4 IDE), 24+ closed-loop CLIs, and 9–23 agent-native tools depending on runtime (Hermes, OpenClaw, Claude Code, Codex). The loadout registry — not static marketing copy — is the source of truth.
09
Is Cursor required?
No. Cursor is optional delegation for code edits through cursor-bridge and @cursor/sdk. Without CURSOR_API_KEY, the rest of the machine still runs: chat, files, browser automation, closed-loop tools, skills, cron, memory, dashboard polling, artifacts, and provider lifecycle controls.
10
What is ~/.agent-machines?
~/.agent-machines is the unified runtime root for Agent Machines. It holds all agent state -- skills, crons, sessions, logs, MEMORY.md, USER.md, config, chats, and artifacts. The repo checkout at /home/machine/agent-machines is used by reload-from-git.sh to sync knowledge from GitHub.
11
What inference providers are supported?
Models can use any OpenAI-compatible /v1 endpoint. The CLI prefers Vercel AI Gateway, then OpenRouter, then configured fallbacks; override with AGENT_CHAT_BASE_URL or configure model.base_url on the machine. The dashboard stores a model slug per machine.
12
What happens when a machine sleeps?
On supported providers, sleep pauses compute while preserving the persistent volume. The next wake resumes from disk: app artifacts, agent runtime state, skills, cron schedules, sessions, and the venv remain available.
13
Where does my data live?
Provider credentials and gateway bearers live in Clerk private metadata. Machine state lives on the provider machine under /home/machine, with all agent runtime data and app state under ~/.agent-machines. The public client only sees redacted provider and machine status.
E2B
Sprites
Dedalus
OpenClaw
Claude Code
Codex