Modal turns unpredictable AI jobs into a metered cloud business

Company desk | Peterson Compute Trading | November 7, 2026
AI-assisted public-source analysis. No interviews or independently run performance tests. Dollar amounts are US dollars.

Modal's customer buys the ability to start work quickly, expand it briefly and stop paying when resources are released. That proposition suits a model evaluation that arrives without warning or a coding agent that alternates between waiting and running tests. It becomes harder to justify when the same hardware stays busy all day. Understanding the company requires examining both patterns, rather than treating serverless compute as automatically inexpensive.

The scale is substantial. On October 14, Modal announced a $750 million Series D at a $15.75 billion post-money valuation and said it had exceeded $1 billion in annualized run rate. Those are company-reported figures. Run rate extrapolates current activity; it is not a statement that Modal has already booked a billion-dollar financial year. Modal's announcement

A customer needs a completed evaluation

A November 6 Modal case study describes Snorkel running millions of agent simulations monthly, with peaks of tens of thousands of sandbox creations per hour. A sandbox is an isolated execution environment. These tests require different environments: an infrastructure agent may need a full Linux kernel, while an ML agent needs a GPU. Snorkel also uses shared and dedicated inference endpoints to evaluate standard and customized models. The commercial deadline can be a day after a new model appears. Snorkel case study

The same account reports roughly 20% savings on Snorkel's total Sandbox bill after adopting resource bursting, with approximately 10–15% of its sandboxes using that feature. The baseline bill, observation period and detailed workload mix are not disclosed. This is an attributed customer result in supplier material, not a general savings promise. Snorkel case study

For a buyer, the useful unit is a valid evaluation delivered before its deadline. Cheap executions that fail because their environment lacks memory contaminate the comparison. A trial should separate model failures from infrastructure failures and record reruns, queueing and elapsed time alongside the invoice.

The workflow can outlast the first GPU order

Ramp supplies customer-authored evidence of a different use. Its January 12 engineering article describes Inspect sessions running in Modal sandboxes with a full development environment, including Postgres and Temporal. Ramp builds repository images every 30 minutes, installs dependencies ahead of time, snapshots the prepared environment and starts new sessions from that state. It snapshots completed work again so a later follow-up can resume it. Ramp's engineering account

This explains how an infrastructure supplier can become embedded in a customer's daily operations. The recurring purchase includes environment preparation, state recovery and concurrent execution. Replacing that supplier means validating the whole workflow again. That is a plausible source of retention, not evidence that customers cannot leave or that Modal earns a particular margin.

Founded by Erik Bernhardsson and Akshat Bubna, Modal combines its software with externally supplied capacity. Its October announcement describes a pool spanning more than 20 clouds and its own scheduler, filesystem, networking and container runtime. Lead investor Accel separately says Sandboxes accounted for $300 million of revenue run rate, about 30% of the stated billion-dollar total. Accel corroborates the financing but is an interested investor, not an independent auditor. Company account, Accel's October 14 statement

Price the whole running container

The public tariff observed November 7 lists an H100 SXM5 at $0.001097 per second, or $3.9492 per hour. Base CPU is $0.0000131 per physical core-second and memory is $0.00000222 per GiB-second. CPU and RAM are separate meters. CPU-only Sandboxes use non-preemptible CPU and memory pricing, listed at three times the base rates. The example below is a GPU Function, not a Sandbox quote. Modal pricing

Consider an illustrative GPU Function billed for one H100, four physical CPU cores and 64 GiB of RAM throughout an hour. The calculation is $3.9492 for the GPU, $0.18864 for CPU and $0.511488 for memory: $4.649328 per hour, before storage, network, plan charges, credits, discounts or region premiums. This is PCT arithmetic, not a customer invoice or a benchmark. Actual charges depend on resources consumed and requested.

Now suppose a genuinely comparable reserved configuration costs $3 per hour continuously. That $3 is an illustrative quote, not an observed competitor offer. Ignoring other differences, the reservation costs $72 per day. Modal reaches that amount after 15.49 billed hours, about 64.5% of the day. Below that utilization, release of capacity can outweigh the higher running rate; above it, the assumed reservation wins on these compute charges.

The reservation comparison is valid only after matching hardware, throughput, memory, interruption rights and support. Add the customer's operating labor and required headroom to both cases. A less expensive configuration that takes longer to produce the same accepted result can erase the apparent saving.

Idle time has several meanings

Modal's cold-start documentation distinguishes container boot from application readiness. Imports and model initialization can still take time after the container starts. Keeping containers warm reduces waiting but retains billable resources; the default maximum idle window is 60 seconds, and actual scale-down can occur sooner. Cold-start documentation

Assume an isolated request occupies an H100 for 240 seconds of useful work, 30 seconds of loading and the full 60-second idle window. The GPU meter records 330 seconds, costing $0.36201 rather than the useful-work-only $0.26328. That is 37.5% additional GPU time. This deliberately simple example assumes no overlapping requests and no early scale-down. Reusing a warm container changes the result.

The buyer therefore needs two measurements: productive seconds and billed seconds. Test traffic at its real arrival intervals. A continuous load test will hide the cost of sporadic requests; a single cold request will overstate overhead for a busy endpoint. A minimum warm pool may be sensible for latency, but it should appear explicitly in the budget.

Bursting transfers a sizing decision

Modal bills CPU and memory at the greater of requested capacity and actual usage. Requesting a large allocation establishes a floor, even while the process is doing little. Bursting above the request depends on spare host capacity. The documentation recommends monitoring CPU pressure and memory-related evictions, then increasing reservations where necessary. Resource billing, Sandbox sizing

Suppose, purely illustratively, a CPU sandbox needs eight GiB for one minute and two GiB for nine minutes. An eight-GiB reservation bills 80 GiB-minutes. A two-GiB reservation with successful bursting bills 26: two times nine, plus eight times one. The memory component falls 67.5%. CPU, inference, storage and other costs do not disappear, and this is not a reproduction of Snorkel's 20% result.

The operational catch matters. Lower reservations can expose a workload to contention or eviction when capacity is tight. Set a resource ceiling to contain a runaway agent, but choose it using actual workload traces. A limit that repeatedly kills valid work simply moves spending into retries. Evaluate cost per successful session and high-percentile completion time together.

Four conditions belong in procurement

Location. Pinning a broad container region carries a 1.15-times usage multiplier; a narrow region carries 1.75 times. In the illustrative H100 configuration, that changes $4.65 per running hour to approximately $5.35 or $8.14. A buyer with a fixed jurisdiction requirement should use the regional price from the beginning. Region selection

Residency. Compute placement does not settle every data question. Modal's documentation says application logs are stored in the United States. Function payloads above two MiB and asynchronous payloads have additional US-storage implications; explicit Sandbox snapshots are also stored there. Shared Endpoints do not offer selectable regions. Map the complete data path before approving a regulated workload. Data residency

Interruption. GPU Functions and GPU Sandboxes are preemptible. Paying the CPU non-preemptible premium does not buy non-preemptible GPU Functions. Current documentation also limits GPU Sandboxes to the gVisor runtime, so do not assume the full-VM and GPU configurations are interchangeable. Test checkpoint recovery and safely repeatable operations before relying on a long job. Preemption rules, GPU Sandbox restrictions

Application security. On July 29, Modal described a customer endpoint that accepted unauthenticated public code execution. Modal said its platform isolation was not breached and other customers were unaffected. The practical lesson is to review the application boundary as well as the sandbox boundary. Current docs allow outbound public-IP access by default, with controls to restrict it. Incident statement, Network controls

The supplier has its own utilization problem

Pooling many customers can improve hardware use because their peaks do not always coincide. That is the economic logic behind Modal's offer. Its success depends on obtaining suitable capacity, packing jobs efficiently and charging enough to cover software, operations and unused commitments. The reviewed public sources do not establish its gross margin, cash consumption, supplier concentration or contractual capacity obligations.

An October 19 engineering post shows where Modal is looking for further efficiency. Its early NVIDIA Vera test reported up to twice the task throughput of an equivalent x86 GNR machine under load. The benchmark used 50 Terminal-Bench tasks with network calls removed and containers prewarmed. That is a supplier-run CPU experiment, not proof that a complete customer's agent becomes twice as fast. Modal described supporting Arm as requiring infrastructure and image-system changes. Vera test

The competitive question is whether better scheduling and faster environments keep saving customers enough to justify the service layer. When workloads become predictable, customers can renegotiate, reserve capacity or operate more of the stack themselves. When model changes and agent behavior keep workloads irregular, flexible execution retains a clearer purpose.

A purchase should start with a measured pilot

PCT would ask a prospective customer to replay a representative week, including quiet hours, burst traffic and failures. Record completed valid jobs, total compute and data charges, setup labor, billed-to-productive time, queue delays and recovery time. Run one deliberate restart and one region-constrained test. Confirm account quotas and capacity terms rather than interpreting an autoscaling feature as an availability guarantee.

Modal is credible as a candidate for teams whose work changes shape faster than their infrastructure plans. Its reported growth and concrete customer workflows warrant attention. The purchasing decision still belongs in the workload trace: what finished, how long it took, what was retained between requests and what the complete run cost. That evidence is more durable than either a funding valuation or an attractive GPU-hour headline.