Beam vs boxd (2026)

Code on Beam reaches other systems through what the customer writes. Secrets hold credentials, S3 buckets mount into apps and custom registries supply images. Task callbacks POST results to the customer's server, and sandbox ports expose services. Beam has no catalog of connectors, OAuth actions or tool gateway of its own, and the tools are the customer's code.

Sourcedocs.beam.cloud/llms.txtread 2026-09-22

Agents on a machine act in outside systems through 128 integrations, including GitHub, Linear, Slack, Notion, Jira, Salesforce, HubSpot, Stripe and Zendesk, each with typed tools such as creating an issue or sending a message.

A person connects an account once through the provider's consent screen, personally or as a shared connection for the whole organization, and the platform then makes each call on the machine's behalf, so the credential never enters the machine.

The in machine run CLI and the @boxd/run SDK call these tools, and scripts reach any other API, database or cloud account with ordinary libraries.

Sourcedocs.boxd.sh/guides/integrations/connectionsread 2026-11-05

An agent framework ships in the SDK (Bot, BotLocation, BotContext) and is built on a Petri net model. Locations hold typed state, and transitions consume inputs from locations and write outputs to others. Transitions can be driven by a model or by plain code, run concurrently in isolated containers and keep state synchronized between them. Task queues add retries and timeouts, and map fans work out. Deterministic steps mix with agent steps, and branching and retries are built in. Beam says it is launching the framework and does not say how mature it is beyond the example it gives.

Sourcedocs.beam.cloud/v2/agents/introductionread 2026-09-22

Background jobs give automations a managed lifecycle.

A script that registers a schedule or trigger runs as a job that survives reboots, waits for a missing connection instead of failing, and restarts with exponential backoff for up to five attempts before it is marked failed. boxd's fan out pattern has a coordinator create one machine per worker, run a coding agent headless in each and let a lead agent merge the reports, and a fork brings a machine's jobs along paused so nothing runs twice.

The sequencing, branching and hand offs in that pattern are code the customer writes against the SDK, and boxd has no workflow graph, step model or multi agent runtime of its own.

Sourcedocs.boxd.sh/guides/automations/jobsread 2026-11-05

The schedule decorator runs a deployed job on a schedule, and web endpoints and task queues boot containers from zero when requests or tasks arrive. One app can send events to another through signals, for example to reload a model when retraining finishes. Task callbacks also notify the customer's server when a task finishes.

Sourcedocs.beam.cloud/v2/function/scheduled-jobread 2026-09-22

Work reaches a machine on schedules, events and inbound requests. An automation registers durations or cron expressions with every() and subscribes to integration events with .on(), such as a new Linear issue or a pull request through the boxd GitHub App, and 36 integrations emit triggers.

The platform holds the next due time and wakes a hibernated machine shortly before it, holds events that arrive while a machine wakes for up to 15 minutes, and fires a missed cron slot once on wake. A hibernated machine also wakes on the next HTTPS request, so an agent served from it answers webhooks at its own address.

Sourcedocs.boxd.sh/guides/automations/scriptsread 2026-11-05

Any retrieval system on Beam is one the customer builds. Beam maintains no retrieval structure of its own over the customer's content for an agent to query. Volumes, durable disks, Maps and mounted S3 buckets store data but return no search results, and nothing Beam provides indexes, refreshes or permissions the customer's sources.

Sourcedocs.beam.cloud/llms.txtread 2026-09-22

No retrieval index, vector store or knowledge base over the customer's content comes with the platform. Files on a machine's disk, standalone disks that outlive a machine and data sets saved into a snapshot are storage the agent's code reads, not an index a query returns. Tools such as Notion, Confluence or Google Drive are searched through their own integrations, and any grounding layer is something the customer installs on the machine.

Sourcedocs.boxd.sh/llms.txtread 2026-11-05

State carries across runs. Sandbox snapshots capture filesystem and memory as an immutable artifact to fork from or restore, and distributed volumes and durable disks on each node persist data. Distributed Queues and Maps share it across tasks, and the agent framework synchronizes state between transitions, so an agent's code can read that state and carry on. Snapshot state is the machine's own state, which a customer can restore or delete but not review or edit. Beam names no memory layer for agents.

Sourcedocs.beam.cloud/v2/sandbox/snapshotsread 2026-09-22

Machines keep their working state between sessions. A machine on standby resumes in under a millisecond and a hibernated one wakes with its memory and processes intact, and coding agent sessions live on the persistent disk, so a job delegated in the morning can be resumed interactively later. Forks, checkpoints and snapshots copy or rewind that state.

Automations also get object(name), a named JSON store written on every assignment and restored on the next run, meant for cursors, dedup sets and counters. All of it is machine and script state the developer manages, with no memory layer of stated scope and lifetime that a buyer can review, edit or delete as memory.

Sourcedocs.boxd.sh/guides/automations/scriptsread 2026-11-05

For work running on Beam, including agents built with its framework, Beam names no approval step, consent checkpoint or escalation to a person. The platform isolates workloads with containers per customer, network separation and scoped secrets.

Sourcedocs.beam.cloud/v2/security/securityread 2026-09-22

A person can step into an agent's work while it runs. Every machine has a live desktop in the browser where its owner watches the agent's browser, takes over the keyboard to enter a password, solve a captcha or fix a form, and hands control back without stopping the agent. The preinstalled coding agents are told to share that desktop link whenever they need someone, so a login or approval happens in the browser the agent already opened. There is no approval gate, pause primitive or policy that holds an agent's action until a person reviews it.

Sourcedocs.boxd.sh/guides/desktopread 2026-11-05

A SOC 2 Type II audit by Advantage Partners covers Beam, with the report under NDA, and Beam offers HIPAA BAAs for Enterprise customers and a GDPR DPA. Data is encrypted in transit and at rest, and containers and networks are isolated per customer. The customer scopes, rotates and deletes its encrypted secrets, and workspace API tokens can be created, rotated and revoked. All members of a workspace currently have the same permissions, and single sign on is not yet available.

Sourcedocs.beam.cloud/v2/security/securityread 2026-09-22

Organizations have three roles. Members use shared machines and create org billed ones, admins also invite and remove members, change roles, set defaults, create teams and revoke org API keys, and the single owner can demote admins. Admin invites need an interactive login, so an API key or a token minted inside a machine cannot send one.

People sign in with GitHub or Google, with SAML single sign on offered to enterprise customers on request. A DPA is available, and SOC 2 Type II and ISO 27001 are both in progress, not held. Each machine is a KVM microVM with its own kernel, and egress allowlists and host bound secrets are enforced on the host, outside the machine.

Sourcedocs.boxd.sh/guides/organizationsread 2026-11-05

Application logs are kept 30 days on Developer and Team plans and one year on Growth, and log export is included. Task status can be queried by ID, with callbacks on completion. Prompts, tool calls, retrieved knowledge and outputs can be inspected step by step only as far as the customer's code logs them. Beam names no audit log of workspace actions separate from the runtime logs.

Sourcebeam.cloud/pricingread 2026-09-22

Automations are visible and the agent's own steps are not. The console's Automations page lists every background job with its triggers in plain English, the integrations it uses, its state, last run and last error, plus a generated write up and flow diagram for each script, and run logs prints or follows a job's log from inside the machine. Regional uptime and incidents appear on a public status page. A coding agent's prompts, tool calls and outputs are not traced by the platform, and no audit trail of member actions is offered.

Sourcedocs.boxd.sh/guides/automations/jobsread 2026-11-05

There are three ways to run Beam. The managed cloud runs on AWS and Google Cloud. With bring your own cloud, Beam runs the control plane and compute in the customer's AWS or GCP account for a flat management fee, and the compute bills to the customer's cloud. The pricing plans add Azure as a bring your own cloud option.

Beta9, the engine that powers Beam, is open source under AGPL 3.0 and can be self hosted on a local machine or Amazon EKS. Compute pools can also run Beam workloads on the customer's own machines. The beta9 repository is actively maintained. Beam names no region selection for the managed cloud.

Sourcedocs.beam.cloud/v2/self-hosting/overviewread 2026-09-22

Each machine runs in Frankfurt or New York, picked per machine from the CLI, console or SDK or set as an organization default, and its disk, memory, snapshots, checkpoints and backups stay in that region on Latitude.sh bare metal. Scale customers can have boxd operate the cluster inside their own cloud account, and the same release self hosts on AWS, Google Cloud or any KVM host, free up to 16 worker vCPUs and licensed above that, with air gapped installs supported. boxd gives conflicting accounts of its US region, with New York live in some places and coming soon with a waitlist in others.

Sourcedocs.boxd.sh/guides/regionsread 2026-11-05

Ready made starting points ship as end to end examples for model serving (Llama, DeepSeek, Qwen and Hugging Face models, plus an OpenAI compatible vLLM server), for media (ComfyUI, Whisper and text to speech), and for fine tuning and web scraping, plus a research assistant agent built on the agent framework. Developers build from these examples, and Beam offers no browsable catalog of agents a customer can adopt as they are.

Sourcedocs.beam.cloud/v2/examples/overviewread 2026-09-22

Machines arrive with Claude Code, Codex and OpenCode installed and configured through an instructions file that teaches each agent the platform, plus three preinstalled skills covering the in machine CLI, automations and the desktop, and a CLI skill for the laptop.

Guides walk through development workspaces, preview environments, CI runners, personal assistants, sandboxes, agentic SaaS, RL environments and agent swarms, and connectors exist for open source tools such as TanStack AI, Pydantic AI, Harbor and Scale AI AgentEnv. These are configured third party agents and recipes a developer builds from, not prebuilt agents of boxd's own.

Sourcedocs.boxd.sh/use-cases/coding-agentsread 2026-11-05

Customers choose the model, and Beam runs any model on the GPU the customer picks. Examples serve Hugging Face models such as Llama 3.1, DeepSeek R1 and Qwen through vLLM, including an OpenAI compatible vLLM server, or through SGLang, and others fine tune Gemma and Llama. Customers can bring their own deployments and providers.

Sourcedocs.beam.cloud/llms.txtread 2026-09-22

The customer decides which agents and models run. Claude Code and Codex use the customer's own subscription, signed in once and served to every private machine in the organization, or an API key stored as a secret, OpenCode signs in on each machine, and any other agent or model that runs on Linux can be installed. boxd adds no model of its own and does not route between providers, and it does not use customer data to train or improve any model.

Sourcedocs.boxd.sh/use-cases/coding-agentsread 2026-11-05

Outside callers reach Beam through Python and TypeScript SDKs, a CLI, and a REST API with published Swagger specifications for the gateway and pods, covering tasks, pods and sandboxes. Web endpoints expose the customer's code as HTTP APIs, the open source Beta9 engine can be extended, and a docs MCP server serves Beam's documentation to coding tools.

Sourcedocs.beam.cloud/llms.txtread 2026-09-22

Outside code drives the platform through TypeScript and Python SDKs, a gRPC API whose full api.proto service definition is public for generating stubs in any language, and a CLI that returns JSON from its commands. Each region has its own API endpoint, and organization API keys keep working after the person who created them leaves. The SDKs cover machines, forks, snapshots, checkpoints, disks, egress, secrets, domains, organizations and teams, and a filesystem API reads and writes files inside a machine from code.

Sourcedocs.boxd.sh/reference/grpc-apiread 2026-11-05

Code, experiments and fine tuning jobs run on Beam with retries and logs. Beam names no fixtures, scoring or quality gates for a customer's agent workflows, and no way to compare agent runs.

Sourcedocs.beam.cloud/llms.txtread 2026-09-22

There are no test cases, scoring or quality gates for an agent's behavior. The platform is where evaluations run, not how they are scored. Forks give every reinforcement learning rollout or benchmark trial a byte identical starting state, Moyai ran 279,577 Harbor benchmark machines on it, and a reproducibility check compares two forks run with the same seed, but rewards, datasets and scoring belong to the customer's own framework.

Sourcedocs.boxd.sh/use-cases/reproducible-rl-environmentsread 2026-11-05

Sandboxes run any code with GPUs, networking and storage and can expose ports for web services. Beam names no browser or desktop for an agent to operate and no API for screenshots, clicks or typing.

Sourcedocs.beam.cloud/v2/sandbox/overviewread 2026-09-22

Agents drive a real browser on the machine's own desktop. Every machine ships a browser automation CLI built for agents, backed by Chromium with anti bot fingerprinting and a persistent profile so logins stick, and scripts get the same browser through Playwright. A machine can also drive a Chrome window on the user's laptop over the DevTools protocol, for sites that only accept the user's own network, and the preinstalled agents get a browser tool for it automatically. Any GUI app installed on the machine opens on the same desktop.

Sourcedocs.boxd.sh/guides/launch-a-browserread 2026-11-05