Summary

  • Fastly's current public Compute price table has two meters: request count and consumed vCPU milliseconds. It no longer lists the old memory-times-duration charge.
  • The first 10 million requests and 100 million vCPU milliseconds per month sit in separate free bands. Above them, the first paid bands are US$0.50 per million requests and US$0.05 per million vCPU milliseconds.
  • A reusable sandbox serving a request cannot take another while that request waits for asynchronous work. Fastly starts another sandbox for the next arrival; reuse does not change the request count.

The old Compute bill could charge for a room while the machine inside waited. Fastly removed that duration meter in April, replacing the public self-purchase model's three-part calculation with two counters: arrivals and active vCPU time. The current price page makes the change concrete. The first 10 million monthly Compute requests and 100 million vCPU milliseconds have separate free bands. The next bands charge US$0.50 per million requests and US$0.05 per million vCPU milliseconds. Those figures describe Fastly's published usage schedule, not a customer's negotiated invoice.

The accounting switch changes a developer's incentive. A request blocked on an external answer no longer accumulates the old memory-allocation-times-wall-clock meter. It can still count as one of the requests. And the sandbox handling it cannot host the next arrival until that handler finishes. Fastly's execution guide is explicit: even when a request is temporarily idle, its sandbox remains dedicated; a new request gets a new sandbox. The company has moved the price clock without making the occupied seat disappear.

That matters most where a team mistakes a billing metric for a capacity metric. A slow dependency may leave the CPU meter almost still while causing more sandboxes to be opened for concurrent arrivals. Reusable sandboxes can reduce repeated initialization, but Fastly says they handle one request at a time and do not change request counting. The feature can alter work done per invocation; it cannot turn several simultaneous arrivals into one billable request.

The two free bands also need separate reading. A service can cross the request threshold before the vCPU threshold, or the other way around. The public price table supplies both scales, not a single blended allowance. A dashboard that shows only CPU efficiency could celebrate a leaner handler while an unchanged or growing arrival count keeps using the other meter. The mirror-image mistake is to optimize request volume and ignore expensive code paths.

Fastly's Go SDK exposes a vCPU-time reading for relative comparisons inside code, with a warning that absolute values from different runs and builds may not converge across platforms. That makes it useful for comparing operations, not for inventing a customer's bill from a benchmark. The authoritative charge still depends on the account's measured usage and applicable terms.

The missing facts for a particular application are its request volume, vCPU consumption, concurrency and contract. Those four readings would show whether the new meter rewards its design. The public documents already settle the market mechanism: Fastly stopped charging for Compute's old duration unit, while arrivals and active work remain on the tab and waiting still consumes an execution slot.

Sources