Can I run multiple agents for different jobs?

Yes. Save starting configurations for coding, research, browser tasks, and other workflows. Each preset suggests a runtime, instructions, and selected abilities. Connect credentials and install the tools you need before running it. One dashboard shows your machines, terminals, files, logs, and usage.

What is Agent Machines?

Agent Machines provides open-source building blocks for agent harnesses: runtime adapters, sandbox providers, browser terminals, editable instructions and memory, skills, and MCP configuration. Start from a preset or assemble your own setup, run the actual agent CLI, and manage remote agents from one dashboard. Inspect, modify, and extend the source as your workflow changes.

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.

Which agents can I run?

Claude Code, Codex, Hermes, and OpenClaw have runtime adapters. You can use the actual native CLI in a browser terminal or use managed execution. Native tools, model paths, and session formats vary by runtime; selecting a runtime does not install every integration in the catalog.

Which providers can host the machine?

Daytona, E2B Sandbox, Sprites.dev, and Vercel Sandbox. Daytona stop/start retains files but restarts processes; E2B supports pause/resume; Sprites manages idle suspension; Vercel resumes from filesystem snapshots. Each provider exposes only the lifecycle and terminal operations it supports. Historical benchmark results do not establish Daytona performance.

How is this different from a sandbox like E2B or Daytona?

Those supply compute. Agent Machines adds runtime setup, editable instructions and memory, tool configuration, terminals, files, and logs. You can reuse and modify the open-source adapters instead of rebuilding this layer. Provider-specific features such as pause, snapshots, and preview URLs remain available only where supported.

How do I get my own machine today?

Sign in and add provider and model credentials in Settings. Open Starter setups, preview a preset, and save it. Review its configuration and provision a machine when ready; saving a setup alone does not launch compute. Quick launch on the overview creates a machine directly. Compute and inference use your connected accounts.

What tools and skills can I add?

The source includes 161 SKILL.md entries and 39 MCP catalog entries, plus CLI and service guides. These are available building blocks, not a promise that every tool is installed, authenticated, or compatible with every runtime. Preview and select abilities, connect the required services, then use the dashboard installation controls. Runtime-native tools vary by agent.

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.

What is ~/.agent-machines?

~/.agent-machines holds Worker configuration, canonical memory, skills, schedules, logs, chats, and artifacts. Native runtimes also keep their own state directories. The ~ prefix means the sandbox user's home: /home/daytona, /home/user, /home/sprite, or /vercel/sandbox. Knowledge updates use ~/.agent-machines/knowledge-source, separate from the Worker's project at ~/agent-machines.

What inference providers are supported?

Compatibility depends on both runtime and interface. The hosted dashboard uses native Anthropic for Claude Code and native OpenAI for Codex; Hermes and OpenClaw expose supported router or native-compatible paths. The direct mux SDK has a separate upstream map: Claude Code and Codex support native keys, OpenRouter, and Vercel AI Gateway; Hermes uses native Anthropic or OpenAI. An arbitrary endpoint is not guaranteed to work with every runtime.

What happens when a machine sleeps?

The behavior is provider-specific. Daytona stop/start retains files but restarts processes. E2B supports pause/resume. Sprites manages idle suspension rather than manual sleep. Vercel uses filesystem snapshots with bounded sessions. Moving files between providers does not migrate live process memory or guarantee that a native conversation can resume unchanged.

Can I share or customize a setup?

You can fork the MIT-licensed source, reuse direct SDK configuration files, bring your own skills, and export memory documents as Markdown. Full executable setup import/export, a public marketplace, and a copy-into-app component installer are not available yet. The shadcn analogy describes the source-first design principle, not an existing shadcn integration.

Where does my data live?

Provider credentials and model keys are stored privately for your account. Worker configuration and history also use the hosted data store; workspace files and runtime state live in the selected sandbox user's home, including ~/.agent-machines. The public client receives redacted credential and machine status.

Product

Your agent setup. Built from open parts.

Real agent runtimes, your tools, and a remote workspace. Configure each layer in the dashboard or adapt the open-source implementation.

Build your setup Read docs

MIT source
Runtime adapters
Your credentials
Real CLIs

The configurable layers · overview

runtime: hermes | openclaw | claude-code | codex
provider: e2b | sprites | daytona | vercel
model: supported router profile or native key
loadout: skills + MCP + CLI + cron
observe: logs + usage + artifacts

The building blocks

Use the parts you need.

Configure each layer in the dashboard, or change its source.

Agent runtimesClaude Code · Codex · Hermes · OpenClaw Sandbox providersDaytona · E2B · Sprites · Vercel Sandbox Models & credentialsNative keys · OpenRouter · Vercel AI Gateway Skills & toolsSKILL.md · MCP servers · CLI packages Instructions & memoryEditable documents · Markdown export · Explicit install Remote workspacesLive terminal · Files & logs · Streaming API

Explore the component guide

The Worker system

Keep the Worker.
Swap the machinery.

Give your Worker a job. Its identity, memory, files, and schedules stay with it as you change the runtime, model, tools, or cloud provider.

Your Worker is more than a chat session.

One lasting WorkerFour replaceable layers

Animate engine

Scroll to explore the engine. Every layer connects to your Worker.

The durable coreYour Worker

IdentityMemorySchedulesFilesHistoryEvidence

Same identity. Saved context.

Agent runtime

Sandbox provider

Models & routing

Tools & skills

Agent runtime

Choose how it works.

Claude Code
Codex
Hermes
OpenClaw

Sandbox provider

Choose where it runs.

Daytona
E2B
Sprites
Vercel

Models & routing

Connect the intelligence.

Anthropic
OpenAI
Routers
Custom API

Tools & skills

Give it the right abilities.

Skills
MCP servers
CLI tools
Connections

The Worker keeps its saved state; each provider supplies its own capabilities. Migration transfers files and restarts managed work—not live process memory.

Give it a responsibility.

Set the job, connect its tools, and define its permissions.

Run it on your terms.

Choose a runtime and provider without rebuilding the Worker.

Come back to its work.

Review saved files, logs, and results from the dashboard.

Inside the product

Configure. Run. Inspect.

Follow a Worker from its first configuration to the sessions, files, and activity you can inspect.

Recorded product views, not live status. Versions may differ.

Configure

Worker configuration dialog with a name, runtime, and specialist recipe — Worker configuration
View full size
A specialist, an agent, and a place to run.

Earlier provider-routing screen with primary and backup choices, including the now-retired Dedalus provider — Provider routing
View full size
Primary and backup providers. This older capture includes retired Dedalus; current providers appear below.

Run

Claude Code answering a question inside an Agent Machines Worker console on Sprites — Claude Code on Sprites
View full size
Conversation, terminal, and logs in one workspace.

OpenClaw answering a question about its runtime and persistent state inside an E2B Worker — OpenClaw on E2B
View full size
The selected model and stored context, in the session.

Hermes running in the Agent Machines browser console — Hermes console
View full size
The native agent, inside your browser.

Codex CLI running in the Agent Machines browser terminal — Codex CLI console
View full size
Your project and terminal, attached to the Worker.

Inspect

Agent Machines fleet showing Codex and Claude Code Workers and their machine controls — Fleet overview
View full size
Providers, models, health, and controls—with sessions, logs, and artifacts one step away.

Worker capabilities

Build a Worker. Run a fleet.

Choose the agent. Give it tools and a place to work. Then manage its sessions, schedules, files, and activity from one dashboard.

Agent runtimes: 4
Sandbox providers: 4
Skills: 161
MCP servers: 39

Start with the job.

Choose a specialist, connect its tools, and decide how it should run.

Illustration · Not live data

Agent

Hermes

Model connection

OpenAI

Sandbox

E2B

Saved recipe

Research Worker

MemoryToolsSchedule

Worker recipes

Save an agent, model, memory, tools, and schedule together as a reusable specialist template.

One reusable Worker recipeExplore

Choose your agent

Run Claude Code, Codex, OpenClaw, or Hermes from the same dashboard.

4 agent runtimes

Choose where it runs

Launch on E2B, Sprites, Daytona, or Vercel Sandbox, with compatible backup providers for launch failures.

4 providers · Primary and backups

Connect your models

Bring native API keys, OpenRouter, Vercel AI Gateway, or a compatible custom endpoint.

Your models, your credentials

Keep work moving.

Manage the machine, schedule recurring work, and move providers when you need to.

Illustration · Not live data

Pause

Running

Paused

Resume

Where the provider supports it

Operation journal

Requested
Progress
Result

Machine lifecycle

Launch, configure, repair, and retire a Worker through tracked operations. Pause and wake are available where supported.

Track each step from request to resultExplore

Pause and resume

Pause supported machines and resume from persistent files when work is needed again.

Availability depends on the provider

Recurring jobs

Schedule prompts and commands, then inspect when they ran and what happened.

Saved schedules and run history

Move between providers

Drain managed work, copy durable files and state, then cut over while keeping the Worker's identity.

Not a transfer of running processes or RAM

Work right alongside it.

Open the real agent, follow its progress, and inspect what it produces.

Illustration · Not live data

Worker terminal

codex

Summarize the notes.
Save a report.md file.

Saved session

Prompt and history

report.md

Artifact

Same Worker · linked context and outputs

A real terminal, in your browser

Use the agent's own command-line interface on the remote machine, with a terminal session you can reconnect to.

Worker-owned terminal sessionsExplore

Chat and streaming commands

Send a prompt or run a command and follow output as it arrives, with streaming where supported.

Prompts, commands, and progress

Logs and sessions

Return to saved conversations, review command history, and inspect the machine's logs and activity.

Context beyond a single browser tab

Files and artifacts

Find reports, screenshots, and other outputs beside the Worker that made them. Inspect its installed runtime, too.

See the work, not just the answer

Give it the right tools.

Add repeatable procedures, connected services, and context worth keeping.

Illustration · Not live data

SKILL.md

Memory

Worker loadout

GitHub

Slack

Playwright

Connections require configuration and their own credentials.

Reusable skills

Give a Worker written procedures it can use again, stored as versioned SKILL.md files.

161 synced skillsExplore

Connected tools and services

Configure MCP connections and service routes with the credentials each needs. Add Cursor delegation when available.

39 MCP servers · 27 service routes

A searchable tool catalog

Search the MCP registry, skills.sh, npm, Cursor plugins, GitHub, and URL manifests.

2,595 audited items

Memory and tool bundles

Keep instructions, agent docs, skills, and tool configuration together in a portable loadout.

Context that belongs to the Worker

See the whole fleet.

Know what's running, review activity, and compare providers using evidence.

Illustration · Not live data

Dashboard

SDK

CLI

Worker	Agent / provider	State
Research	Hermes Daytona	Running
Build	Codex E2B	Paused
Review	Claude Code Vercel	Stopped

Recorded activity. Unknown usage stays unknown.

One view of your Workers

See each Worker's agent, provider, status, tools, and recent activity without juggling separate provider dashboards.

Your fleet, in one placeExplore

Usage and activity

Review recorded activity and sampled compute usage. Missing measurements stay unknown; cost estimates are labeled.

Machine-level and fleet-wide views

Provider benchmarks

Compare recorded startup, resume, command latency, and compute tests across providers.

Measured results, not a speed promise

SDK, API, and CLI

Manage Workers from your own code with TypeScript, REST, and command-line tools.

Built for people and software

Keep the important parts.

Preserve context and files, scope credentials, and make recovery visible.

Illustration · Not live data

Account boundary

Saved credentials

Server-side

Settings

Configured

Presence, not secret values, is returned to settings.

Process memory Pause behavior is provider-dependent

Persistent files

Memory · sessions · outputs

Files and context that persist

Keep the Worker's memory, runtime files, sessions, schedules, and outputs in its persistent storage.

~/.agent-machinesExplore

Scoped credentials

Check credential presence and model compatibility before launch. Saved account secrets are stored server-side, not returned in settings.

Preflight is not vendor credential validation

A record of every operation

Follow lifecycle requests through a durable journal, with recorded failures and recovery steps.

Inspect progress and failures

Know what survives a pause

See the provider's actual persistence and pause capabilities. Persistent disk does not automatically mean preserved process memory.

Capabilities stay explicit