Modal Pricing: Sandbox Rates, Credits, and Agent Costs

Do not index

Modal pricing for CPU Sandboxes starts with two meters: $0.00003942 per physical core per second and $0.00000667 per GiB of memory per second. Charges follow the greater of requested or actual resources, so a peak-size estimate can overstate an elastic workload's bill. Agent37 is worth comparing when you need inexpensive persistent agent infrastructure, with separate standard gVisor and full VM prices.

The useful question is what your agent will cost while installing dependencies, running tests, waiting for a model, and keeping its files between sessions. Those phases can consume very different resources.

This guide focuses on Modal Sandboxes for agent execution. Rates and documentation were checked October 31, 2026. The examples are calculations, not measured performance results, and exclude model tokens, taxes, and unrelated services.

Modal pricing uses different rates for Sandboxes and Functions

Use the Sandbox section of Modal's pricing page. Its standard Function CPU and memory rates are lower. CPU Sandboxes use non-preemptible pricing, described as a threefold multiplier, with these published rates:

Resource	Sandbox rate	Hourly conversion
CPU	$0.00003942 per physical core-second	$0.141912 per core-hour
Memory	$0.00000667 per GiB-second	$0.024012 per GiB-hour

Multiply the displayed Sandbox rates directly. Applying another threefold multiplier would overcharge your estimate. Substituting Function rates would understate it.

One Modal physical core corresponds to two vCPUs in its pricing terminology. A request of cpu=2 therefore means two physical cores, not a two-vCPU shape. Memory requests use MiB: 4 GiB is 4,096 MiB. These unit conversions matter before comparing providers. Modal resource configuration documents both.

GPU jobs need a separate calculation using the selected GPU's rate. This article's CPU examples do not estimate a GPU training run or hosted model inference bill.

Requests create a floor; limits control the ceiling

Modal starts a Sandbox with a small default request: 0.125 physical cores and 128 MiB. It can consume more when host capacity is available. Billing uses the larger of the request and actual consumption for each resource. Explicitly requesting one core and 4 GiB means paying for at least that much throughout the Sandbox's lifetime, including quiet periods. Sandbox resource guide.

A limit serves a different purpose. It bounds resource use rather than reserving that entire amount. CPU limits can throttle work; a memory limit can terminate a process that exceeds it. Choose limits that leave enough room for dependency installation and test suites, then examine failures alongside costs. Resource limits.

For a coding agent, a repository checkout may be quiet while a compiler briefly needs much more CPU. Reserving the compiler's peak for the whole session buys predictable capacity, but changes the economics. Letting the session burst can reduce charges, at the cost of depending on available capacity.

Measure the full job before changing reservations. A cheaper hour that doubles job duration might leave your cost per completed task unchanged.

Calculate two realistic workload shapes

Start with aggregate Sandbox hours. Ten Sandboxes running six hours each contribute 60 hours, even if their sessions overlap.

For a fixed request of one physical core and 4 GiB, with no usage above that request:

Hourly CPU:    1 × $0.00003942 × 3,600 = $0.141912
Hourly memory: 4 × $0.00000667 × 3,600 = $0.096048
Hourly total:                          $0.237960
60 aggregate hours:                   $14.277600
730 aggregate hours:                 $173.710800

That is a reservation scenario, not the inevitable cost of an agent that occasionally reaches those peaks.

Now suppose measured billable consumption averages 0.25 physical cores and 1 GiB over the session, with requests at or below those values. The hourly calculation becomes $0.035478 for CPU plus $0.024012 for memory: $0.05949. That produces $3.57 at 60 aggregate hours and $43.43 at 730 hours, before credits.

Use averages of billable consumption. Taking a raw average first and applying the request floor afterward can miss charges incurred during quieter intervals.

Neither example includes image-build work, extra storage, egress above allowances, regional surcharges, or model calls. A spreadsheet should keep those as separate lines. This makes it possible to explain a bill increase without blaming every change on the CPU rate.

Apply plan fees and credits after calculating usage

Modal Starter has no monthly plan fee and includes $30 of monthly compute credit. Team costs $250 per month plus usage and includes $100 of compute credit. Starter supports three workspace seats; Team has unlimited seats. Enterprise terms are custom. Current plans.

Assuming no other compute has consumed the allowance, our 60-hour reserved example fits inside Starter's credit. Its compute charge after credit is $0. The 730-hour reserved example leaves $143.71 payable. The elastic 730-hour example leaves $13.43.

On Team, that reserved 730-hour example becomes $250 plus $73.71, or $323.71 before other charges. Subtracting $100 from the plan fee as well would count the same credit twice.

Credits belong in the workspace budget. They are not a fresh $30 allowance for each agent you launch. Model endpoint tokens also need their own line: Modal's included compute does not cover Shared Endpoint token charges. Credit coverage.

Choose a plan for the access and operating requirements you actually need. A small experiment can have a lower cash bill on Modal Starter than on a provider with cheaper recurring unit rates. A team that needs paid-plan features must include that fee when estimating the project.

Storage and lifecycle change the monthly total

A terminated execution environment and a saved workspace are different resources. Decide which files must survive before comparing monthly prices.

Modal Volumes provide persistent storage. The published allowance includes 1 TiB, then storage is $0.09 per GiB-month. Modal measures Volume storage daily; deleted data can remain billable for up to four days. That lag matters when a build cache briefly expands. Pricing and Volume billing.

Snapshots are another persistence path, with distinct retention rules. Filesystem and directory snapshots default to 30 days and support configurable expiry. Memory snapshots expire after seven days. Root-filesystem snapshots exclude mounted Volumes, so your recovery plan must account for both. Snapshot documentation.

Modal Sandboxes default to a five-minute maximum lifetime, configurable up to 24 hours. Longer workflows need state preservation and subsequent Sandboxes. The 730-hour example above therefore means aggregate time across sessions, not one uninterrupted month-long Sandbox. Sandbox lifecycle.

Set an idle timeout deliberately. Modal considers an active command, stdin writes, or an open Tunnel TCP connection to be activity. A worker waiting inside a running command may therefore outlive the idle period you expected. Test termination and recovery using your real connection pattern. Idle timeout rules.

For network costs, Starter includes 1 TiB of monthly egress and Team includes 10 TiB; excess is $0.04 per GiB. Downloads and billable outbound transfers are different directions. Large artifact uploads deserve their own estimate. Network egress billing.

Compare Agent37 using the same running hours

Agent37 provides standard gVisor sandboxes and full VMs. Standard compute shares host resources. A full VM has its own Linux kernel and supports workloads such as Docker and Compose; standard sandboxes cannot run a Docker daemon. Pick the runtime your job requires before comparing its price. Instance docs and VM reference.

For Agent37, use 2 vCPU, 4 GB RAM, and 4 GB disk retained for a 730-hour month. Standard compute is $4.40 for 730 running hours; retained disk adds $0.36. VM compute costs 2.5 times standard compute, with the same disk rate. Agent37 pricing.

Infrastructure scenario	60 running hours	730 running hours
Modal, requested 1 physical core and 4 GiB	$14.28	$173.71
Modal, average billable 0.25 core and 1 GiB	$3.57	$43.43
Agent37 standard, 2 vCPU / 4 GB RAM / 4 GB disk	$0.72	$4.76
Agent37 full VM, 2 vCPU / 4 GB RAM / 4 GB disk	$1.26	$11.36

Modal rows are before plan fees and compute credits, assume no region surcharge, and include 4 GiB of retained Volume data within an otherwise unused free allowance. Agent37 rows include 4 GB of disk retained all month. Both exclude model/tool charges and additional services. GB and GiB follow each provider's units. These are billing scenarios, not identical hardware or throughput measurements.

Agent37 bills allocated compute whenever the instance runs, including CPU-idle time. Stopping or sleeping pauses compute while retained disk continues billing. Auto-sleep must be configured. Its smaller hourly rate does not make an abandoned fleet free. Billing documentation.

The VM example explicitly specifies 4 GB disk. The agent37-ubuntu default is 12 GB, making that default 2-vCPU/4-GB VM $12.08 for 730 hours. VM creation requires a funded workspace. VM configuration.

Pick the platform around the job you need to finish

Modal is a strong candidate when elastic allocation, GPU access, or an existing Modal application is central to the workflow. Its small-workload credit can outweigh a unit-rate difference. Modal also offers both gVisor and VM runtimes; Docker workloads can use its VM option. It should not be ruled out on an outdated assumption that it only offers containers. Modal runtimes.

Agent37 is worth testing for persistent CPU agent workers where predictable infrastructure expense matters. Use standard sandboxes for compatible execution jobs, and budget the VM rate when Docker or a full kernel is required.

Compare one complete task on each candidate: prepare the workspace, execute, retrieve artifacts, stop, and recover saved files. Record successful completion time and total billable resources. Include failed runs and retries. This article does not claim either platform completes your workload faster.

For other infrastructure choices, the sandbox cost comparison and E2B pricing guide provide related budgeting frameworks.

Set a budget before scaling the agent fleet

Write down the expected number of jobs, average duration, reservation floor, peak limits, and retained data. Then run a small batch and replace the assumptions with observations.

Modal distinguishes a workspace usage budget, measured before credits, from a spend limit on net charges after credits. Environment budgets cover compute and do not represent the full workspace invoice. Configure the control that matches the financial limit you intend. Budget documentation.

Keep three numbers visible: infrastructure cost per successful task, model/tool cost per successful task, and total monthly spend. An improvement in one does not guarantee an improvement in the others.

If persistent agent compute is your main expense, create an Agent37 sandbox, choose the runtime your workload needs, and test one representative job. Compare the complete result against Modal, including credits and retained storage, before moving the fleet.

Modal Pricing: What Agent Sandboxes Actually Cost