The Hidden Cost Model Behind macOS CI Runners

Five ten-minute Mac builds were about to consume an entire roughly $35 monthly CI budget. The surprise in evaluating macOS CI runners was the 24-hour rental clock that each build could start, even after useful work had stopped.

Choosing macOS CI runners from three governing variables

I reduce this decision to three variables:

1. Demand timing: when builds and retries occur, including whether they can be batched.
2. Allocation policy: what starts and stops billing, the minimum allocation, and whether attempts can reuse paid capacity.
3. Production-proof requirements: the toolchain, packaging path, checks, and credential handling that the release must retain.

Demand timing and allocation policy determine the billable quantity. Production-proof requirements eliminate options that cannot execute the real release path. That leaves an economic comparison among technically admissible runners.

In this case, five builds were expected across twenty working days. Five consecutive builds can share capacity. Five builds on separate release days can create five allocation windows. Keeping a host between releases buys idle capacity, while releasing it means the next build must acquire another host.

The diagram shows the boundary of this calculation. It compares minimum host allocation for two timing patterns. It does not estimate queues, acquisition failures, startup delay, or concurrent demand.

The dated break-even calculation

The approved ceiling was roughly $35 per month for the whole pipeline. Baseline CI charges, retries, storage, and other applicable costs therefore reduce the amount available for Mac capacity.

baseline pipeline cost
+ billable Mac allocation cost
+ retry allowance
<= roughly $35 per month

As reviewed on 5 August 2026, AWS states that EC2 Mac Dedicated Hosts are billed per second with a 24-hour minimum allocation period. The Dedicated Host is the billing unit. This official fact establishes the allocation boundary, but it does not supply an effective rate for this article.

If five scattered builds each require a separate allocation, the minimum is 120 host-hours. Before baseline charges, retries, or storage, the host rate must satisfy:

$35 / 120 host-hours = $0.2917 per host-hour

If all five builds fit within one allocation, the corresponding threshold is:

$35 / 24 host-hours = $1.4583 per host-hour

My recommendation is conditional: use the dedicated-host option only if its reviewed effective rate is below the applicable threshold after subtracting every non-host charge from the ceiling. At exactly $0.2917 per hour, five separate allocations already consume the entire nominal budget. Any baseline or retry cost makes that rate too high.

The retry rows show why a monthly attempt count is insufficient. A timestamped retry can reuse already purchased capacity or open another 24-hour period.

A small executable allocation model

The following program groups timestamped attempts into allocation windows. Each timestamp is an integer minute from the start of the month. An attempt reuses the current host when it begins before that allocation’s paid-through time; otherwise it opens a new window.

MINIMUM_MINUTES = 24 * 60
BUILD_MINUTES = 10
 
 
def allocation_windows(attempt_minutes: list[int]) -> list[tuple[int, int]]:
    """Return (allocation_start, paid_through) for one serial host."""
    windows: list[list[int]] = []
 
    for attempt in sorted(attempt_minutes):
        attempt_end = attempt + BUILD_MINUTES
 
        if windows and attempt <= windows[-1][1]:
            windows[-1][1] = max(windows[-1][1], attempt_end)
        else:
            windows.append([attempt, attempt + MINIMUM_MINUTES])
 
    return [(start, paid_through) for start, paid_through in windows]
 
 
batched = [540, 550, 560, 570, 580]
scattered = [540, 4 * 1440 + 540, 9 * 1440 + 540,
             14 * 1440 + 540, 19 * 1440 + 540]
scattered_with_retry = [*scattered, 9 * 1440 + 570]
 
assert len(allocation_windows(batched)) == 1
assert len(allocation_windows(scattered)) == 5
assert len(allocation_windows(scattered_with_retry)) == 5

This proves only allocation-window grouping under a 24-hour minimum for a single serial host. It does not model host availability, concurrency, startup latency, provider billing granularity beyond the stated minimum, storage, or labor. It also assumes explicit release after the paid-through time and treats every attempt as ten minutes. Those omissions require measured or reviewed inputs before production approval.

Compare admissible operating models

A low price is irrelevant when the executor cannot run the required native toolchain, packaging path, or release checks. I first validate production parity, then compare the remaining operating models.

A hosted service is attractive when its charges track short jobs closely, but that conclusion needs its current terms and a successful production-faithful build. Signing credentials should have narrow scope and a defined cleanup path. External queues and image changes remain release risks.

A controlled physical Mac avoids rented allocation windows. It does not make hardware or operations free. Under this budget, it is financially plausible only when acquisition and labor are already sunk or funded elsewhere. That accounting choice must be explicit.

For the scenario as stated, I would not approve a dedicated host from compiler duration alone. I would obtain the reviewed effective host rate, baseline charges, release timestamps, and retry history. If scattered demand is representative, the rate must be below $0.2917 per hour before other costs, and lower once those costs are included. If the team accepts batching, the economic boundary changes, but so does release policy.

FAQ

What evidence should I collect before comparing runner prices?

Collect timestamped builds and retries, current billing terms, baseline charges, and the mandatory production checks. Attempt counts without timing cannot show allocation reuse.

Does a retry always add another 24-hour allocation?

No. A retry inside an active paid window can reuse the same host; a later retry may open another allocation. The result depends on its timestamp and the release policy.

When should this decision be reviewed again?

Review it when demand timing, allocation terms, concurrency, baseline costs, or production-proof requirements change. Runner image and credential-handling changes also warrant another production validation.