Evidence at a glance
The Rectangle Describes the Contract
Modal CEO Erik Bernhardsson uses the image of a “rectangle” to describe a mismatch between AI compute demand and supply. Customers typically buy a fixed number of GPUs for a fixed term, producing a rectangular commitment on a chart, while real workloads rise and fall over time. Modal targets developers and AI teams that do not want to provision clusters in advance, forecast peaks, or pay for idle resources. Here, “rectangle” is best read as a metaphor for the purchasing model, not as an established technical term.
The metaphor matters not because it gives GPUs a new name, but because it makes the infrastructure business’s risk visible. Buy for the peak and hardware may sit idle in the troughs; buy for average demand and a spike may leave you short. Modal’s approach is to pool the fluctuating needs of many customers, secure supply underneath, and offer users smaller, more flexible slices. Whether that works depends on how complementary the workloads are, not simply on how many customers join the pool.
Elasticity Depends on Pooling and Startup Speed
Shared capacity can smooth demand, but putting GPUs in a pool does not make them instantly available. Modal’s materials describe a buffer of GPUs, a custom filesystem, process checkpointing, and GPU memory snapshots, all intended to reduce the work of starting or restoring a model replica. For users, these mechanisms come down to a practical question: can compute arrive when demand appears, rather than after the workload’s peak has passed?
That is why “serverless” cannot be judged only by whether developers have to manage clusters. If elasticity responds too slowly, it converts resource cost into waiting time. If the provider reserves too much capacity to guarantee responsiveness, idle cost returns. The materials do not disclose startup times, GPU utilization, or how much the different workloads actually offset one another, so they do not establish how efficiently Modal pools capacity. What they do show is that fast startup and recovery are not cosmetic developer-experience features. They are prerequisites for making shared capacity deliver on its promise.
Sandboxes Become an Agent Runtime
Modal’s sandbox story shows that demand is changing not only in volume, but also in how compute is used. The company introduced sandboxes after recognizing that language models could generate code and that the code needed an isolated place to run. Early adoption was modest enough that the team considered shutting the product down. Coding agents, background agents, and reinforcement learning later created new use cases. Bernhardsson says sandboxes now account for roughly a third of Modal’s revenue, a shift the team did not anticipate at launch.
An agent may create an environment, run code, inspect the result, and decide whether to try again. Sandboxes therefore stop being occasional developer tools: startup and recovery latency become part of each agent cycle’s experience and cost. Modal reports having launched nearly three billion sandboxes, but that cumulative count says nothing by itself about per-task efficiency or the strength of isolation. It does make one shift visible: deciding where generated code runs is becoming part of the infrastructure product.
The Pool Operator Bears Price Risk
Aggregating demand does not remove supply-side risk; it shifts that risk toward whoever buys capacity. Modal says it does not own compute, instead relying on leases and multi-cloud procurement, with nearly 25 cloud providers. The materials also describe capacity agreements that typically run for more than three years. Long commitments can help secure availability, but if GPU prices later fall, capacity locked in at earlier prices may become expensive. More flexible spot capacity has a different drawback: it can be preempted and may not be there when needed.
Growth Figures Do Not Prove Unit Economics
In materials accompanying its Series D, Modal reported more than $1 billion in annualized revenue, a $750 million financing round at a $16 billion valuation, and nearly three billion sandboxes launched. These figures show the pace of expansion, but they do not answer the harder questions: how high is GPU utilization, does the pool make money, and who absorbs losses when long-term commitments meet changing prices? Treating funding, valuation, or sandbox counts as direct evidence of infrastructure efficiency confuses growth with economics.
Technical leaders should start with the shape of their own workloads: how pronounced are the peaks and troughs, can jobs tolerate startup delays, and have sandbox creation and recovery become bottlenecks in agent loops? Shared elastic compute merits evaluation when demand is volatile and keeping GPUs reserved for peaks is costly. For steady workloads, or those requiring tight latency and predictable capacity, compare it against reserved resources on their actual costs. The central question is not whether compute is rectangular, but who pays for idle capacity, shortages, and price changes.