I price Giant Context at $25 per million tokens. Until this week I had no defensible answer to what it costs to serve a thousand customers. There is no billing export on the project, so every infrastructure figure I held was a bottom-up estimate of a system with one tenant on it, and every projection past that was multiplication.

Multiplication is the wrong operation. Four of the five cost classes on a cloud invoice are linear in something I already measure and they multiply fine. The fifth is a queueing problem with a closed-form answer, and it bends the curve down as traffic grows.

Bytes stored, bytes moved, tokens generated, seconds of CPU held. Every meter on a cloud invoice counts one of those four things, and every one of them is a quantity I already record. Where the map from telemetry to dollars is linear, forecasting is arithmetic and the only uncertainty left is the volume estimate. Sorting the meters by how they behave under growth gives five groups.

BigQuery on-demand analysis is $6.25 per tebibyte scanned with the first tebibyte each month free, Cloud Storage Standard is $0.020 per gibibyte-month, and egress out of North America is $0.12 per gigabyte after the first hundred. Rate times volume, and the only uncertainty is the volume. Free tiers are fixed grants rather than percentages, so they subtract once, which makes them enormous at one tenant and a rounding error at a hundred.

Cloud SQL does not scale smoothly. It jumps from a db-f1-micro to two vCPUs to four to a read replica to high availability, and each jump costs somewhere between $100 and $1,000 a month. The trigger is not customer count. It is connection pool exhaustion, then working set exceeding RAM, then IOPS saturation, roughly in that order. A rate card cannot say when a step fires, but it says exactly what the step costs, so instrumenting those three signals gives warning before the bill changes.

Cloud Monitoring bills $0.258 per mebibyte of chargeable metrics, and metric volume scales with services multiplied by label cardinality rather than with traffic. Ten times the requests through the same services costs nothing extra. One new label carrying a tenant ID multiplies the series count by the tenant count and produces a bill nobody modelled.

Cloud Run bills for instance time, and it bills it whenever an instance has at least one request in flight. Nothing in that rule mentions how many requests arrived. It asks how many instances were simultaneously busy, which is a different question with an exact answer.

The arrival rate, written as lambda, is requests per second. The service time, written as S, is how long one request takes end to end. Little's Law says the average number of requests inside the system at any instant is lambda multiplied by S. Call that L. Ten requests a second at 300 milliseconds each puts three requests in flight on average.

For randomly arriving traffic the number in flight is not merely averaging L, it follows a Poisson distribution with mean L, and that holds whatever the distribution of service times looks like. Real latency on these services runs from 40 milliseconds to several seconds, and the result is unaffected.

Cloud Run packs up to c requests onto one instance, where c is the concurrency setting. So an ideal packer needs N divided by c instances when N requests are in flight, rounded up, and the number billed is the average of that across the month. Because N is Poisson, that average has a closed form, and it behaves completely differently at each end of the traffic range.

The saving is 1.0 at the left, which means concurrency is worth nothing. Requests do not overlap at that volume, so an instance serves one at a time regardless of what the setting says, and setting concurrency to 1,000 on a service nobody uses changes nothing at all. The saving then climbs across two orders of magnitude of traffic and flattens just under 80, which is the concurrency setting. It cannot go past it.

Integrating over a day with a peak-to-mean ratio of 3, a bursty service at L near 1 costs 28 percent less than a flat one at the same average, because the quiet hours bill nothing and scale-to-zero is worth more than packing. At L near 116 the same burstiness costs 4 percent more, because peak hours need extra instances and a ceiling function is convex. Under L of about 80 the saving comes from idle time, above it from flattening the peak.

One service, 1 vCPU and 512 MiB, 300 millisecond average latency, concurrency 80, a diurnal traffic day. Cost divided by traffic so the two billing behaviours sit on the same axis, with free tiers excluded so the mechanics are visible rather than the grants.

The red line is flat because linear means constant unit cost. The blue line falls by a factor of 14 across four orders of magnitude and then stops. On the compute term alone the fall is steeper still, from $6.82 to $0.10 per million requests, a factor of 68 against a concurrency ceiling of 80.

Before trusting any of that I checked the closed form against a Monte Carlo simulation, generating exponential inter-arrival times and sampling the number of requests in flight across a long horizon. Agreement is to three decimal places, which is the sampling noise floor rather than model error.

The blue line flattens because Cloud Run request-based billing has two meters and only one of them packs. Instance time divides by concurrency. The $0.40 per million requests does not divide by anything. At 10 billion requests a month the compute term is $981 and the request term is $3,999, so four fifths of the bill is the meter that packing cannot touch.

Cloud Run has a second billing mode for that. Instance-based billing drops the per-request charge entirely and cuts the unit rates to $0.000018 per vCPU-second and $0.000002 per GiB-second, with a larger free grant of 240,000 vCPU-seconds. The trade is that it bills the full lifetime of every instance from start to termination, so idle time between requests is now chargeable where before it was free.

A 5.4 times saving at a billion requests, from a radio button. The right-hand column assumes instances sit idle only 25 percent longer than they are busy, and that number is not on any rate card. It is the only input here I cannot derive, because it depends on how tightly a real arrival pattern packs rather than on any published rate.

At perfect packing with no idle at all, instance-based wins from about a million requests a month. At 50 percent idle it wins from 13.5 million. At double, 58 million. At triple, 156 million. The ratio of billable instance time to busy instance time gives the crossover directly. Until that ratio is measured, request-based billing is the safe default, because it charges nothing for idle and idle is the term nobody can predict.

Giant Context served 438,187 requests and generated 598,315 metered tokens over the last thirty days, across eleven Cloud Run services with a single db-f1-micro behind them. Those are the driver coefficients, one dogfooding tenant's worth, and every column below is that usage multiplied out with the packing model doing the compute term and the step function doing Cloud SQL.

Unit cost falls from $34.30 to $7.50 per million requests, almost all of it landing before 300 customers, after which the curve is flat and further growth buys nothing on unit infrastructure. Then there is the spike at ten customers, where unit cost more than doubles.

That spike is the db-f1-micro giving out and a two vCPU instance arriving in its place, $11 a month becoming $135 for capacity nobody is using yet. Every provisioned step does this. Steps are the only places on the whole curve where growing makes a business less efficient, and they are exactly where a linear forecast says nothing is happening.

Every hour spent on the concurrency setting is an hour spent on the blue band, which is 8 percent of the bill at ten thousand customers. Egress is 69 percent. Putting a CDN in front of the platform at 85 percent cache offload saves $1,277 a month at a thousand customers and $12,833 at ten thousand, which is more than every compute optimisation in this post combined.

The egress coefficient behind that is 45 kilobytes per response, and it is my assumption rather than a measurement. It drives the largest line item in the model, which makes it the first thing I would replace with a real number, and it takes an afternoon to measure.

Gross margin ranges from 56 to 97 percent across that table and I had been quoting one point inside it. Both corners describe a plausible generation workload. Two counters on a meter I already run, model identifier and input against output, collapse the range to a number, and that is a smaller piece of work than any of the modelling above.

The corrected floor moves the break-even too. Calculated rather than estimated, the infrastructure floor at current usage is $15 to $30 a month rather than the $40 to $130 I had written down, mostly because 438,187 requests sit inside Cloud Run's free grant and cost nothing at all. Break-even against that floor is 0.6 to 1.6 million tokens a month depending on model mix, against the 4.3 million I had been planning around. Roughly double last month, not seven times it.