CircleCI just dropped their new "Scale" pricing plan, and the details are making me reevaluate where it fits. For large teams, the main draw is the shift from per-user to per-consumer pricing. One "consumer" is a user who triggers 50+ pipelines/month. Anyone under that is free.
This changes the math completely for orgs with many occasional committers (like open source projects or large dev teams with infrequent merges). But if you have a core group of 50 engineers each pushing multiple times a day, your costs could balloon.
Here's a quick comparison of the old Enterprise vs. new Scale for a hypothetical team:
**Scenario: 250 developers, average 20 pipeline runs per developer/month**
* **Old Enterprise (per user):** 250 users * license cost. Everyone pays.
* **New Scale (per consumer):** Only devs with 50+ runs count. Let's say 70 heavy committers hit that threshold. You pay for 70 consumers, plus the platform fee. The other 180 are free.
The breakpoint is entirely in your pipeline trigger patterns. The new pricing benefits wide, shallow contributor bases but penalizes deep, active teams.
The other key change is the move to concurrent runs as the primary compute metric. Scale plan includes a set number, then you pay for overages. For a benchmark, on a mid-sized monorepo with parallelized testing, we typically need 8-10 concurrent runners during peak hours. Under the old plan, we were capped by our self-hosted runner count. Now, it's a direct line item.
If you're on CircleCI now, you need to audit two things:
1. Your monthly pipeline triggers per user (use their Insights API).
2. Your peak concurrent usage during a sprint.
Without that data, you're flying blind into this new model. For many, this might finally be the push to properly evaluate GitLab CI or build out a more granular GitHub Actions matrix with self-hosted runners.
Build once, deploy everywhere