CPU-Hour Pricing: Examples & Companies

What is it

CPU-Hour Pricing is a billing unit where customers are charged for the CPU time their workloads consume, typically measured in vCPU-seconds or vCPU-hours.

A vCPU-hour is the product of two numbers: how many CPU cores a workload reserves and how long it holds them. Run 2 vCPUs for 30 minutes and you have consumed 1 vCPU-hour. The unit exists because, on serverless and sandbox platforms, the customer is buying compute work — not a reserved server that sits powered on whether or not it is doing anything. Billing CPU time, rather than wall-clock uptime or a proxy like requests, aligns the invoice with the actual work performed.

The modern refinement is active CPU billing — metering only the milliseconds the CPU is genuinely executing code, not the time a process spends idle waiting on I/O. Vercel is the canonical example: its Fluid Compute model, switched to Active CPU billing in June 2025, charges only for CPU-active milliseconds — $0.128 per CPU-hour on the Pro plan. For an AI inference call that spends 50ms computing and 950ms waiting on the model, Vercel bills the 50ms and cites up to 90% savings on I/O-heavy workloads — the first Active CPU billing model from a major PaaS provider.

CPU-hours are most common among compute-execution platforms: serverless functions, code-interpreter sandboxes, distributed-training clusters, and on-demand GPU clouds where CPU is the cheap companion meter. Modal and E2B bill CPU per vCPU-second alongside their memory and GPU lines, BentoML meters a plain CPU instance at $0.00001322/sec, while CoreWeave and Nebius are large-scale GPU cloud providers where CPU billing completes the resource picture for customers running H100 and A100 clusters.

How it works

The core formula is identical everywhere: CPU cost equals allocated vCPUs multiplied by the time those cores are held, times a per-vCPU rate. The variation is in what counts as “held” — whether the meter runs on wall-clock uptime or only on active execution — and in how finely time is measured.

The per-vCPU rates cluster tightly at the bottom of each rate card. Modal bills a physical CPU core at $0.0000131 per second (about $0.047 per hour, with a 0.125-core minimum), E2B bills $0.000014 per vCPU-second (about $0.05 per hour, scaling linearly — 2 vCPUs cost $0.000028/s, 8 vCPUs cost $0.000112/s), and BentoML’s cpu.1 instance is $0.00001322 per second. The CPU line is almost always the least expensive meter; the cost in a real bill comes from memory, GPU, or runtime, not the cores.

Unit math: A sandbox holding 4 vCPUs for 30 minutes consumes 4 × 0.5 = 2 vCPU-hours. On E2B that compute line is ~2 × $0.05 = $0.10 ($0.000056/s × 1,800s); on Modal a comparable 4-core run is ~2 × $0.047 = $0.094 — before memory, GPU, or storage charges are added.

Active CPU billing changes the numerator without changing the formula. On Vercel, a Fluid Compute function that runs for one wall-clock second but only executes for 50ms is billed for 0.05 CPU-seconds, not 1 — so the same invocation pattern can cost a fraction of what a wall-clock meter would charge. Picking the right compute meter is a metric-selection decision as much as a packaging one; see the guide on choosing the right usage metric, and model a blended serverless bill with the Vercel pricing calculator.

Companies using this

Sixteen companies in the corpus meter CPU time, spanning serverless and sandbox platforms (Vercel, Modal, E2B, Trigger.dev, Novita AI), GPU clouds where CPU is the companion meter (CoreWeave, Nebius), ML platforms that fold CPU into inference or credit billing (BentoML, Hugging Face, LangChain, Anyscale, Lightning AI, OpenPipe, Together AI), and workflow or database contexts (GitLab, Qdrant).

Patterns observed

On every platform in this corpus the CPU line is an order of magnitude below GPU and often below memory. BentoML, CoreWeave, and Nebius all follow the same structure — the GPU is the primary cost driver, and CPU is billed to complete the resource picture for CPU-bound workloads. BentoML’s cpu.1 instance runs $0.00001322/sec against a T4 at $0.00014198/sec and an H100 at ~$2.65/hr; Nebius lists CPU-only instances from $0.05/hr (Intel Ice Lake) and $0.10/hr (AMD EPYC Genoa) against an on-demand H100 at $3.85/GPU/hr. CoreWeave and Nebius both run large-scale GPU cloud infrastructure where individual A100 and H100 instances dominate customer bills; CPU is present on every rate card but rarely the primary optimization target. The pattern holds across the GPU cloud cluster: a buyer running a training job on CoreWeave or Nebius will scrutinize GPU and networking costs far more carefully than the CPU line sitting at the bottom of the same invoice.

Per-second is the real granularity behind the “CPU-hour” label, and the distinction matters most for short workloads. Modal and E2B bill per vCPU-second; Trigger.dev bills per compute-second for serverless job execution, from $0.0000169/sec (Micro, 0.25 vCPU) to $0.00068/sec (Large 2x, 8 vCPU); Novita AI and Lightning AI both meter per second and only quote hourly rates for readability. The “CPU-hour” label exists so buyers can reason about cost, but these platforms meter at second or millisecond resolution because agent and sandbox workloads are short — a code-execution sandbox that completes in eight seconds should not round up to an hour, and it does not on any of these platforms. The per-second granularity is not a premium feature; it is the baseline expectation for any platform targeting short-lived compute jobs.

Active CPU as a differentiator sets Vercel apart from every other company in this set. Vercel is the only platform that meters execution time rather than wall-clock uptime, and it leans on that as a marketing wedge, citing up to 90% savings on I/O-heavy workloads. GitLab’s CI/CD compute, charged per CI minute, is also execution-time-based by nature — a pipeline only runs when it is running, so idle time between jobs does not accumulate. Trigger.dev’s serverless job billing similarly charges for active execution; a background job queued but not yet running, or paused on a checkpointed wait, accrues no compute cost. These three show that active-execution billing is not unique to web-function platforms — any execution context where jobs start and stop cleanly is a candidate for it.

Credit denomination and inference bundling hide the CPU rate for a significant portion of this corpus. Anyscale denominates CPU-only compute at $0.0135/hr in Anyscale Compute Units where $1 ACU literally equals $1, and Lightning AI draws per-second CPU and GPU usage from a credit pool where one credit is roughly a dollar. Together AI, OpenPipe, Hugging Face, and LangChain (for managed deployments) all wrap compute into an inference or platform API. Hugging Face’s inference endpoints bill per hour of deployed instance, but the CPU is bundled into the instance type — a buyer pays for the instance, not for its constituent vCPUs separately. For these companies the CPU-hour is a real cost the vendor absorbs and passes through in the credit or instance price, but it is not a line the buyer ever negotiates or optimizes against directly.

Counterexamples & variants

Vercel’s Active CPU billing carries a catch that never surfaces in a wall-clock model: predictability. Because the meter tracks execution profile rather than uptime, a workload’s cost depends on how compute-heavy it actually turns out to be — harder to forecast from a plan card than a flat per-second rate, and the price of subtracting idle time.

The credit-denomination structure (Anyscale, Lightning AI) makes the CPU rate invisible rather than merely cheap: a buyer comparing either platform to Modal must first translate a credit-denominated rate back into a per-vCPU figure before the numbers mean anything. That opacity is the trade for smoothing GPU and CPU onto one currency.

OpenPipe and Together AI show where the CPU-hour stops being a true compute meter. Both are token-first inference platforms; CPU-hours appear only at the edges — OpenPipe bills hosted inference “per-token or by hourly compute units,” and Together AI exposes them mainly through its Code Sandbox and dedicated-endpoint plumbing rather than a primary SKU. Here the CPU-hour is a cost the vendor absorbs, not one the buyer optimizes against.

Qdrant is the vector-database variant: rather than per-query pricing, Qdrant Cloud meters vCPU + RAM + storage hourly, so the cluster’s CPU allocation is a first-class billing dimension — even though a permanent free 0.5-vCPU tier exists and the pricing page never prints a dollar-per-vCPU-hour figure.

What this means for buyers vs vendors

For buyers

Ask whether the meter is active CPU or wall-clock — it is the single biggest cost variable on this page. An I/O-bound workload (an AI proxy, a database-backed API) can cost far less under Vercel’s Active CPU billing than under a wall-clock meter that charges every second the process waits. Then get the per-vCPU rate in a comparable unit; a platform that bundles CPU into a credit pool or instance price will require you to back-calculate the implied cost before any comparison is honest. And scrutinize the GPU and memory rates harder than the CPU line, because that is where the real bill lives.

For GPU-cloud procurement, model total cluster cost — GPU plus networking plus storage — rather than the per-vCPU rate: on CoreWeave and Nebius the CPU line is a rounding term next to the GPU. It matters mainly when a workload has significant CPU-only pre- or post-processing running separate from GPU inference.

For ML-platform and credit-pool billing, the meaningful comparison is between instance configurations (memory-optimized vs. compute-optimized), whether the platform supports scale-to-zero so idle endpoints accrue nothing (BentoML advertises this explicitly), and — for credit platforms — how many effective CPU-hours a dollar of credit actually buys.

For vendors

CPU-hour billing fits any product that runs customer code on shared compute — serverless functions, sandboxes, training clusters, on-demand instances. It requires per-second (or finer) metering and the ability to attribute core-time to a tenant, which is heavier than counting requests; the underlying metering and aggregation problem is covered in the guides on tracking and metering usage events and aggregation methods for usage-based billing. The defensible move is active-CPU billing: metering execution rather than uptime, as Vercel does, is a genuine customer-friendly innovation that doubles as marketing copy.

The packaging decision is whether to expose a discrete per-vCPU rate (transparent, like Modal, E2B, and BentoML) or fold CPU into a credit currency or instance price (simpler ladder, like Anyscale, Lightning AI, and Hugging Face) — the former wins trust with cost-conscious engineers, the latter smooths multi-resource pricing into one number. For platforms that adopt credit packaging, the operational risk is that the CPU-hour rate disappears into the credit price, making cross-vendor comparison harder and potentially obscuring vendor margin from sophisticated buyers.

Workflow-compute contexts — CI/CD pipelines and serverless background jobs, as GitLab and Trigger.dev demonstrate — are a natural fit for execution-time billing because the job boundary is well-defined: a pipeline starts, runs, and ends, with no ambiguity about what counts as active execution, and a checkpointed wait consumes nothing. For vendors building in these categories, per-minute or per-second execution billing is already the buyer expectation; the differentiation opportunity is in free-tier generosity and cold-start latency, not in the billing unit itself. For the broader trade-offs, see the introduction to usage-based pricing.

Explore this theme in the knowledge graph →