The State of CI/CD Cost Optimization 2026

Where engineering teams are actually cutting CI spend in 2026, ranked by what each lever really returns rather than how often it gets talked about.

Executive summary

CI has quietly become one of the largest variable line items in an engineering org's cloud bill, and in 2026 finance teams are asking platform groups to defend it. The good news in the data is that most of the spend sits in a handful of well-understood places, and the levers that move it are pipeline hygiene rather than rewrites. There is no heroic project hiding here, only a short list of mechanical wins that most teams have simply not gotten around to.

This report ranks the savings levers by realized return rather than by how often they are talked about, because the two orderings differ. Caching and shifting work to Linux land at the top because they attack minutes that produce no signal at all: re-installed dependencies, re-built artifacts, and expensive-OS minutes doing work that Linux could do identically. Right-sizing runners and moving steady-state load to managed capacity then compound on the smaller, leaner pipeline that remains.

The single most important idea in the report is sequencing. The levers are multiplicative, not additive, because each one acts on the bill the previous one already shrank. Cache first so the pipeline does less work, then shift the heavy legs to Linux, then right-size what is left, then move the steady-state remainder to managed runners. Applied in that order, each lever operates on a smaller base than the last, and the realized savings compound rather than simply summing.

The opposite mistake is the common one: teams jump straight to cheaper or bigger runners without caching first, and end up buying cheaper minutes for work they never needed to repeat. The bill moves, so it feels like progress, but the pipeline is still re-installing the same dependencies and re-running the same expensive-OS legs on every run. The cheap-runner lever is real, but it belongs last, after the work that should never have run has been removed.

None of this requires touching application code. The teams that cut the most simply stopped paying for work their pipeline did not need to repeat, on hardware it did not need to run. The wasted-minutes breakdown that anchors this report shows where the removable spend hides, and every lever in the ranking is a configuration or infrastructure change rather than a change to a single test or a line of product code.

Caching is the single highest-return lever, and most pipelines barely use it

Dependency installs and re-built artifacts dominate the removable portion of a CI bill because they recur on every run and produce no new signal. The wasted-minutes breakdown shows re-installed dependencies and re-built cacheable artifacts together accounting for the majority of the cuttable spend, ahead of expensive-OS minutes and oversized runners combined. That is the clearest evidence that caching, not cheaper hardware, is where the largest single saving sits.

A warm dependency cache and an artifact or layer cache together remove the largest slice of wasted minutes before any other change. The mechanism is straightforward: work that does not change between runs should be restored rather than recomputed, and a well-keyed cache does exactly that. The reason caching tops the savings-levers ranking is not that it is clever but that it attacks the biggest pile of pure waste in the pipeline, the work that re-runs identically every time.

It is the least glamorous lever, which is precisely why it is underused. Caching is finicky to configure well, its payoff is invisible unless someone measures the hit rate, and it lacks the satisfying immediacy of switching to a cheaper runner. So teams skip it and reach for the visible levers instead, leaving the largest saving on the table. The data is unambiguous that caching ranks first by modeled return, and that most pipelines capture only a fraction of it.

• Re-installed dependencies and re-built artifacts are the two largest slices of removable spend, ahead of OS and runner-size waste combined.
• Caching restores unchanged work instead of recomputing it, which is why it leads the savings ranking.
• It is underused because its payoff is invisible without a measured hit rate, not because it returns less.

The Linux shift is a pricing arbitrage, not a quality tradeoff

A macOS minute costs ten times a Linux minute and a Windows minute about twice, so a cross-platform matrix often concentrates the majority of spend in a minority of minutes. The relative-cost chart makes the gap visceral: the same job, run on macOS, costs an order of magnitude more than on Linux, which means a handful of expensive-OS legs can dominate a bill that is mostly Linux by minute count.

The waste is not the existence of macOS and Windows legs but what they are running. When teams audit their matrices, the expensive runners are routinely doing OS-agnostic work, linting, unit tests, dependency resolution, that would pass identically on Linux. The expensive hardware ends up doing cheap work, which is pure arbitrage waste: the same result for ten times the price, paid because the matrix grew up around defaults nobody revisited.

Moving heavy build and test legs to Linux and reserving macOS and Windows for the platform-specific steps that genuinely require them, signing, packaging, platform UI tests, captures most of that gap without weakening coverage. The platform-specific surface that truly needs an expensive OS is much smaller than the matrix that accreted around it, so the shift is a pricing arbitrage rather than a quality tradeoff. The coverage is identical; only the per-minute price changes.

Right-sizing beats up-sizing more often than teams expect

Bigger runners feel like a speed lever, and teams reach for them instinctively when a pipeline feels slow. But a larger runner frequently just adds idle headroom that bills by the minute, because most CI jobs are bound by sequential steps and network waits rather than by raw core count. Paying for cores a job never saturates is a steady tax on every run, and it is one of the quieter slices in the wasted-minutes breakdown.

Profiling peak CPU and memory per job and matching the runner class to it trims that tax across every run. The exercise is unglamorous, watch what a job actually uses, then size the runner to it, but it removes a recurring cost that scales with run count. The per-minute-rate chart shows how much room there is below the largest tiers; the goal is not the cheapest runner but the right one, the smallest class that does not slow the job down.

Right-sizing stacks cleanly on top of caching, which is why sequencing matters. A pipeline that caches well has less work in it, so the runner it needs to right-size for is smaller still: there are fewer cold installs and rebuilds demanding peak resources, so the matched runner class drops. Right-sizing a leaner pipeline removes more headroom than right-sizing a bloated one, which is the general pattern behind every lever in this report compounding on the ones before it.

Managed runners convert the leftover steady-state load into a flat discount

After caching and the Linux shift, what remains is steady recurring compute: the genuinely necessary build and test work that runs on every merge and cannot be cached away. This is the load managed runners are built for. It is predictable, it is continuous, and it is exactly the kind of steady-state demand that a managed per-minute rate prices well below hosted while a self-hosted fleet would either sit idle off-peak or starve jobs at peak.

Moving that load to managed runners captures a modeled saving of around 70 percent versus GitHub-hosted rates, as the per-minute-rate chart shows the managed blended rate sitting well under the hosted Linux line. The saving comes without the ops cost of scaling, patching, and cleaning a self-hosted fleet, which is the cost the naive self-hosting spreadsheet always omits. Managed captures most of the per-minute compute saving while removing the idle and the operations entirely.

Self-healing is the part of the managed story that touches the bill in a way teams often miss: transient failures do not re-bill the pipeline. When a step fails on a known-transient signal and the platform retries it on a fresh environment automatically, the minutes spent are recovery minutes rather than a full re-run paid from cold. A managed layer that recovers mechanical flakes in place keeps the steady-state discount from being eaten back by re-runs the team never should have paid for.

The levers compound, so sequencing matters

Applied in the right order, cache first, then shift to Linux, then right-size, then move steady-state load to managed, each lever acts on a smaller bill than the last, so the realized savings are multiplicative rather than additive. The savings-levers chart shows each lever's isolated return, but the isolated figures understate the combined effect, because in sequence every lever operates on the residue the previous ones already trimmed.

The reason the order is cache-first is that caching shrinks the work itself, which makes every downstream lever cheaper to apply. A cached pipeline has fewer minutes to shift to Linux, a smaller runner to right-size for, and less steady-state load to move to managed. Start anywhere else and you optimize a pipeline still carrying work it never needed to do, which is why the same set of levers can return very different totals depending purely on the order in which they are pulled.

Teams that jump straight to cheaper runners without caching first simply buy cheaper minutes for work they never needed to run. It is the most common and most expensive sequencing error, because it feels like progress, the bill drops, while leaving the largest pile of waste, the re-installed dependencies and re-built artifacts, fully intact. The cheap-runner lever is genuinely valuable, but it belongs at the end of the sequence, after the unnecessary work has been removed rather than merely re-priced.

• The levers are multiplicative in sequence because each acts on the bill the previous one already shrank.
• Cache first because it removes work, which makes the Linux shift, right-sizing, and managed move all cheaper to apply.
• Jumping to cheaper runners first buys cheap minutes for work that should never have run, the costliest sequencing error.

Concurrency and fail-fast stop paying for doomed runs

The smallest lever in the ranking is still real money: cancel-in-progress concurrency and fail-fast ordering stop the pipeline from spending minutes on runs that are already destined to fail or to be superseded. When a developer pushes three times in quick succession, there is no reason to finish validating the first two; cancel-in-progress kills the stale runs and bills only the latest. That is pure waste removed with a one-line configuration change.

Fail-fast ordering attacks the same waste from the other direction. Running the cheap, fast, most-likely-to-fail checks first means a doomed run dies in seconds rather than after a full matrix has executed, so the minutes spent on a failing change are a fraction of what they would be if the slow legs ran first. Neither lever requires touching a test; both simply stop the pipeline from doing work whose outcome no longer matters.

These levers return less than caching or the Linux shift, which is why they sit at the bottom of the savings ranking, but they are nearly free to enable and they compound with everything above them. On a pipeline already cached, Linux-shifted, and right-sized, cancelling doomed runs trims the last avoidable slice, and because it is configuration rather than code it carries no risk. They are the finishing move rather than the opening one, but they belong in the sequence.

The cost story and the reliability story point at the same setup

Read together, the levers in this report describe a single architecture rather than five disconnected tactics. A pipeline that caches aggressively, runs OS-agnostic work on Linux, right-sizes its runners, moves steady-state load to managed capacity, and cancels doomed runs is also a pipeline that is fast and reliable, because the same changes that remove cost also remove waiting and mechanical failure. Cost optimization and delivery performance are not in tension; they are the same work.

The clearest example is self-healing. Recovering transient failures in place is a reliability feature, it keeps mechanical flakes from reaching a developer, and a cost feature at the same time, because it stops a transient blip from re-billing the whole pipeline. A team that adopts it gets a more dependable pipeline and a smaller bill from one change, which is the pattern across the whole report: the optimizations that cut spend are the same ones that make CI faster and steadier.

This is why the teams that cut the most are rarely running a cost-cutting program in isolation. They are running a managed, well-cached, Linux-first pipeline because it ships faster, and the lower bill comes along with it. The practical takeaway is that defending the CI budget and improving delivery are not competing priorities to be traded off, but two readings of the same short list of mechanical improvements, applied in the right order on a runner layer that removes the rest automatically.

Recommendations

Cache dependencies and build outputs first

Re-installed dependencies and re-built artifacts are the two largest slices of removable spend, so caching is the highest-return lever and the right place to start. Key caches to the dependency manifest and toolchain version, split dependency caches from build-output caches, and measure the hit rate so you can tell a working cache from one that silently stopped hitting.

Shift OS-agnostic work to Linux

A macOS minute costs ten times Linux and Windows about twice, and the expensive runners are usually doing OS-agnostic work that Linux could do identically. Move linting, unit tests, and dependency resolution to Linux and reserve macOS and Windows for signing, packaging, and platform UI tests. The coverage is identical; only the per-minute price drops.

Right-size runners to actual peak usage

Bigger runners often just add idle headroom that bills by the minute. Profile peak CPU and memory per job and match the runner class to it rather than defaulting everything to the largest tier. This stacks on caching, because a leaner pipeline has less work to oversize for, so the matched runner class drops further.

Move steady-state load to managed runners

After caching and the Linux shift, the steady recurring compute that remains is exactly what managed runners price well, around 70 percent below GitHub-hosted, while removing the ops cost of a self-hosted fleet. Self-healing on that layer means transient failures recover in place rather than re-billing the pipeline as a full re-run.

Sequence the levers; do not jump to cheap runners first

The levers are multiplicative in order: cache, then Linux-shift, then right-size, then managed, then concurrency. Each acts on the bill the previous one shrank. Jumping straight to cheaper runners buys cheap minutes for work that should never have run, the most common and most expensive sequencing error. Pull the work-removing levers before the price-reducing ones.

Outlook

Expect CI cost to stay under finance scrutiny through 2026 and beyond, because it is a variable cloud line item that grows with the codebase, and the levers to control it are now well-enough understood that leaving them unpulled is hard to defend. The teams that treat CI cost as a tracked metric, with a cost-per-merge figure alongside their delivery metrics, will keep the bill flat as they scale while their peers watch it climb with headcount.

The architectural direction is toward runner layers that capture most of these levers by default. A managed runner with a fast co-located cache, a Linux-first posture, and self-healing built in delivers the caching, the Linux shift, and the managed-rate saving as properties of the platform rather than projects the team has to run. As that becomes the baseline, the gap between optimized and unoptimized pipelines will widen, because the optimized setup will increasingly be the default one rather than an achievement.

For most teams the practical takeaway is that the CI bill does not need a heroic project, it needs the levers pulled in the right order. Cache the repeated work away, run the OS-agnostic legs on Linux, right-size what is left, move the steady-state remainder to managed capacity, and cancel the doomed runs. Done in sequence on a runner layer that removes the mechanical waste automatically, that turns CI from a line item finance questions into one that scales with usage rather than with the size of the team.

Methodology

This report ranks CI cost-optimization levers by modeled return, derived from published GitHub-hosted runner pricing and Latchkey's analysis of typical web-app pipeline shapes. Per-lever percentages are illustrative estimates applied to an unoptimized Linux-and-macOS baseline and will vary with each pipeline's cache hit rate, OS mix, and job profile. Managed runner economics assume a blended rate of $0.0025/min, roughly 70 percent below GitHub-hosted. Figures labeled "modeled" are illustrative estimates derived from public pricing and typical pipeline shapes, not a primary survey; figures attributed to a named source reflect that source. Pricing reflects published rates at time of writing and should be verified against current provider pricing.

Sources

• GitHub Actions - billing & pricing
• GitHub Actions documentation
• Stack Overflow Developer Survey
• AWS EC2 On-Demand pricing

More Latchkey reports