Monorepo CI cost: test sharding, remote caching, and selective execution

Monorepos Made CI Cost a Single Big Line Item

Five years ago a CI bill was a per-repository line item, easy to ignore because each repo’s spend was small enough to escape attention. The migration to monorepos — Nx, Turborepo, Lerna, pnpm workspaces, Bazel, Pants — collapsed the per-repo bills into one bill that grows with every engineer the company hires. By 2026 the monorepo CI bill is one of the top three infrastructure line items at most engineering organizations above 50 people, often larger than the production compute bill it builds for.

The reason is structural. A non-monorepo with thirty repositories has thirty independent CI pipelines that each run only when their repo changes. A monorepo with thirty packages has one pipeline that triggers on every change anywhere — and without aggressive optimization, runs every check on every package on every commit. The naive monorepo CI bill scales as (number of packages) × (number of commits) × (cost per check). Every term grows with engineering headcount. The bill compounds.

Three optimization levers — selective execution, remote caching, and test sharding — turn the cost curve flat. Used together correctly, they cut typical monorepo CI cost by 60-80% without losing coverage. Used incorrectly, they cut coverage and leave the cost curve growing. The 2026 playbook is the difference between the two.

Lever 1: Selective Execution (Build Only What Changed)

The single largest CI cost-saver in a monorepo is not running checks on packages that did not change. The pattern is universal across monorepo tools but the implementation details differ enough that the choice of tool matters.

Nx computes an “affected” graph for every change: starting from the changed files, it walks the package dependency graph and identifies which packages need re-checking. nx affected -t test runs tests only for affected packages. The dependency graph is explicit (every project declares its dependencies in project.json); Nx uses it for both selective execution and parallelization decisions.

Turborepo uses the same conceptual model with a slightly different surface. Its --filter flag accepts package selectors, and the [HEAD^1] git-range syntax lets the CI invoke turbo run test --filter=...[HEAD^1] to run only the packages affected by the last commit. The dependency graph is implicit in package.json dependencies plus Turborepo’s pipeline config.

Bazel is the most rigorous of the three: every target’s inputs are declared up front, and bazel query plus git diff gives a precise affected-targets set. Bazel’s selective execution is the strongest in the industry; it also has the highest setup cost because every package has to be bazelified.

The monorepo tool’s affected-graph quality directly determines the size of the CI cost saving. The teams that get the largest savings have packages with explicit, narrow dependency declarations; the teams that get the smallest savings declared everything as depending on a “common” package, which means every commit affects every package. The cost-optimization opportunity is mostly a dependency-graph hygiene project, not a tooling project.

Lever 2: Remote Caching (Don’t Rebuild What Has Already Been Built)

The second-largest CI cost-saver is caching the output of any deterministic build or test step so that the next run with the same inputs reuses the cached output instead of re-executing. Remote caching shares the cache across all CI runs and across all developers.

Bazel remote cache has been the gold standard since the late 2010s; the tooling around it (Buildbuddy, EngFlow, Buildbarn) matured in 2024-2025 to the point that running a remote cache is a paid managed service for most teams rather than a self-hosted operation. The cache hit-rate on a well-bazelified codebase is typically 70-90% for unchanged targets, which collapses CI run time by an order of magnitude on most pull requests.

Turborepo remote cache is built in (turbo run --remote-cache) and integrates natively with Vercel’s remote-cache service or with self-hosted alternatives. The deterministic-execution requirement is real but not nearly as strict as Bazel’s; teams typically reach high cache hit rates within a sprint of adopting it.

Nx Cloud plays a similar role for Nx workspaces, with the additional value-add of distributed task execution.

GitHub Actions cache and CircleCI workspaces are the per-tool, per-pipeline cache layers. They cache toolchains, dependencies (npm, yarn, pip), and intermediate build artifacts. The cache hit rate is typically 90%+ for dependency installation and 30-60% for build artifacts.

A correctly-configured remote cache plus selective execution typically delivers 60-80% CI cost reduction on monorepos that had been running everything on every commit. The cache layer is the source of most of the savings; selective execution is the source of the rest.

See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →

Lever 3: Test Sharding (Parallelism Without Wasted Compute)

Selective execution narrows what to run; remote caching skips what has already run; test sharding makes what is left run in parallel without overpaying for the parallelism. The naive answer is to add more runners. The cost-aware answer is to shard the work and right-size the runners.

Static sharding divides tests into N buckets up front (alphabetical, by file count, by historical duration) and assigns each bucket to a separate runner. Simple and effective for tests with predictable durations. Wasteful when a single test hangs or runs long.

Dynamic sharding (Knapsack Pro, GitHub Actions test-splitting actions, CircleCI test splitting) uses historical timing data to balance the buckets so all runners finish at roughly the same time. The total runner-minutes are similar; the wall-clock time is dramatically lower, and the lower wall-clock time matters because most CI cost models are runner-minute-based but most developer-experience pain is wall-clock based.

Adaptive sharding is the 2026 generation: a coordinator hands tests out as runners complete, no static assignment, work-stealing semantics. The coordinator-runner overhead is real but the load balancing is near-perfect.

The shard count matters too. Doubling the shard count typically halves wall-clock time but does not halve total runner cost; runner spin-up overhead and per-shard fixed costs mean there is a sweet-spot beyond which more parallelism stops paying off. Most teams pick a shard count by intuition; the cost-aware teams measure cost-per-PR-tested at multiple shard counts and pick the inflection point.

The Runner Cost Landscape: Where the CI Bill Actually Lives

The monorepo CI cost story is incomplete without the runner-cost story. The 2026 runner market has three real categories:

Hosted runners on the CI-as-a-Service vendor. GitHub Actions hosted runners, CircleCI cloud runners, GitLab CI shared runners. The convenience tax is real — these are typically 2-3x the cost of equivalent self-hosted compute, in exchange for zero operational overhead and tight integration. Most teams start here and most stay here longer than they should.

Self-hosted runners on the team’s cloud. GitHub Actions self-hosted runners, GitLab self-hosted runners, on-demand EC2 / GCE / Azure VM. The cost-per-runner-minute drops to underlying compute cost; the operational cost is real (auto-scaling, security patching, runner-image hygiene). Reasonable for teams with platform engineering capacity; over-engineered for teams without.

Managed CI compute. The 2024-2026 generation of services — Depot, Namespace, Blacksmith, BuildJet, Ubicloud, RunsOn — provide hosted runners at near-self-hosted prices, often with faster boot times and bigger machines than the CI vendor’s defaults. The category exists because the CI vendors over-charge for runner compute; the gap was big enough that a managed-runner market emerged. For teams with significant CI spend (typically $5K/month and up on hosted runners), the migration to a managed-CI-compute provider often pays for itself in two months.

The decision tree most teams should follow in 2026: start on the CI vendor’s hosted runners; once monthly CI cost crosses $3-5K, evaluate managed-CI-compute providers; consider self-hosted only if the team already has the platform engineering capacity and a strong reason (compliance, special hardware, network proximity).

CI Cost Attribution: What Most Teams Get Wrong

The single most common cost-optimization failure in monorepo CI is not knowing which package, team, or pull request is driving the bill. The CI bill arrives as a single line item; the team’s intuition about which workloads are expensive is almost always wrong.

The pattern that works:

• Tag every CI run with the package(s) it touched, the team owner, the PR number, and the commit. The data is already available in the CI runs; structured tagging surfaces it.
• Aggregate by tag in a small data pipeline (the CI vendor’s API → a daily warehouse load → a per-team cost dashboard). Most teams’ first run of this query is illuminating.
• Enforce per-team CI cost budgets by tagging at the runner-pool level when the platform supports it, or by surfacing the cost back to teams as a leaderboard so social pressure does the enforcement.

The cost-attribution work is unglamorous but it produces the highest-ROI cost-optimization conversations the platform team will have all year. “Team X’s CI cost is $4,000/month and 80% of it is one flaky integration test” is the kind of finding that moves spend down by tens of percent in a single sprint.

What an Active Cost Agent Adds on Top

Selective execution, remote caching, and test sharding are levers; cost attribution surfaces where the levers should be applied. An active cost agent on the active operational layer connects the two and runs the optimization continuously:

• Continuous attribution. The agent tags CI runs and re-aggregates the per-team, per-package, per-PR cost view hourly. Cost regressions are noticed in hours.
• Regression investigation. When a team’s CI cost jumps, the agent investigates the cause — new test added, cache hit rate dropped, runner pool resized, dependency graph collapsed onto a “common” package — and produces a rooted summary instead of a “your CI cost went up” alert.
• Reversible cleanup, autonomous. Disabling stuck workflow runs, retiring unused runner pools, applying TTL to PR-specific cache keys that survived their PR. Always within capability-tier policy.
• Irreversible cleanup, gated. Workflow rewrites, package-graph restructuring, runner-tier downgrades — always escalates to a human approver with the data.
• CI cost dashboard. Generated from the agent’s attribution graph, not maintained by hand, queryable per-team and per-package without the platform team writing queries.

The Three-Phase Rollout

Phase 1 — Selective execution + remote cache. Get the affected-graph or filter-based selective execution turned on. Stand up the remote cache. Most teams unlock 50-70% cost reduction in the first month, before any sharding work. Two-to-six weeks for an existing monorepo with reasonable hygiene.

Phase 2 — Cost attribution + test sharding tuning. Tag CI runs, build the per-team cost dashboard, surface the cost back to teams. Tune shard counts based on cost-per-PR-tested at the current scale. One-to-three months of mostly attribution work.

Phase 3 — Cost agent integration. Continuous attribution, regression detection, reversible cleanup autonomous, irreversible cleanup gated. Steady-state operation with the cost trend visibly bent.

The 60-80% cost reduction is achievable within a quarter for most monorepo CI estates. The teams that fail to capture it usually stalled on Phase 1 because the selective-execution graph was bad, not because the tooling was insufficient.

How IAN Helps

IAN’s cost agent runs the active operational layer pattern against CI cost the same way it runs against cloud compute cost. The agent ingests CI billing data, GitHub Actions / CircleCI / GitLab / Buildkite run metadata, and per-team tags, and produces continuous attribution and regression investigation against a single live cost graph.

Because IAN is BYOK on the model side, the cost-attribution analysis the agent runs uses the customer’s existing model contract, and because IAN is MCP-first, the agent surfaces in the platform team’s existing developer tools (Cursor, Claude Code, Codex) without a separate dashboard product. The Observe / Operate / Administer capability tiers apply: cost observation always-on, reversible cleanup autonomous under policy, irreversible cleanup gated to a human approver.

The CI cost line item that used to surface only at the quarterly business review surfaces continuously in the agent’s attribution graph, with the same audit-evidence trail that covers the rest of the active operational layer. The audit is the byproduct; the cost reduction is the operating-state result.

Get a free infrastructure audit → | See pricing →