GB-Hour Pricing: Examples & Companies

What is it

GB-Hour Pricing is a billing unit where customers are charged for the memory their workloads consume over time, measured in gigabyte-hours.

A gigabyte-hour (GB-hour, sometimes written GiB-hour or memory-hour) is the product of two numbers: how much RAM a workload reserves and how long it holds it. Reserve 4 GB for 30 minutes and you have consumed 2 GB-hours. The unit exists because, on serverless and sandbox platforms, memory is a provisioned resource that costs the vendor money the entire time it is allocated — even when the CPU sits idle. Billing it separately, by time, aligns the invoice with the actual resource footprint rather than with a proxy like requests or seats.

GB-hours rarely travel alone. They are the second dimension in serverless billing, paired with CPU-hours (or vCPU-seconds) so the bill describes both halves of a container’s footprint. Modal bills memory at $0.00000222 per GiB-second right alongside its per-second CPU and GPU meters, and notes that idle containers still cost “only memory and storage” — a clean illustration of why memory needs its own line item. E2B does the same for code sandboxes, exposing a derived “RAM GB-hours” metric computed as run-hours times allocated RAM, and Together AI’s Code Sandbox bills GiB-hours separately from vCPU-hours for the same reason.

The unit is most common among compute-execution platforms: serverless functions, code-interpreter sandboxes, and the data-plane operations of usage-priced databases. Apify takes the idea to its logical conclusion, collapsing memory and runtime into a single synthetic “compute unit” defined as exactly 1 GB of RAM for 1 hour — so a GB-hour is the product’s headline meter rather than one input among several. At the database end of the spectrum, Qdrant meters the RAM its vector clusters consume by the hour, since a vector index lives largely in memory and the cluster’s memory footprint, not query volume, is what drives the bill.

How it works

The core formula is identical everywhere: memory cost equals allocated memory multiplied by the duration that memory is held, times a per-GB-hour rate. The variation is in what wraps around it — whether memory is billed per second or per hour, whether it is bundled into a synthetic unit, and what minimums apply.

The per-unit rates span a surprisingly wide band. E2B bills RAM at $0.0000045 per GiB-second — about $0.0162 per GiB-hour — Together AI’s Code Sandbox lists $0.0149 per GiB-hour, and Vercel bills provisioned memory at $0.0106 per GB-hour on Pro, while Modal charges $0.00000222 per GiB-second, roughly $0.008 per GiB-hour. That is close to a 2x spread on the same physical resource, which is why memory rate, not just CPU rate, belongs in any serverless cost comparison.

Unit math: A sandbox holding 4 GiB of RAM for 30 minutes consumes 4 × 0.5 = 2 GiB-hours. On E2B that memory line is ~2 × $0.0162 = $0.032; on Modal it is ~2 × $0.008 = $0.016 — before any CPU or GPU charge is added.

Composite units change the arithmetic without changing the principle. On Apify, an Actor running on 2 GB of RAM for 90 minutes consumes 2 × 1.5 = 3 compute units, billed at $0.2/CU on Free/Starter, $0.16 on Scale, and $0.13 on Business — so the same run costs $0.60 or $0.39 depending on plan tier. Some vendors keep the rate off the page entirely: Qdrant states its clusters are “priced based on CPU, memory, and disk storage usage” but publishes no per-GB-hour number — you size a cluster in its in-app calculator, which puts a 1M-vector production cluster at roughly $25-45/month. For the standalone calculators that model these blended meters, see the pricing calculator hub.

Companies using this

Eight companies in the corpus meter memory in GB-hours, almost all of them compute-execution or usage-priced-database platforms. Modal and E2B are the cleanest examples — per-second memory billing paired with per-second CPU — while Apify is the outlier that makes GB-hours its primary headline meter, and Qdrant and turbopuffer bring the pattern into vector databases.

Patterns observed

• Memory never bills alone. Every company on this page pairs GB-hours with at least one other compute meter — Vercel buries it among seven parallel meters, and even database platforms like Qdrant meter RAM alongside vCPU and storage. The GB-hour exists to complete the resource picture, not to be the whole bill.
• Granularity splits by workload lifetime. Sandbox platforms meter per GiB-second because their jobs are short; always-on clusters like Qdrant’s can afford coarser hourly metering. The “GB-hour” label is a unit of account, not the resolution the meter actually runs at.
• Memory rates move down, not up. Apify cut compute-unit rates ~20-25% across all tiers in September 2025, and E2B’s vCPU rates have held flat across the entire tracked range. GB-hour meters in this corpus trend cheaper or stable, never more expensive.

Counterexamples & variants

The most interesting variant is turbopuffer, which is not a compute platform at all — it is a serverless vector database built on object storage. It bills the majority of usage per write, per query, and per GB-month of storage, with GB-hours appearing only for a narrow feature: namespace pinning, introduced in April 2026, which keeps a namespace warm in memory for latency-sensitive workloads. Pinned namespaces bill in GB-hours (scaling with size, replica count, and time pinned) with floors of 64 GB and 10 minutes. Here GB-hours are an opt-in alternative to per-query billing, not the default — the opposite of Apify, where they are the default. Qdrant sits at the far end of the same axis: it makes provisioned RAM the entire default bill and charges nothing per query, a deliberate capacity-not-query counter-position to serverless rivals — but it never publishes the per-GB-hour rate, so buyers can only see the number after sizing a cluster in-app.

Apify is the inverse counterexample — GB-hours as the entire compute story rather than a supporting meter — and the risk of that abstraction is opacity: a buyer who only sees “compute units” cannot tell whether a cost spike came from more memory, longer runtime, or both. Novita AI shows where the model gets thin: its agent sandbox bills “per second on vCPU and memory,” but the published example (~$0.3744 for a 1-hour job on 8 vCPU + 8 GiB RAM) blends the two so tightly the memory component is never quoted on its own. When memory disappears into a single per-second sandbox rate, the GB-hour stops being a meter the buyer can optimize against.

What this means for buyers vs vendors

For buyers

Ask for the per-GiB-hour (or per-GiB-second) memory rate separately from the CPU rate — the spread is large (Modal’s ~$0.008/GiB-hour versus E2B’s ~$0.0162/GiB-hour is roughly 2x), and over-provisioned RAM is the most common source of silent overage. If a vendor bundles memory into a synthetic unit like Apify’s compute unit, get the GB-per-unit definition so you can model the impact of right-sizing memory; if a vendor hides the rate behind a calculator like Qdrant does, size a representative cluster before you commit. Watch for minimums: turbopuffer’s 64 GB / 10-minute pinning floor means small or short workloads pay more than the headline rate implies, and Vercel includes only 360 GB-hours on Hobby before metered memory begins.

For vendors

GB-hour billing fits any product that provisions memory the customer can’t see consuming — serverless functions, sandboxes, warm database namespaces, and always-on vector clusters like Qdrant’s. It requires per-second (or at least hourly) metering infrastructure and the ability to attribute reserved memory to a tenant over time, which is heavier than counting requests. The packaging decision is whether to expose memory as its own line (transparent, like Modal, E2B, and Together AI) or fold it into a composite unit (simpler to reason about, like Apify) — the former wins trust with cost-conscious engineers, the latter lowers cognitive load for everyone else. For the broader trade-offs, see the introduction to usage-based pricing and our note on billing cycles and invoicing.

Explore this theme in the knowledge graph →