Forty frontend packages move into one monorepo - 12 applications and 28 shared libraries including the design system. CI runs affected builds and tests on every push. The team opens about 140 pull requests a week and a full build and test of everything takes 95 minutes of runner time. Roughly what does CI cost per week with no scoping, with affected-graph scoping, and with a remote task cache - and which assumption dominates the error?

The assumptions, stated

• 140 pull requests a week, 2.5 pushes each - rebases, review fixes, a lint fix. That is about 350 CI runs a week, and this multiplier is the one teams forget.
• Full fan-out run: 95 runner-minutes.
• A typical product pull request touches one application and maybe one library, so the affected set is roughly 15% of the task graph - call it 14 minutes.
• 10% of pull requests touch the design system or the shared tooling config, and those fan out to all 12 applications, so they pay the full 95 minutes.
• Hosted Linux runner list prices in 2025 sit on the order of US$0.01 per minute for a small instance. Use that as an order of magnitude, not a quote.

The arithmetic

No scoping: 350 runs x 95 min = 33,250 runner-minutes a week - about 554 runner-hours, on the order of $330 a week, $17k a year.

Affected-graph scoping: (35 hub runs x 95) + (315 scoped runs x 14) = 3,325 + 4,410 = 7,735 minutes, about 129 hours, on the order of $77 a week. Scoping removes roughly four fifths of the bill.

Remote task cache on top: the cache does not help the task that changed; it helps everything downstream whose inputs did not change, plus every re-run after a rebase. At a 60-70% task hit rate - a realistic steady state once cache keys are clean - the scoped work falls to roughly 3,000 minutes, on the order of $30 a week.

The number, with its range

$1.5k to $4k a year once scoped and cached, against about $17k unscoped. The range is wide because the hub share swings it: at 25% of pull requests touching shared code the scoped bill nearly doubles to about 12,400 minutes.

The money is the small number. The expensive resource is wall clock: 95 minutes of feedback against 14 means a reviewer round trip per day instead of three, across every engineer.

Which assumption dominates the error

The share of pull requests that touch a hub package. Everything else moves the answer by tens of percent; this moves it by multiples, because a change to the design system is by construction unscopeable - the graph is telling the truth. Pushes per pull request is second, and it is the one you can measure in an afternoon from your CI history.

Cache hit rate is third and it is self-inflicted: a task that reads the git SHA, the current time, an unpinned toolchain or an over-broad input glob never hits, and teams usually discover their real hit rate is near 20% rather than near 70%.

What the number rules in or out

It rules the monorepo in. At this size the compute is not the argument, so a team arguing against consolidation on CI cost is arguing against the wrong number.

It rules out one thing: a hub package with no granularity. If more than roughly 30% of changes land in shared code, affected-graph scoping buys little, and the next move is finer task boundaries - per-component entry points, type-only changes that skip runtime suites, visual tests split from unit tests - not more runners.

When this is the wrong answer

At three packages and two engineers, none of this is worth building. The whole weekly bill is under an hour of engineer time, and a remote cache is a service to operate, a cache-key correctness problem and a supply-chain surface. Run everything on every push until a full run exceeds roughly 10 minutes or the monthly bill exceeds a day of engineering time, then scope, then cache - in that order, because scoping is configuration and caching is infrastructure.