CI contracts look like SaaS seat deals, but the meter runs on compute time. That mismatch explains most renewal surprises. This piece breaks down where the margin lives in hosted CI, how overage and lock-in actually work, and what finance never sees until the invoice arrives.

The Meter Runs on Every Commit

CI pricing is compute-time, not seats. Vendors charge per build minute on hosted runners, with concurrency limits gating how much you can spend at once. A monorepo multiplies every push: one commit can trigger dozens of jobs across services, each billed separately. Free tiers hide the marginal cost until the first overage invoice lands.

Build minutes bill like cloud egress. The base plan includes a bucket of minutes, and anything beyond that bills at an overage rate that is often several times the effective base rate. Teams that treat CI as a fixed line item miss this. The variable cost scales with commit frequency, test suite size, and runner specs.

The shape of that spend is uneven. A quiet week with a handful of merges can cost almost nothing, then a release branch with a full matrix of jobs and a flaky integration suite can burn through a month's bucket in a few days. Finance teams used to predictable monthly SaaS invoices find this pattern hard to forecast, because the driver is engineering behavior rather than headcount. The teams that get surprised are usually the ones that scaled up a test matrix or added a service without anyone checking what the new jobs cost per run.

A related piece on framework budgets splitting runtime and build makes a similar point about where costs hide. In CI, the hidden cost is idle capacity. Hosted runners sit warm between jobs, and that idle time is baked into the per-minute rate. You pay for the vendor's utilization problem.

Where the Margin Lives in CI

Hosted runners carry high gross margins. The vendor buys compute in bulk, packages it as a per-minute product, and prices for utilization. Idle capacity is the vendor's problem in theory, but the pricing model shifts it to you in practice. Concurrency limits are the lever: they cap how many jobs run at once, which caps your spend but also caps your throughput.

Overage rates dwarf base plans. A plan that includes a few thousand minutes might bill overages at a rate that makes the effective cost per minute two or three times higher once you exceed the bucket. The psychology is deliberate. The base plan looks cheap, and the overage is where the margin is made.

Runner sizing is the second margin lever. Vendors offer tiers — a couple of vCPUs at one rate, larger machines at multiples of it — and the price does not scale linearly with the compute. A job that needs four cores but is scheduled on a sixteen-core runner pays for twelve cores it never uses. Multiply that across every job in a matrix and the waste compounds quietly. Most teams pick a runner size once, during setup, and never revisit it, which is exactly what the pricing model rewards.

This site has argued in edge contracts that traffic growth undercuts that the real cost in infrastructure deals is the growth tier, not the entry price. CI works the same way. The entry plan is a loss leader; the overage tier is the product.

The Lock-In Is the YAML

Pipeline configuration is proprietary glue. Every CI vendor has its own YAML dialect, its own caching primitives, and its own artifact store. Migration cost sits in the scripts, not the contract. Teams that have built years of pipeline logic around a vendor's specific syntax face a rewrite to leave.

The lock-in deepens through integrations. A pipeline that posts status checks to a code host, pulls secrets from a specific vault, and publishes artifacts to a vendor-hosted registry has woven the CI tool into a dozen small dependencies. Each one is trivial on its own. Together they turn a migration into a quarter of work that nobody wants to schedule, so the renewal gets signed and the switching cost becomes self-fulfilling.

Caching and artifacts tie you down. Build caches are keyed to the vendor's storage layer, and artifact retention policies differ. Moving to a competitor means rebuilding cache warm-up from scratch, which shows up as slower builds for weeks. Self-hosted runners soften the exit: if your jobs run on your own machines, the vendor is a scheduler, not a compute provider.

The trade-off is real. Self-hosted runners reduce overage exposure but add operational overhead: patching, scaling, and security. A team that runs its own runners has traded a vendor invoice for an infrastructure team. That trade is worth it at scale and rarely worth it for a small team. The middle path — hosted for most jobs, self-hosted for the heavy ones — captures most of the savings with a fraction of the operational burden, though it means maintaining two execution paths and keeping them in sync.

Contract Terms That Bite Later

Annual commits with true-up clauses are common. You commit to a spend level, and if you exceed it, the true-up bills at list price, not the negotiated discount. That clause turns a growth year into a margin event for the vendor. Read the true-up language before signing.

Seat minimums bundled with minutes create a floor you cannot escape. If you buy fifty seats to get a better minute rate, you pay for fifty seats even if only thirty engineers commit code. The bundle looks like a discount and behaves like a minimum commitment.

Watch for the definition of a billable minute. Some contracts round partial minutes up, so a job that finishes in ninety seconds bills as two. Others exclude setup and teardown time from the count, and some include it. Over thousands of short jobs the rounding rule alone can shift the effective rate by a noticeable margin, and it is buried in the terms rather than the pricing page.

Renewal pricing resets after year one. Introductory rates are common, and the renewal quote often lands at list. Vendors count on switching costs keeping you in place. The log pipeline cost breakdown on this site shows the same pattern: the visible event is cheap, the surrounding infrastructure is where the spend accumulates.

What Finance Actually Sees

CI sits under engineering, uncategorized. It lands in a cloud or tooling budget line with no unit economics attached. Finance sees a monthly total, not a cost per pipeline or a cost per merge. That blindness is why overages surface at renewal rather than at the point of spend.

Cost per merge is never measured. A team that merges fifty pull requests a day and runs a full test suite on each has a per-merge cost that nobody calculates. Chargeback models miss build spend entirely because the invoice is not broken down by team or pipeline. The result is that the engineers who drive the cost have no visibility into it.

This is an accounting gap, not a technical one. The data exists in the CI vendor's API: minutes consumed per job, per branch, per user. Nobody joins it to the invoice. A finance team that asked for per-pipeline cost would get an uncomfortable answer about which services are expensive to maintain. It would also find the usual suspects: the service with the integration suite that runs the full database, the one with the end-to-end tests that spin up a browser for every branch, and the one whose cache key is wrong so it rebuilds from zero on every run.

Actions Before the Next Renewal

Instrument cost per pipeline run. Pull the CI vendor's usage API and join minutes consumed to pipeline name and branch. You cannot negotiate what you cannot measure.

Audit runner sizes against job needs. Most pipelines run on larger runners than the job requires. Dropping a tier on a test job that finishes in two minutes saves more than a discount negotiation.

Fix the caches before adding capacity. A cache that never hits is a silent multiplier on every job that depends on it, and a stale cache key is one of the cheapest things to repair. Check hit rates per pipeline and treat a low hit rate as a bug rather than a fact of life.

Negotiate overage rates explicitly. The base plan is rarely the lever; the overage rate is. Ask for a committed-spend discount that applies to overage, not just to the base bucket.

Keep a self-hosted fallback path. Even a partial migration of the heaviest jobs to self-hosted runners gives you a credible alternative at renewal. The threat of exit is worth more than the exit itself.

Model a two-vendor split. Running CI for different repos on different vendors is operationally annoying but financially instructive. It gives you a real price comparison and a real fallback if renewal goes badly.