Beam gives agents compute with an explicit lifecycle

Beam provides cloud compute for agents and AI applications through persistent virtual machines, disposable sandboxes and deployable endpoints. These options solve different problems: maintaining a development environment, isolating a short-lived task or serving a model behind an API. The practical decision is which lifecycle matches the work. An environment that should survive an interruption needs different storage and billing assumptions from a temporary function call.

01 / ProductThree execution patterns on one platform

The Beam introduction presents persistent VMs, sandboxes and endpoints as distinct starting points. A VM supports work that benefits from an enduring machine. A sandbox gives an agent a disposable execution environment. An endpoint turns application code into a callable service. These are complementary tools, not interchangeable labels for the same resource.

The VM documentation describes durable root storage, SSH and persistent connection options. Current VMs are CPU machines; the documentation directs GPU workloads to sandboxes or endpoints. This matters when a demonstration of a coding agent and a demonstration of model inference appear on the same platform: they need not use the same compute product.

The company page frames Beam around reducing infrastructure work for AI developers. Its public offer still requires engineering decisions about images, secrets, storage and networking. A convenient SDK can simplify resource creation, but it does not decide whether a task should be persistent or disposable, or which data the agent should be allowed to access.

02 / AudienceFor workloads with a clear reason to leave the laptop

Beam is useful when an agent needs an isolated machine, a long-running environment or hardware unavailable locally. A development task may need a prepared repository and dependencies that survive across sessions. A document-processing job may need a short-lived sandbox. A model-serving application may need GPU capacity that expands with demand.

A team should be able to explain which of those needs it has. Moving a trivial local script into managed compute can add deployment and networking work without improving the outcome. Conversely, running an unbounded agent on a developer’s everyday machine may give it much broader access than the task requires. The environment choice should follow the workload and trust boundary.

The E2B blueprint is a relevant comparison for agent sandbox execution. The Modal blueprint helps assess programmable compute and model-serving workflows. Beam’s particular proposition is the combination of different execution lifecycles under one platform. Compare the resource type that matches your task rather than treating every provider’s lowest advertised rate as equivalent.

03 / WorkflowA proposed coding task tests pause, recovery and cleanup

Consider a proposed pilot in which a coding agent investigates a test failure in an isolated repository. Create a persistent VM with only the project, required dependencies and narrowly scoped credentials. Record the starting revision and ask for a bounded diagnosis and patch. Keep deployment secrets out of the environment if the task is only to prepare code.

The lifecycle guide distinguishes stopping from pausing. Stopping preserves disk but discards memory and running processes; pausing preserves both for resumption. Choose deliberately. If the task depends on an expensive in-memory setup, pause may be useful. If the application should restart cleanly from files and configuration, stopping can expose missing setup assumptions.

Inspect the patch and tests before accepting the result. Then pause and resume the environment to check that the expected state remains. Finally remove the temporary resource or configure a bounded idle policy. The experiment should establish that both work and cleanup are understandable. This is a proposed test of the workflow, not a claim that Beam has run a verified repair for Sequenced.

For a different task, such as evaluating generated code against a fixed fixture, a sandbox may be the better unit. Its disposable lifecycle lets each attempt begin from a defined image or snapshot. Persist only the outputs that matter, such as the patch and test result, rather than relying on the sandbox’s temporary filesystem as the sole record.

For an application endpoint, use the endpoint guide instead. It distinguishes synchronous endpoint work from longer asynchronous task queues. An agent workspace and a production inference API have different failure and latency requirements; carrying the development environment directly into service without revisiting those requirements is a poor evaluation shortcut.

04 / PricingRead credits, runtime and storage as separate meters

The current Developer price differs from older cached search results showing a zero-dollar plan. The live page and billing guide describe monthly credits that expire, while extra purchased credits do not. A prepaid workload can stop when the available balance is exhausted. Account for that behaviour when the workload is expected to remain available.

For serverless containers, billing includes application startup code, request execution and configured warm time. It excludes waiting for a machine and pulling the image. Reserved machines follow a different lifecycle: they remain billable until released, including idle periods. These distinctions mean that a request-based estimate can understate the cost of a service kept ready between requests.

The endpoint documentation also says a development serve session is billable throughout its duration, even without requests. Development activity therefore belongs in the budget. Compare the dashboard with a known trial period and verify which resources remain active when the developer closes a terminal or stops sending traffic.

05 / DistinctionsPersistence is a product feature with consequences

Beam’s pause/resume model is useful when an agent benefits from retaining an environment between bursts of work. A persistent filesystem can keep a repository, toolchain and generated artefacts together. Preserving process memory can avoid rebuilding temporary state. The value is specific to the workload: persistence that helps one task can carry unwanted state into another.

The VM lifecycle documentation makes these states explicit enough to design around. An engineering team can decide when to pause, stop or delete instead of treating every interruption as a fresh deployment. That should be paired with a clear record of which files need durable version control and which state can be discarded.

GPU execution remains a separate decision through sandboxes or endpoints. That separation can be useful for an agent that orchestrates a heavier inference job without requiring its entire development VM to be GPU-backed. It also creates another boundary to observe: the agent’s request, the GPU task and the persisted result should be traceable as parts of one workflow.

06 / QuestionsConfirm what survives and what stays reachable

The first uncertainty is persistence. Test what survives each lifecycle transition, including attached storage, processes and credentials. Do not infer that a snapshot is a complete backup strategy for the application. Source changes should still be committed, and important output should be exported to an intended durable destination.

The second is access. A sandbox or VM is a useful isolation unit, but its actual reach depends on mounted files, secrets, exposed services and network policy. A task that only needs to run tests should not inherit broad infrastructure credentials. Check the environment with a benign access test before giving an agent a long chain of tool operations.

The third is the interaction between cost and readiness. An idle policy can reduce spend but interrupt a workflow whose notion of inactivity differs from the platform’s. A warm endpoint can improve response time while continuing to consume resources. Test these behaviours at the expected cadence of work. The right setting for a busy API may be wrong for an agent that works briefly several times a day.

07 / DecisionChoose the smallest lifecycle that preserves the work

Beam is worth evaluating when an application needs managed compute and the team can define the intended resource lifecycle. Start by choosing persistent VM, disposable sandbox or serving endpoint. Then verify state, access and billing together. That produces a stronger decision than a comparison based only on accelerator names or headline hourly prices.