TL;DR: Replace the full cross-product matrix with a representative set: each dependency's min and max supported versions, plus one mid point, tested independently instead of combined. Cap matrix size in the agent's CI config and require human approval above it. One bump should run tens of jobs, not hundreds.

```text
agent tested every permutation of django x postgres x python and burned the month's CI budget in one night
```

1. Stop the bleeding: cancel the running matrix jobs and cap the agent's CI job count for the current run.
   Expected: no more new jobs spawn; the budget stops draining.
2. Rewrite the matrix strategy from cross-product to supported-range: for each dependency, test its lowest supported version and its latest version against the pinned others, not every combination.
   Expected: for 3 axes of 4 versions each, jobs drop from 64 to under 12.
3. Add fail-fast to the matrix so a broken axis kills the run early instead of burning all permutations.
   Expected: a genuinely broken bump finishes in minutes, not hours.
4. Put a hard cap on matrix jobs in the agent's config (for example max 24 jobs per upgrade) and require the agent to request approval to exceed it.
   Expected: future bumps cannot silently burn the budget; excess needs a human yes.
5. On the next bump, check the CI run list before the bill: count the jobs and confirm the budget dashboard moved a sane amount.
   Expected: a single candidate version costs a few dozen job-minutes, not a month.

## Use this when
- upgrade CI tests every combination of every version
- CI minutes spike overnight after a dependency bump
- the agent builds matrices without asking
- you support multiple versions of a framework, DB, and language at once

## Not for this skill when
- CI is expensive because tests are slow, not because the matrix is big (fix test time instead)
- you genuinely need full cross-product coverage for a support guarantee (then budget for it deliberately)
- the cost problem is GPU or runner size, not job count

## Variant phrasings
- "CI matrix explosion after dependency upgrade"
- "agent ran 200 CI jobs for one version bump"
- "django postgres python version matrix too big"
- "CI bill exploded overnight from bot PRs"
- "how to limit github actions matrix for upgrade tests"

## Why it happens
A full cross-product matrix is the lazy-correct choice: it proves every combination works. But compatibility is usually monotone - if the min and max supported versions work, the middle ones almost always do. Agents default to exhaustive because nobody told them the budget; the cost only shows up on the invoice a month later.

## Edge cases
- A mid-range version can genuinely break while min and max pass (dropped feature flags, removed shims); keep one mid-point in the matrix for high-risk deps.
- Database version matrices hit real limits on hosted CI (service containers per version); test DB versions against the app on a schedule, not per bump.
- fail-fast can hide secondary breakage; after the first green fix, run the full reduced set once.
- Budget caps set too low will silently skip real coverage; alert, do not just cap.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qSfykQsGTPMd_ib8Tzcuxw