Continuous integration used to be a machine under someone's desk. Now it is metered compute, billed by the minute or the seat, and the bill lands on whoever signed the enterprise agreement. Editors, package managers and hosted platforms each have a different answer to who should absorb that cost, and the answer usually follows the contract rather than the engineering.

The CI Bill Becomes a Line Item

Hosted CI is priced like a utility. Minutes are metered, concurrency is capped, and the overage rate sits in an appendix most engineers never read. Procurement teams started asking about runner quotas because the invoice moved, not because the pipeline changed. A repository that adds two test shards can double a monthly bill without anyone touching a pricing page.

The mechanics are worth spelling out because they are easy to underestimate. A hosted runner is billed per minute of wall-clock time, rounded up, and a job that queues before it starts still counts once it is picked up. Multiply one push by a matrix of three operating systems and two language versions and you have six billed jobs from a single commit. Do that on every branch rather than on merge, add a nightly schedule, and the arithmetic gets away from you quickly. Most teams discover this after the first full month, when the invoice reflects a workflow nobody deliberately designed.

Open-source projects sit in an awkward spot. Maintainers get free minutes on some platforms, but the allowance is discretionary and rarely covers a matrix build across several operating systems. When a popular library's CI queue backs up, the cost lands on volunteers or on a sponsor's account. Neither is a stable arrangement for infrastructure half the ecosystem depends on.

Vendors bundle minutes into enterprise tiers for a reason. Once compute is inside the contract, the pipeline becomes part of the renewal conversation. The tool that shows you a red build icon in the editor is not the tool that shows you the invoice, and that gap is where most budget surprises live.

Editors Ship Their Own Runners

GitHub Actions meters minutes by runner type and caps them per plan, with overage billed separately. GitLab folds compute into its premium tiers and sells additional minutes as an add-on. Both models treat CI as a platform service, which makes the pipeline sticky in a way a standalone build server never was.

Editors push the other direction. JetBrains IDEs and VS Code extensions encourage running tests locally before a push, which shifts the cost from a metered runner to the developer's laptop. That is cheaper for the employer in cash terms and more expensive in wall-clock time. A test suite that takes four minutes locally and ninety seconds on a warm cloud runner is not obviously a saving.

The trade-off is real and rarely stated. Local runs depend on hardware the company already bought, so the marginal cost looks like zero. It is not zero. It is amortized into the laptop refresh cycle and the engineer's attention, and those are harder to audit than a line on an invoice.

There is a second-order effect on pipeline design. When tests run locally, engineers tend to run a subset, the one covering the file they just changed. That habit is good for latency and bad for coverage discipline, because the full matrix only runs in the cloud on push. Teams that lean hard on local execution often find their integration failures cluster in the combinations nobody runs by hand. The editor integration makes the fast path pleasant and quietly demotes the thorough one.

Package Managers Inherit the Build Tax

Every pipeline run pulls dependencies, and every pull is time you pay for. Registry mirrors and dependency caching cut that time, which is why platform vendors sell caching as a feature. A warm cache can turn a six-minute install into under a minute, and that difference multiplies across every job in the matrix.

Lockfile churn triggers redundant runs. A dependency bump that touches one hash can invalidate a cache key and rebuild the whole tree, so a trivial version pin costs the same as a fresh checkout. Teams that pin aggressively and review lockfile diffs pay less than teams that let a bot merge them nightly.

The package manager matters here more than most engineers expect. Ecosystems that resolve dependencies from a single lockfile tend to cache cleanly, while those that resolve at install time from a manifest can produce a different tree on every runner. The second pattern is not wrong, but it makes caching unreliable, and unreliable caching means you pay for the cold path more often than the warm one. Choosing a resolver with deterministic output is a build-cost decision as much as a correctness one.

Private registries are priced per egress gigabyte on several commercial offerings, which makes the package manager a billing surface. npm, PyPI and Maven Central handle this differently, and the commercial mirrors built on top of them differ again. A related piece on open source licenses and cloud vendor contracts covers how that revenue split gets negotiated.

Contracts Decide Who Absorbs the Cost

Enterprise agreements usually cap monthly CI spend and set an overage rate for anything beyond it. The rates vary widely between vendors, and the caps are negotiable in a way list prices are not. Procurement teams now ask for runner quotas in the same meeting where they ask about seat counts, which was not true a few years ago.

Open-source maintainers are often excluded from those caps. A company's internal repositories sit behind the negotiated ceiling; the public project its engineers maintain on the same platform may not. That asymmetry is the sharpest objection to bundling, and the platforms have not resolved it.

There is a subtler contract problem in how seats and minutes interact. A plan that bundles a generous minute allowance with a per-seat price encourages adding engineers and discourages adding automation, because the automation consumes the shared pool while the people consume the seats. Teams respond by routing more work through fewer accounts, which is exactly the kind of workaround that makes an audit unpleasant later. The pricing shape steers behavior whether or not anyone intended it to.

The cost of getting this wrong shows up slowly. A pipeline that creeps from ten minutes to forty across a year rarely triggers a review, because no single change looks expensive. The renewal does. This site has argued before that build systems become the longest-lived code a company owns, and the billing attached to them outlives the teams that set it up.

Market Structure Favors the Bundlers

Platforms that sell editor, CI and registry together have an advantage that has little to do with quality. Each piece makes the next harder to leave. A team that moves its CI but keeps its registry and its code review has done a migration and gained nothing, so the bundle holds.

Standalone CI vendors get squeezed. They compete on runner speed and price against companies that can subsidize compute from a broader subscription. Some survive on self-hosted deployments where the customer owns the hardware, which removes the metering problem entirely and reintroduces the operational one.

Self-hosting deserves a fair hearing rather than a dismissal. The metered cost disappears, but someone now owns patching, capacity planning and the on-call rotation for the build fleet. For a team large enough to keep a platform engineer busy, that trade is often favorable. For a team of fifteen, the operational load is a hidden tax that lands on whoever is nearest the build system, and that person already has a job.

Switching costs are measured in engineer weeks. Rewriting pipeline configuration, reissuing secrets, and re-establishing cache behavior is a quarter's worth of side work for a mid-sized team. That number, more than any per-minute rate, explains why the market consolidates around whoever already holds the repository.

Practical Moves for Engineering Leads

Start with the invoice. Pull monthly CI minutes broken down by repository and runner type, and find the three repositories that consume the most. They are almost never the ones anyone would guess, and the breakdown usually reveals a matrix job that runs on every push instead of on merge.

• Audit monthly CI minutes by repository and runner type before the next renewal conversation.
• Cache dependencies at the registry layer so lockfile churn does not force a full reinstall.
• Negotiate runner quotas and overage rates into the enterprise agreement rather than accepting list pricing.
• Move low-risk test suites to local runners and keep the slow integration matrix in the cloud.
• Track egress costs on private registries, which often hide behind a separate invoice line.
• Set a build-time budget per job and alert when a pipeline drifts past it, so creep surfaces before the renewal does.

The objection worth taking seriously is that local runners shift cost onto engineers who did not choose the hardware. A team on older laptops will feel a local test suite as a tax on their day, and no invoice will show it. Measure before moving anything.

Budget for pipeline depth as a recurring cost, not a setup cost. A related piece on inference bills overtaking training spend makes a similar point about compute that looks like a one-time purchase and behaves like a subscription. CI is the same shape, and the contracts that govern it are worth reading before the renewal, not after.