Elastic Storage Billing for Agent Workloads

Agent workloads break storage billing because their consumption pattern looks nothing like what storage pricing was designed to measure, not because they use more data overall. Provisioned billing assumes a workload that behaves itself: steady, forecastable, polite. Agents are none of those things.

Why agent workloads don't match storage billing's design

Traditional storage billing was built for workloads with a pulse you could set a watch to. A database writes at a steady clip. A data warehouse runs its reads on a schedule. A backup job kicks off and finishes by sunrise. Whether you're paying for block storage or provisioned IOPS, the pricing logic assumes you know roughly what you'll need next month, so you reserve it now and pay for that reservation whether you touch it or not.

Agents don't work that way, and they were never going to. An agent doesn't write once and move on. It loops: read, reason, write, reread, reason again. The mismatch is a structural incompatibility between how agents behave and what the billing model was built to price, not a rounding error in an otherwise good system.

How agents consume storage across a session

Picture an agent six steps into a task. It is re-reading on step six data it also read on steps one through five, with the same bytes crossing the storage layer multiple times within this single task. The storage layer doesn't see one clean read. It sees the same bytes crossing it repeatedly, compounding with every turn.

Three behaviors stack on top of each other to produce this pattern. The first is that repetitive context read: the same data getting pulled back through storage multiple times within a single task, a cost that occurs at the storage layer well before it ever reaches the model itself. One audit covering 30 production engineering teams found that a majority of the total inference bill traced back to exactly this kind of repetition.

The second behavior is checkpoint writing. Agents save their progress constantly so a crash or a retry doesn't send them back to square one, and those checkpoints don't trickle in evenly. They arrive in dense bursts, right when the agent is working hardest and needs the highest write throughput it's going to need all session. Slow checkpoint writes don't just annoy the storage system. They leave GPU or CPU time sitting idle while the write finishes, so a storage delay turns into a compute cost.

The third behavior is the mess agents leave behind: search results, draft plans, tool outputs, all generated and discarded at a pace no human workflow comes close to matching. Storage has to be ready to absorb all of that at peak volume, then sit mostly empty between sessions when nothing happens.

These three behaviors combine into a demand curve that is spiky in time, unpredictable in size, and allergic to being described by a single provisioned number.

What provisioned billing charges agents for but they don't use

Provisioned billing makes you pay for the worst moment you might have, every single day, whether that moment shows up or not. Reserving for the peak means paying for the peak, even on the days nothing peaks.

Amazon EBS is a clean example of how this plays out. On certain volume types, like gp3 above its baseline, io1, and io2, IOPS, throughput, and snapshot charges stack up separately from the per-gigabyte rate, billing for headroom whether or not the workload ever uses it, while a volume type like gp2 bundles IOPS into the per-GB price with no separate IOPS line at all. An agent that runs hard for a few hours and then goes silent has still reserved that IOPS capacity for the entire billing period, paying for a resource it only needed for a sliver of the time it was billed for.

Snapshots compound the same problem in a quieter way. Every checkpoint an agent writes sticks around, and it keeps accruing retention costs long after the task it supported has wrapped up. And egress fees multiply the damage further: an agent that keeps re-reading context, checkpoints, and retrieval results across distributed infrastructure pays an egress fee on every one of those reads, not once. For data-heavy workloads, egress alone can eat a substantial share of total AI infrastructure spend, and that per-GB charge isn't a one-time toll, it's a toll collected at every read epoch.

Then there's a charge most teams don't see coming until the bill arrives: uncompressed metering. Elastic's serverless platform meters ingest and retention based on the uncompressed, normalized, fully enriched version of the data, and Elastic's own billing documentation states that metered volumes run much higher than the raw or compressed size actually moving across the wire. If an agent workload generates large volumes of enriched intermediate state, that inflates every line item on the invoice even though no one touches a single extra byte of real data.

Add it up: egress, snapshots, IOPS overages, and uncompressed metering routinely pile a large fraction on top of whatever the original storage budget projected, and most of that extra cost traces back to paying for a steady provisioned state that an agent workload never actually holds.

Why consumption-based billing doesn't automatically solve the problem

Switching from provisioned to consumption-based billing sounds like the obvious fix. Pay for what you use, stop paying for what you don't. It narrows the problem. It doesn't close it, because the unit you're charged for matters just as much as whether you're billed on reservation or usage.

Plenty of agent workloads running in production today aren't bursty at all: always-on inference serving, data pipelines that never stop, retrieval loops that run continuously around the clock, these are sustained workloads with steady utilization, and for that kind of workload a flat provisioned rate usually beats a consumption model on price.

Consumption billing carries its own traps even for the workloads it's supposed to help. Elastic's serverless pricing bills Agent Builder and Workflows per execution, and a single conversational turn that crosses a defined input-token threshold counts as more than one execution, while each Workflow execution counts as one full run with no token-based multiplier. A single turn using a large enough context window can quietly rack up several billed executions, so the invoice scales with how complex the orchestration gets, not with how much storage actually moved.

Uncompressed metering raises costs again here too: a consumption model still charges based on a volume that can run several times larger than the bytes actually being stored, because enrichment and normalization inflate the billing basis before the per-unit rate ever gets applied.

Cloudflare gives a live example of how fast this kind of billing model can shift underneath a team already in production. On July 7, 2026, Cloudflare published a changelog changing how it calculates durable workflow costs, and starting no earlier than August 10, 2026, Workflows began billing for step execution and storage usage on Paid plans. That's the bundled-to-metered transition happening in real time, mid-deployment, for exactly the kind of retry-heavy agent pipeline this piece has been describing. The bill starts scaling with orchestration complexity itself, not with the compute or storage underneath it.

And egress doesn't go anywhere. Consumption billing gets rid of idle-capacity charges, but it does nothing about egress fees charged on every read, so if an agent keeps re-reading context or a retrieval corpus, it still faces the same egress multiplication whether you bill it on provisioned capacity or on consumption.

Consumption-based billing is a necessary step. It isn't sufficient on its own. The unit being billed has to match what an agent is actually consuming: active cached data, not provisioned headroom sitting unused, and not an uncompressed enriched volume that was never the real size of anything.

Elastic Billing in Practice

The model that actually fits an agent workload bills on what's being actively cached and used right now, not on provisioned capacity sitting in reserve, not on raw ingest volume, and not on an uncompressed enriched figure that overstates the real footprint. Capacity scales with the agent's actual working set at any given moment, moving with the workload instead of being set in advance of it.

Active use" means storage capacity expands and contracts with what's actively cached. When an agent's working set shrinks between sessions, billed capacity shrinks right along with it. When the agent bursts into a heavy checkpoint or retrieval phase, capacity expands to match without anyone pre-provisioning for that spike. And the data itself never has to move to make this work. The source of truth stays in the customer's own bucket, whether that's S3, GCS, R2, Azure Blob, or any S3-compatible store, so revoking access leaves the data sitting exactly where it was the whole time. Billing tracks active use. It doesn't track who holds custody of the data.

This isn't a hypothetical pricing model waiting to be built. CoreWeave's AI Object Storage, with general availability announced at NVIDIA GTC 2025, runs on automated usage-based billing that cut existing customers' costs by more than half, charges zero fees on egress, ingress, or requests, and delivers throughput up to 7 GB/s per GPU at a scale that reaches hundreds of thousands of GPUs. Zero egress by design removes the exact egress-multiplication problem that makes agent re-reads so expensive under other billing models.

Nutanix is building toward the same idea from a different angle. Unified Storage 5.3, announced at.NEXT 2026, turns object storage into a high-speed tier built for AI Factories, using Smart Tiering to move data to Google Cloud and OVHCloud S3 without friction. Frequently accessed data sits close to compute where it's cheap to serve fast, and cold data gets moved out of the active billing tier entirely, so you stop paying active-use rates on data nobody's actively using.

None of this works if the fast tier isn't actually fast. Billing on active cache instead of total capacity only makes sense if that cache can serve an agent at the latency the agent needs to keep working. LLM training needs sub-millisecond response times on small-object reads just to keep a GPU cluster fed, and the architecture that makes that possible is all-flash object storage running NVMe-over-Fabrics. NVIDIA's own DGX SuperPOD reference architecture specifies read bandwidth in the tens to over a hundred GBps depending on the size of the GPU cluster, and storage has to hit those numbers for an active-use billing model to be worth adopting in the first place. A cheap billing model attached to slow storage just trades one cost for a different kind of pain: idle GPUs waiting on reads that should have taken microseconds.

The cloud-agnostic requirement: active-use billing depends on storage that isn't locked to one provider

Active-use billing only delivers on its promise if a team can actually move compute to wherever storage is cheapest. If egress costs and data gravity keep everything pinned to one provider, elastic billing on paper turns into captive pricing in practice.

Egress fees are the mechanism that makes lock-in stick. Public cloud providers charge enough to move data out, or to run compute in a different region than the one storing it, that doing so becomes economically painful rather than just mildly annoying. For data-intensive workloads, egress can eat a very large share of total AI infrastructure cost, and at that scale the elasticity consumption billing promises is theoretical at best, because actually moving data to chase better pricing elsewhere costs more than staying put. This dynamic has a name in the research: the hyperscaler tax, and it's a primary reason AI teams go looking for pricing that's more transparent in the first place.

The fix is a storage layer that doesn't care which cloud is asking for the data. Cloudera's Anywhere Cloud, announced August 2026, lets teams run AI capabilities directly against their own proprietary data estates without moving the sensitive assets anywhere, cutting out the disruptive migrations and the vendor lock-in that usually come bundled together. If you query the data where it already lives instead of copying it somewhere new, the duplication cost that makes egress fees compound never gets created.

IBM's watsonx.data applies the same zero-copy logic to structured data at enterprise scale: querying data without duplicating it cuts duplication costs, removes ETL steps that would otherwise slow time-to-value, and builds a hybrid bridge between on-prem systems and the cloud. Active-use billing and cloud-agnostic storage aren't two separate features. One is the pricing model, the other is the condition that keeps the pricing model honest. Without a storage layer that can sit anywhere and be queried from anywhere, elastic billing is just provisioned billing wearing a usage-based label. Archil, a serverless filesystem that mounts S3 and GCS buckets as a native POSIX filesystem so agents can read and write against a persistent, shared workspace without data migration, is built on that same premise.