CircleCI Performance plan cost: how do I forecast monthly credits for ~25 engineers and our current pipeline volume?
CI/CD Platforms

CircleCI Performance plan cost: how do I forecast monthly credits for ~25 engineers and our current pipeline volume?

10 min read

Most teams evaluating the CircleCI Performance plan get stuck on the same question: how many credits do we actually need per month, and what will that cost with ~25 active engineers and our current pipeline volume? You don’t want surprise overages, but you also don’t want to overbuy and sit on idle credits.

Quick Answer: You forecast CircleCI Performance plan cost by estimating how many pipelines your ~25 engineers will trigger each month, multiplying by the average credits per pipeline (based on resource class and runtime), and then mapping that to a credit bundle. CircleCI’s credit model lets you buy what you need up front (with volume discounts) and roll paid credits over for up to a year, so you can iterate on your estimate as your delivery volume grows.

The Quick Overview

  • What It Is: The CircleCI Performance plan is a credit-based CI/CD plan where you pay for compute (credits) instead of fixed “minutes,” with flexible resource classes, concurrency, and parallelism.
  • Who It Is For: Engineering teams that have outgrown the Free plan—typically 10–100+ engineers—who run frequent builds and want predictable cost, faster pipelines, and enterprise-style controls without managing their own CI estate.
  • Core Problem Solved: It gives you a scalable way to run more pipelines and heavier workloads (Docker, mobile, AI/ML, GPU, etc.) while keeping cost under control through a single credit model you can forecast and tune.

How It Works

CircleCI runs on credits. Every pipeline job consumes credits according to the resource class it runs on (for example, a “Linux Medium” machine) and how long it runs. Your monthly bill is essentially:

Monthly credits used ≈ number of pipelines × jobs per pipeline × credits per job‑minute × average job runtime

With a team of ~25 engineers, the main levers are pipeline frequency and how aggressively you parallelize tests. You’ll use more credits as you run more pipelines or larger machines, but you’ll also finish builds faster and keep engineers unblocked.

Here’s the flow at a high level:

  1. Estimate usage:
    Quantify how many builds per engineer per day you expect, the average runtime per pipeline, and which resource classes you’ll use most (for example, Linux Medium vs larger machines).

  2. Translate to credits:
    Use CircleCI’s credit/minute rates (for example, 10 credits/min for Linux Medium, per the docs example) and your runtime assumptions to compute a monthly credit range. Remember: more powerful classes cost more per minute but can reduce total minutes.

  3. Pick a plan and refine:
    Choose a Performance plan credit tier that comfortably fits your forecast, then monitor real usage in the CircleCI app. Because paid credits roll over for up to a year, you can start with a healthy buffer, watch actual consumption, and adjust purchases.

Forecasting Credits for ~25 Engineers

Let’s walk through a realistic, directional forecast so you can plug in your own numbers.

1. Estimate monthly pipelines

For 25 engineers on an active product:

  • Each engineer pushes code that triggers CI ~5 times per day (feature work, re-runs, etc.).
  • Work ~20 days/month.

That’s:

  • 25 engineers × 5 pipelines/day = 125 pipelines/day
  • 125 pipelines/day × 20 days = 2,500 pipelines/month

If your team is more conservative (3 pipelines/day per engineer), you’re closer to 1,500/month. If you’re practicing trunk-based development and feature flags, 5–8 per engineer per day is common.

2. Estimate jobs and runtime per pipeline

Assume a typical workflow has:

  • 1 build job
  • 1–3 test jobs (parallelized by service or platform)
  • 1 deploy job (not on every pipeline, but we’ll smooth it out)

We’ll simplify to an average of 3 jobs per pipeline, each running on Linux Medium:

  • Typical job runtime after some optimization: 8–10 minutes
  • So, roughly 25–30 minutes of job time per pipeline (3 jobs × 8–10 minutes).

For 2,500 pipelines/month:

  • 2,500 pipelines × 3 jobs = 7,500 jobs
  • 7,500 jobs × 8–10 min ≈ 60,000–75,000 job‑minutes/month

3. Convert minutes to credits

CircleCI’s docs give the example:

30,000 credits at a rate of 10 credits per min (using Linux Medium) is 3,000 minutes.

So for a Linux Medium resource class:

  • 10 credits/minute/job

Now apply that to your estimate:

  • Lower bound: 60,000 minutes × 10 credits/min = 600,000 credits/month
  • Upper bound: 75,000 minutes × 10 credits/min = 750,000 credits/month

This is a directional range for 2,500 pipelines/month on Linux Medium. If you use larger machines for heavy workloads, multiply those minutes by the higher credits/min rate for those classes.

4. Adjust for real-world behavior

Your team won’t be perfectly uniform. Variables to consider:

  • Deploy frequency: If only main-branch pipelines run deploy jobs, your average jobs/pipeline might be closer to 2.5, reducing credits.
  • Parallelization: If you split test suites into more parallel jobs, each job runs fewer minutes, but total credits may be slightly higher. The tradeoff is faster feedback for engineers.
  • Smarter Testing / selective execution: As you adopt test selection and only run impacted tests, your average job runtime drops, lowering credits per pipeline.
  • Nightly / scheduled workflows: Add a small budget for nightly/regression pipelines, which may be heavier than each feature pipeline.

In practice, I recommend:

  1. Use the rough range (for example, 600k–750k credits/month) as your baseline.
  2. Add 20–30% buffer for growth and variability, landing in the 720k–975k credits/month range.
  3. Choose the next highest annual credit bundle that covers that comfortably, especially if you can take advantage of prepaid discounts.

Features & Benefits Breakdown

Core FeatureWhat It DoesPrimary Benefit
Credit-based Performance planLets you buy a pool of credits and spend them on pipelines, seats, and resources.Aligns CI/CD cost with actual usage, so 25 engineers can scale pipelines without fixed seat/minute constraints.
Flexible resource classes & scaleLets you choose machine sizes, use Docker Layer Caching, and run jobs in parallel.Shortens pipeline time while using credits efficiently—do more in a minute on CircleCI than on basic CI.
Rollover & bulk discountsPaid credits roll over for up to a year; large pre-purchases get discounts.Makes forecasting safer: overestimate slightly, avoid surprise overages, and gain savings at scale.

Ideal Use Cases

  • Best for teams graduating from Free: Because the Performance plan keeps the same developer experience but gives you more credits, higher concurrency, and the ability to support ~25 engineers without hitting the Free plan’s ceilings (30k credits, 5 active users/month).
  • Best for teams standardizing CI across repos: Because you can centralize credits for the whole org, enforce common workflows, and monitor usage across all pipelines—ideal when you’re rolling out golden paths and need predictable cost.

Limitations & Considerations

  • Credit estimates are approximate: The 10 credits/minute example is for Linux Medium; other resource classes have different rates. Always validate your estimate against actual usage in the CircleCI UI after a few weeks.
  • Free vs paid credit behavior: The Free plan’s 30,000 credits expire monthly and don’t roll over, while paid Performance credits roll over month-to-month and expire after a year. Don’t assume Free-plan behavior for your paid pool.

Pricing & Plans

CircleCI’s pricing is designed so you:

  • Buy credits in advance for additional savings.
  • Spend credits on resource classes, seats, and features as needed.
  • Automatically refill credits so your team doesn’t get blocked when usage spikes.

From the public docs:

  • The Free plan includes up to 30,000 credits and 5 active users per month. Those free credits expire each month and do not roll over.
  • On the Performance plan, you can purchase additional credits at $15 for every 25,000 credits. Paid credits roll over month to month and expire after a year. Unused credits are forfeited if you cancel the subscription.
  • If you buy very large volumes in advance, you can get prepaid discounts:
    • 5–10M credits → 2% savings
    • 10–41.7M credits → 3% savings
    • 41.7–83.4M credits → 4% savings
    • 83.4M+ credits → 5% savings

For a ~25‑engineer team using our example range (say ~900k credits/month with buffer), your annual planning might look like:

  • 900,000 credits/month × 12 ≈ 10.8M credits/year
  • That lands you in the 10–41.7M credit band, which qualifies for a 3% prepaid discount if you buy the whole year’s credits up front.

Plan fit guidance:

  • Performance (credits-based): Best for teams like yours (25 engineers) who want to grow organically, tune pipelines, and take advantage of discounts as usage stabilizes.
  • Custom/Enterprise tiers: Best if you’re planning to expand to hundreds of engineers, need the largest resource classes, GPUs, and enterprise controls, or want a bespoke contract with committed spend.

Frequently Asked Questions

How do I adapt my forecast if our pipeline volume grows over the year?

Short Answer: Start with a conservative annual credit bundle that covers your current volume plus 20–30% growth, then monitor monthly usage and adjust with additional credit purchases if needed.

Details:
In reality, your 25‑engineer team might become 30–40 engineers mid-year, or your microservice count might double. Because paid credits roll over month-to-month and expire after a year, it’s safe to:

  1. Use the process above (pipelines/month → job-minutes → credits) based on today.
  2. Multiply your initial estimate by 1.2–1.3 to cover growth.
  3. Buy that as an annual bundle to capture prepaid discounts.
  4. Track monthly consumption in the CircleCI billing dashboard.

If you see sustained usage above forecast, purchase additional credits in blocks (for example, another 500k credits) and fold that into your budget. Since over-purchasing a bit is safer than under-purchasing (credits last up to a year), I bias slightly high once teams are shipping at AI speed.

How can I lower our credits per pipeline without slowing developers down?

Short Answer: Reduce minutes per job with smarter test execution, right-size resource classes, and standardize fast, reusable workflows.

Details:
Your credits are minutes × rate. To reduce credits per pipeline while keeping confidence high:

  • Shorten test time:

    • Use parallelism to cut wall-clock time.
    • Adopt selective test execution so you don’t run the full suite on every commit.
    • Fix flaky tests so you avoid unnecessary re-runs.
  • Right-size machines:

    • Start with Linux Medium as a baseline.
    • Use larger machines only where they actually reduce total runtime (for example, heavy builds).
    • Periodically review which jobs really need bigger resource classes.
  • Standardize workflows:

    • Create golden-path configurations for build/test/deploy across repos.
    • Strip out redundant jobs and ensure you’re not running the same heavy tasks multiple times per pipeline.

As you optimize, you’ll often see both faster feedback for engineers and fewer total minutes per pipeline, which means fewer credits consumed for the same or higher level of validation.

Summary

Forecasting CircleCI Performance plan cost for ~25 engineers comes down to three steps: estimate your monthly pipeline volume, multiply by the job-minutes per pipeline, and apply the credit-per-minute rate for your primary resource classes. For many teams at this size, that lands in the mid-hundreds-of-thousands of credits per month, which you can cover with an annual credit bundle that rolls over and benefits from prepaid discounts.

Because credits on the Performance plan roll over for up to a year, the safest move is to start with a slightly generous estimate, watch actual consumption for a couple of months, and then recalibrate. That way your team can ship at AI speed without worrying about hitting a hard CI ceiling or constantly renegotiating budget.

Next Step

Get Started