Paste this into your coding agent
How it works
- Anthropic runs the agent loop and the model. Each session you create on a self-hosted environment waits in that environment’s work queue.
- Your Agent37 instance runs
ant beta:worker poll, the environment worker from Anthropic’santCLI. It claims a session from the queue, runs the agent’s bash and file tools in/workspace, and posts the results back. It works one session at a time. - The worker only makes outbound HTTPS calls to
api.anthropic.com. The instance needs no public URL, open port, or webhook.
Before you begin
- An Agent37 API key, exported as
AGENT37_API_KEY. Create one in the dashboard. - A Claude API key, exported as
ANTHROPIC_API_KEY. - Node.js, for the
npx agent37CLI that builds the image. No local Docker is needed.
1. Create a self-hosted environment
Create the environment with the Claude API, or in the Claude Console under Environments > New > Self-hosted:curl
401 Invalid bearer token.
2. Build the worker image
Put thisDockerfile in an empty folder:
Dockerfile
tini reaps the background processes those commands leave behind. The image runs on linux/amd64, which is why it fetches the amd64 build of ant; newer versions are on the ant releases page.
Build it on Agent37 and publish it as a workspace template:
3. Start the worker
Create an instance from the template, with the environment id and key as instance env:curl
running within seconds, and the worker starts polling. Leave auto-sleep off: the worker’s outbound polling does not count as activity, so a sleeping instance stops claiming sessions.
Confirm the worker is connected. workers_polling should read 1:
curl
response
idle; polling for work while it waits, then claimed work and executing tool lines once a session runs.
4. Run a session
Any Managed Agents agent works; nothing in the agent says where its tools run. If you don’t have one yet, create one with the built-in toolset:curl
curl
GET /v1/sessions/$SESSION_ID/events, or stream it; see Anthropic’s events and streaming. The bash tool result shows the command ran on your instance, with the instance id as the hostname:
response
Work with the agent’s files
Everything the agent writes stays on the instance’s disk, across sessions and restarts. Read it from your backend with exec:curl
git clone or curl them into /workspace over exec before you start the session. To watch the agent work, SSH into the instance.
Scale out
- More sessions at once. A worker holds one session until a minute after its turn ends (the
--max-idleflag, default1m), so the next message in a conversation continues without going back to the queue. Other sessions wait their turn. To run several at once, create more instances from the same template with the same env: every worker on an environment polls one queue, and each session goes to the first free worker. A later message on a session that was let go queues again and runs on whichever worker is free. - Heavier tools. Resize the instance for more CPU, memory, or disk.
- Separate customers. Sessions on one instance share its disk. When customers must not see each other’s files, give each one its own self-hosted environment and instance.
- Memory stores. The
antworker doesn’t mount memory stores. If your sessions attach them, replace theENTRYPOINTwith the Python, TypeScript, or Go SDK’sEnvironmentWorker; see Use memory stores.
One instance per session
To give every session its own computer, claim the work yourself instead of runningant beta:worker poll. A small orchestrator on your server long-polls the environment’s queue with the Anthropic SDK’s WorkPoller, creates an instance with auto_sleep: true for each new session, and starts ant beta:worker run on it over exec, which wakes the instance if it is asleep. The session’s files stay on its instance between turns, the instance sleeps and bills disk alone while nobody is talking to it, and sessions run in parallel, one per instance.
The claude-managed-agents example is a complete orchestrator in about 100 lines of Node.js, with a chat script and a parallel-sessions demo.