Pay-for-Storage vs Pay-for-Compute Pricing Models for Agents

Most AI agents sit idle for most of their lives, but the infrastructure bill keeps running. How a platform prices that idle time, as active compute or as dormant storage, determines whether per-user agent deployments are economically viable at any scale.

Why the idle time problem is the defining cost challenge for agent deployments

A customer support agent that handles three interactions a day is a representative example of the structural problem. The rest of the day, roughly twenty-three hours, the agent is live but inert: holding its conversation history, its filesystem, its credentials, and its memory of prior sessions in resident memory so it can respond the moment the next request arrives. That state must live somewhere even when no inference is happening, and in a conventional deployment, the somewhere is a running process that bills by the hour.

This idle condition is not an edge case in agent usage. Agentic workflows are built around waiting: waiting for tool responses, for human approval gates, for rate-limit backoff windows, for scheduled tasks to trigger, for a user to return after hours away. The idle problem is structural, not a usage quirk, and it is the question every agent infrastructure pricing model must answer.

How pay-for-compute and pay-for-storage work as billing models

Two architectural responses to the idle problem have emerged, and they represent fundamentally different commitments to what an idle agent costs. Under pay-for-compute, the agent process runs continuously. The provider meters vCPU-hours and gibibyte-hours of active memory, and idle time between turns either bills at the full compute rate or is excluded by the platform's own definition of what counts as active. The agent process has to stay resident to receive the next prompt, so memory is held and billed continuously even when no inference is running.

Vertex AI's Gemini Enterprise Agent Platform offers the clearest published example of a separated compute and storage meter. Agent Compute bills at $0.085 per vCPU-hour, and Agent Memory bills at $0.009 per gibibyte-hour, but idle time between turns is not billed. The memory meter continues to run throughout.

Pay-for-storage takes the opposite approach. When an agent becomes inactive, its process is terminated entirely. Its full state, including memory, filesystem, and execution context, is serialized to durable storage, and the agent pays only for the bytes it occupies at rest. When the next request arrives, the agent resumes from that snapshot on demand. The two models produce different cost curves. Compute billing is time-linear regardless of activity, while storage billing is volume-linear regardless of time. Which curve dominates depends entirely on the ratio of active to idle time in the workload.

What the compute model costs when agents are mostly idle

The weakness of compute billing for idle-heavy workloads becomes visible when the pattern scales from one agent to a fleet. Each wait interval is idle compute billed at active rates. Tool latency, human approval gates, rate-limit backoff, and scheduled pauses accumulate into a large fraction of total runtime that produces no output but still consumes the meter.

The problem compounds multiplicatively. On top of model token costs, you also pay for infrastructure and orchestration to run a production agent. Model inference is only one component of the bill, and idle infrastructure is a significant part of the rest.

Compute billing further exposes operators to concurrency spikes. A monthly average can look manageable but hides short windows of high concurrent activity that exhaust rate limits or reserved capacity, followed by long troughs of paid idle time. For agents that serve a user a few times a day, the between-session intervals dominate the day, and the memory meter continues to bill throughout.

What the storage model costs and where its costs concentrate

Storage-based billing converts idle cost from a time-linear charge into a volume-linear one, which is predictable and bounded. Vertex AI's Gemini Enterprise Agent Platform, for instance, bills Sessions and Memory Bank storage at $0.30 per gibibyte-month, a structure that has been in effect since September 1, 2026. A team managing a fleet knows its storage bill is bounded by data volume, not by usage spikes or concurrency windows. That budget certainty matters for per-user deployments at scale.

The costs concentrate in what the agent accumulates. Conversation history, long-term memory, file attachments, vector embeddings, and cached context all persist and accrue storage cost over time. Agents re-read accumulated context on every step, which means input tokens, not generated ones, dominate the cost stack, and the size of stored context directly determines how expensive each re-read is. The predictability advantage is real, but it has a ceiling when state grows without bound or retrieval is frequent.

How snapshot-restore infrastructure makes the storage model operationally viable

The storage model only works in practice if the infrastructure can pause an agent, preserve its complete state, and resume it fast enough that the delay is invisible to the product built on top of it. A snapshot-restore cycle that takes seconds is usable only for batch and scheduled workloads. Interactive agent products require wake latency well under a second to maintain responsiveness.

Firecracker, originally built by AWS to run Lambda and Fargate workloads at scale, achieves boot times measured in milliseconds and snapshot restore in the 5–30ms range, which is fast enough for interactive use. At the infrastructure level, the pay-for-storage model becomes architecturally coherent: a paused microVM is simply a file on disk, priced at storage rates, ready to be restored to a running process on demand. The same snapshot capability that enables cost savings also enables agent continuity across deployments, with persistent disk, credentials, and memory surviving sleep and redeploy, a functional requirement for agents that maintain long-running tasks or user context across sessions.

Maritime addresses this structural idle problem by using snapshot-restore scheduling. When an agent is inactive, its full state is serialized to durable storage and the compute process terminates entirely, so idle time incurs no infrastructure cost. Only the storage bytes themselves are billed, so the idle-time cost pattern is explicit and predictable, not hidden inside continuous compute billing.

Why micro-VM isolation matters for the economics, not just the security

Micro-VM isolation is what makes it safe and economically practical to run thousands of individually snapshotted agents on shared bare-metal infrastructure, and that density is what keeps per-agent storage costs low. Multi-tenant agent deployments in containers either carry elevated risk or require over-provisioned isolation through other means. MicroVMs give each agent its own kernel: code execution, package installation, browser sessions, and arbitrary tool use happen inside a hardware-isolated boundary that cannot reach neighboring agents or the host.

For agents running untrusted or AI-generated code, which is the normal condition for autonomous agents, this isolation is a functional requirement, not an upgrade. If each agent required a dedicated physical server or a heavily provisioned container cluster, the economics would not work. A snapshotted micro-VM is a compact artifact, a memory image plus filesystem delta, that can be stored at commodity storage rates and restored to a specific physical host with the right hardware characteristics in milliseconds.

The common objection that a microVM is more resource-intensive than a container, which would increase costs rather than reduce them, does not hold up. Firecracker's memory overhead per VM is measured in single-digit megabytes. The isolation cost is negligible relative to the agent's own state, and the density achievable on bare metal more than compensates.

How idle-cost structure determines whether per-user agent deployment is economically viable

The per-user agent pattern, one persistent agent instance per end-user, creates a fleet where the ratio of idle to active agents at any moment is very high. Under a compute model, the idle majority is billing continuously. Under a storage model, they are billing at storage rates only.

This ratio makes the compute versus storage choice the difference between a viable and an unviable unit economics model. The economics only close if idle agents cost close to nothing. Per-agent snapshot-restore means each agent's cost tracks its own state size, not the fleet's peak concurrency.

Maritime's architecture is a direct implementation of this thesis. The flat-rate-per-agent pricing that results from this architecture is not a marketing simplification. It is the output of a cost model that works because most agents are idle most of the time, and the infrastructure accounts for that honestly.

Which model fits which workload type

Neither model is universally superior. The right choice depends on three workload characteristics: the ratio of active to idle time, the size and growth rate of agent state, and the latency requirements of the product built on top of the agent. Compute billing is the better fit when agents are active for a large fraction of their operational lifetime, such as batch processing pipelines, always-on monitoring agents, or agents serving high-traffic applications where idle intervals are short. It also fits when state is small and ephemeral, where the cost of persisting state is not offset by the savings on idle compute. Platforms that already exclude idle-between-turns from billing approximate a compute-only charge for inference time, which reduces but does not eliminate the idle cost problem.

Storage billing is the better fit when agents are idle for the large majority of their lifetime: per-user agents, customer-facing assistants with infrequent sessions, scheduled task agents, or any fleet where individual agents serve a single user who is not always present. It fits when state must persist across sessions, including long-term memory, file access, credentials, and conversation history that define the agent's identity and continuity for a specific user. It also fits when fleet size makes idle compute costs prohibitive, since the larger the fleet, the more the compute model's idle overhead compounds and the more the storage model's predictability becomes a financial advantage.

The storage model does not require sacrificing responsiveness. Snapshot-restore infrastructure like Firecracker makes sub-second wake achievable, and Maritime achieves this by deploying each agent in its own Firecracker micro-VM and waking from snapshot in roughly one second. That makes storage-based billing coherent for real-time agent workflows rather than relegating it only to batch or asynchronous use cases. A hybrid case also exists where platforms separate compute and storage meters, billing compute only for active inference time and storage for persistent state, which gives developers the ability to optimize each dimension independently.

How the broader infrastructure cost stack interacts with the compute vs. storage choice

The compute versus storage decision sits inside a larger cost structure, and optimizing it in isolation can shift costs to another meter without reducing total spend. Agentic workflows push input tokens, not generated ones, to the top of the cost stack because agents plan, call tools, and re-read accumulated context on every step. Context size is therefore both a storage cost and a token cost simultaneously.

Retrieval infrastructure adds its own meter on top of both compute and storage. Hardware media pricing is now a live variable as well. The shift toward persistent context storage on NVMe flash, exemplified by Nvidia's CMX platform, means token costs are increasingly tied to flash pricing, which has shown significant volatility. The economics of inference are no longer determined solely by GPU pricing. So you should make the compute versus storage choice alongside decisions about context retention, retrieval architecture, and storage tiering. They are coupled.

What developers should model before committing to an infrastructure pricing structure

The right pricing model emerges from the workload's actual numbers, not from vendor defaults, and the numbers that matter most are the ones most teams do not measure during planning. The first is the actual active-to-idle ratio. For most per-user agent deployments, this ratio is highly skewed toward idle, but the exact figure varies by use case and cannot be assumed.

The second is state growth over time. Estimate how large each agent's persistent state will be at one month, six months, and one year, including conversation history, long-term memory, file storage, and vector embeddings. The fourth is the full cost stack: token costs with context size modeled accurately, retrieval infrastructure, and any operations meters for reads and writes against stored state, not just idle infrastructure.

Finally, stress-test the model at fleet scale. The compute versus storage choice that is economical at ten agents may be uneconomical at a thousand. The compute versus storage question is ultimately a question about workload shape. Developers who know their idle ratio, state size, and latency requirements can make the decision from first principles.