Cloudflare Containers Pricing: Calculate Your Agent Bill

Do not index

Cloudflare Containers pricing combines active CPU time with allocated memory and disk while each container runs, plus a $5 monthly Workers Paid plan and any related service charges. An agent waiting for a model can use little CPU while still accumulating memory and disk costs. Agent37 offers another option for persistent agent workspaces, with separate standard gVisor and full VM rates.

The useful comparison starts with your workload: how long it stays awake, how much CPU it actually consumes, and what must survive a restart. A low per-second rate alone cannot answer that.

This guide uses public rates checked on November 3, 2026. The examples are calculated budgets, not measured performance tests or complete invoices.

Cloudflare Containers pricing: the three resource meters

Cloudflare meters running containers in 10-millisecond increments. Its Containers pricing documentation lists these rates and monthly allowances on Workers Paid:

Resource	Included monthly usage	Price above allowance
Active CPU	375 vCPU-minutes	$0.000020 per vCPU-second
Allocated memory	25 GiB-hours	$0.0000025 per GiB-second
Allocated disk	200 GB-hours	$0.00000007 per GB-second

For hourly calculations, those rates become $0.072 per active vCPU-hour, $0.009 per allocated GiB-hour, and $0.000252 per allocated GB-hour of disk. The CPU allowance equals 6.25 vCPU-hours.

Memory is measured in GiB; disk is listed in GB. Keep those units in your spreadsheet instead of silently treating every provider's resource labels as identical.

The allowances belong to the paid account. Do not subtract a fresh allowance for every container. If another application has used them, your next workload starts paying the marginal rates immediately.

Cloudflare's Workers plan has a $5 monthly minimum. Containers do not have a standalone, perpetual free plan in this pricing table. An existing Workers Paid customer may already cover that base fee, which changes the incremental cost of adding a small container workload.

CPU utilization matters, but idle memory still costs money

Cloudflare changed Containers to active CPU billing in November 2025. Its pricing change example shows why: a one-vCPU container averaging 20% utilization consumes 0.2 vCPU-hours during one running hour.

That does not mean the whole container bill falls to 20%. Memory and disk remain tied to the selected allocation while it runs.

Consider a coding agent that alternates between tests and model requests. During tests, CPU use may rise sharply. During a model request, CPU use may drop, but the environment can remain awake with its dependencies and files loaded. Both phases belong in the runtime budget.

Measure CPU time across representative jobs. Separately measure elapsed running time, including startup, package installation, retries, and the interval before shutdown. Multiplying job count by the duration of the useful command will undercount an environment that stays awake afterward.

Concurrency needs the same care. Ten separate containers running for one hour contribute ten container-hours. Ten requests sharing one container do not automatically create ten hours of allocated memory. Track the actual instance layout before extrapolating traffic into a bill.

Choose a supported instance size before calculating

Cloudflare's instance types range from lite, with 1/16 vCPU, 256 MiB memory, and 2 GB disk, to standard-4, with 4 vCPU, 12 GiB memory, and 20 GB disk.

For the worked examples below, we use standard-2: 1 vCPU, 6 GiB memory, and 12 GB disk. This is a published shape, not an invented combination chosen to make the arithmetic attractive.

Custom sizing is available, but constraints matter. The current documented defaults include a minimum of one vCPU for custom instances and at least 3 GiB of memory per vCPU. For fractional CPU, choose an appropriate predefined type. Cloudflare says size limits can be increased through support; that is separate from assuming a larger shape is immediately available.

Start with the smallest shape that completes your real job reliably. A dependency install or browser process can need more memory than the main agent loop. A smaller allocation that repeatedly fails can cost more in retries and engineering time than a larger, dependable one.

Worked bills for 60 and 730 running hours

Assume one standard-2 container averages 20% of its one-vCPU capacity. Give this workload all unused monthly CPU, memory, and disk allowances. Include the $5 Workers Paid fee once.

The calculation is:

CPU = max(0, running_hours × 1 × 0.20 - 6.25) × $0.072
Memory = max(0, running_hours × 6 - 25) × $0.009
Disk = max(0, running_hours × 12 - 200) × $0.000252
Subtotal = $5 + CPU + Memory + Disk

Cost component	60 running hours	730 running hours
Active CPU after allowance	$0.4140	$10.0620
Allocated memory after allowance	$3.0150	$39.1950
Allocated disk after allowance	$0.1310	$2.1571
Workers Paid base fee	$5.0000	$5.0000
Calculated subtotal	$8.56	$56.41

The 730-hour column is an aggregate monthly estimate. Both columns exclude Workers and Durable Objects overages, logs, external storage, network egress charges, model usage, tools, and taxes. Disk here is the allocated container disk during runtime, not a persistent volume retained across the month.

Memory is the largest resource charge in this example. That follows from the assumed workload and shape; it is not a benchmark of all agents.

At 100% average CPU utilization, the same subtotals become about $12.02 and $98.46. If the account has already consumed all three allowances, the resource-only amounts at 20% utilization become about $4.29 and $52.14, before allocating any base fee or adding other services.

A tiny workload may fit entirely inside an existing paid account's remaining allowances. A continuously warm workspace may accumulate substantial memory charges. Use both a normal-use estimate and a busy-month estimate before choosing a provider.

Add the services around your container

Incoming requests pass through a Worker, and each container has a Durable Object. Those services have their own meters and allowances. The container subtotal above does not replace their billing calculations.

Durable Objects pricing includes requests, compute duration, and storage. Duration can accrue while an object remains in memory and cannot hibernate. Connection handling therefore affects cost even when the Linux process is doing little work.

If you enable container observability, check Workers Logs billing. Verbose command output multiplied across many workers is an operational choice with a cost, not a free feature to ignore during forecasting.

Network transfer is another separate line. Containers currently include 1 TB monthly egress in North America and Europe, with additional transfer at $0.025 per GB. Other regions have different allowances and rates. Do not apply the general Workers statement about free egress to Containers without checking the product-specific table.

If artifacts live in R2, budget its storage and operations under R2 pricing. Model tokens, search APIs, and other paid tools remain separate regardless of where your execution environment runs.

Sleep, snapshots, and the cost of keeping work

Stopping a container can remove its running resource charges, but your recovery design determines whether that saves useful work or loses it.

Cloudflare's lifecycle documentation says disk is ephemeral by default. A normal start after sleep uses the container image's fresh filesystem. Containers run inside individual microVMs; the product name does not imply an ordinary shared-kernel container boundary.

For persistent work, Container snapshots can capture filesystem state under the durable_object scheduling policy. They do not preserve memory or running processes, and they are tied to the image version used to create them. Changed files need a new snapshot.

Snapshots currently have a 30-day lifetime refreshed by a restore. Treat that as a recovery mechanism with explicit retention, not an indefinite archive. Keep durable outputs somewhere appropriate for your application's retention requirements.

Shutdown controls also depend on your API. The Durable Object Container API provides setInactivityTimeout(). The Container class has a sleepAfter setting, with a documented ten-minute default. Do not copy a timeout between APIs and assume identical behavior.

For an agent, test a real interruption: save work, stop the container, restore it, then resume the job. Record what survives, what must reinstall, and what needs a new process. The recovery overhead belongs in both your cost model and your user experience.

When Agent37 fits the workload better

Agent37 is worth evaluating when you want a persistent agent workspace with low ongoing infrastructure costs. Its standard gVisor sandbox and full VM are separate runtime choices, with different compute rates.

At the current Agent37 pricing, a standard 2 vCPU, 4 GB RAM, 4 GB disk sandbox costs $4.76 for 730 running hours. That combines $0.80 per vCPU, $0.70 per GB RAM, and $0.09 per GB disk per 730-hour month, metered by the minute.

If that same sandbox runs for 60 hours and retains its 4 GB disk for all 730 hours, the estimate is about $0.72: $0.36 of compute plus $0.36 of retained disk. An awake idle instance still pays compute. Stop it or enable auto-sleep to pause compute charges; disk keeps billing while retained.

For a full VM, compute costs 2.5 times the standard rate and disk costs the same. The 2 vCPU, 4 GB RAM, 4 GB disk example becomes $11.36 for 730 running hours, or about $1.26 for 60 running hours with disk retained all month.

These are different resource shapes from Cloudflare's 1 vCPU, 6 GiB, 12 GB example. They are buying options, not equivalent-performance benchmarks or a universal savings percentage. Model and tool spend is extra on Agent37 too.

Standard gVisor instances cannot run a Docker daemon. Use a VM for Docker and Compose workloads. The Ubuntu VM template defaults to 12 GB disk when resources are omitted, making its 730-hour estimate $12.08. VM creation requires a funded workspace, and systemd entrypoints are unsupported.

Cloudflare may be the stronger fit when your application already uses Workers and Durable Objects and can use their remaining allowances. Agent37 may fit better when persistent workspaces, explicit lifecycle controls, and ongoing compute costs drive your decision. Our broader sandbox pricing guide covers other providers and comparison assumptions.

Price one complete job before scaling

Choose a representative task and record its resource allocation, active CPU seconds, total running time, and artifact storage. Repeat with a retry and a restart. Include the idle timeout rather than stopping your measurement when the command finishes.

Then multiply by expected jobs and retained workspaces. Apply account allowances once, add supporting services, and keep model costs in their own column. This gives you a budget you can revise when actual usage arrives.

If a persistent sandbox fits, read the Agent37 instance API and create a sandbox for that representative task. Validate execution and recovery before committing the rest of your workloads.