What CI/CD Costs at Different Team Sizes

Published on September 28, 2026 by DevTools Stack Review Editorial Team

Build minutes, concurrency, storage, and self-hosted runners, what CI/CD actually costs as teams grow, and where the bill quietly escalates.

CI/CD pricing is one of the more deceptive cost categories in modern software infrastructure. The advertised per-minute rate is only the starting point. As teams grow, build volume compounds, concurrency ceilings appear, storage charges accumulate without anyone noticing, and the infrastructure required to run self-hosted runners carries its own ledger of compute and engineering time. This guide breaks down every significant cost driver in CI/CD pipelines, walks through realistic spend profiles at three team-size tiers, names the hidden multipliers that inflate bills beyond what anyone planned for, and closes with a practical optimisation checklist. All figures are ranges sourced from published vendor pricing as of mid-2026 and should be verified against current vendor documentation before budgeting, as rates change frequently.

---

What CI/CD Pricing Actually Measures

Continuous integration and continuous delivery pipelines execute code on remote compute every time a developer pushes a commit, opens a pull request, or merges a branch. The platforms that orchestrate that execution charge for the resources consumed: the compute time used, the number of jobs that can run simultaneously, the data stored between runs, and in some cases the number of seats on the platform. Understanding which of those dimensions your team is actually spending on is the prerequisite for managing the bill.

A build minute is the unit most CI/CD vendors use to bill compute, but the way each CI vendor counts, rounds, and surcharges differs, and those small rules compound into bills that surprise teams every quarter. Before modelling your own costs, it helps to understand each dimension individually.

---

The Core CI/CD Cost Drivers

Build Minutes and Per-Minute Rates by Runner Size

The per-minute rate for a Linux runner is the baseline price point across most hosted CI/CD platforms. Following GitHub's January 2026 repricing, Linux x86 sits at $0.006/min, Linux ARM at $0.005/min, Windows at $0.010/min, and macOS (3-4 core) at $0.062/min. Those figures are for GitHub Actions specifically. Across the broader market, 2026 baseline rates run roughly $0.006 to $0.062/min for GitHub Actions depending on OS, $0.010/min flat for GitLab CI, and $0.006/min for Linux on CircleCI with macOS exceeding $0.12/min on some machine classes.

The runner size multiplier matters as much as the OS multiplier. A 16-core runner costs 8x as much per minute but only finishes 3.5x faster, so the raw compute bill goes up, though developers stop waiting sooner. Larger machines are often selected by default without modelling whether the faster wall-clock time justifies the higher per-minute charge. It is common to default to the biggest runners available "just to be safe," but this leads to chronic underutilisation.

macOS is the category where rates become acutely painful. At $0.062/min, a 15-minute iOS build costs $0.93 per run; heavy iOS CI can cost thousands per month. GitHub Actions also applies included-minute multipliers where macOS consumes 10x the allowance quota, meaning a 3-minute macOS job depletes 30 of your monthly free-minute budget.

Note on pricing accuracy: Vendor rates change, sometimes substantially. GitHub cut hosted-runner rates by up to 39% on 1 January 2026. Linux dropped from $0.008 to $0.006/min (-25%), Windows from $0.016 to $0.010/min (-38%), and macOS from $0.080 to $0.062/min (-23%). All figures in this guide should be verified against current vendor documentation before any budget is committed.

Concurrency Limits and What It Costs to Raise Them

Free and entry-level plans cap the number of jobs that can run simultaneously. Free tiers typically allow one to three concurrent jobs. When you have 20 pull requests open, builds queue. Queued builds translate into developer waiting time, which is a productivity cost even when it does not show up on the vendor invoice.

Raising those concurrency limits carries a real price. Azure DevOps charges $40/month per additional parallel job, and this cost scales linearly, five parallel jobs means $200/month. The most expensive consequence of parallelism is the tier upgrade it forces. CircleCI's Free plan allows 30 concurrent jobs but offers no credit overage, so any team that outgrows the 30,000 monthly credits must upgrade to Performance regardless of whether concurrency itself was the bottleneck.

It is also worth understanding that parallelism does not reduce total billable minutes. Parallelism does not save minutes. A 60-minute job split into 10 parallel jobs of 6 minutes each consumes the same 60 minutes of billable compute. What it saves is wall-clock time, which is paid in developer-minutes-of-waiting, not vendor dollars. And rounding rules compound the cost further. Twenty parallel jobs of 35 seconds each bills as 20 minutes, not the 11.7 minutes the work actually consumed. Parallelism plus rounding inflates the bill.

Storage for Artifacts and Caches

Artifact and cache storage is the line item that accumulates silently. GitHub Actions artifact storage compounds quickly. The free tier covers 500 MB per repository; beyond that, storage costs $0.25 per GB per month. Test reports, coverage files, build outputs, and compiled binaries pile up under 90-day default retention. An active monorepo generating 50 MB of artifacts per build, 100 builds per day, accumulates 150 GB of artifact data per month. After the first 500 MB, that is $37.50 per month from a default that nobody changed.

Artifacts and packages beyond the included allowance cost $0.25/GB/month. Teams that cache large Docker images or store build artifacts for extended periods can see $50 to $200 per month in storage charges alone. Most CI/CD platforms charge premium rates for artifact storage. Pushing large artifacts to S3 or GCS instead is typically 10 to 100 times cheaper than CI/CD platform-included storage past the free tier.

Egress and Container Registry Pulls

Egress fees are the cost that almost no one budgets for at the outset. Egress is the line item nobody plans for. CI pipelines pull container images, download dependencies, push artifacts, and ship logs. Each byte that crosses an AWS NAT, an Availability Zone boundary, or a region edge is metered.

Container registry storage compounds on top of egress. If your CI builds container images, those images live in a container registry. The pricing math runs per-GB-month. ECR Standard is $0.10/GB-month. GitHub Container Registry is $0.25/GB-month for private images. The key cost driver is layer churn: container images pile up image manifests as each build produces a new tag.

Registry pricing is designed around consumption. CI/CD pipelines are designed around repetition. The combination is expensive by default. Accessing images outside the region of your registry incurs network egress costs, and data egress costs can surmount storage costs over time due to excessive image pulls.

Self-Hosted Runner Infrastructure and Engineering Time

Self-hosted runners are frequently described as "free" because the platform software charges no per-minute fee for jobs running on infrastructure you own. That framing omits two significant cost categories: the infrastructure itself, and the engineering time required to keep it running.

Self-hosted runners look attractive until you factor in idle time. An m5.xlarge instance costs $0.192 per hour on-demand, $132 per month running continuously. At 15% utilisation, which is common for teams without autoscaling, the effective per-minute cost is 6.7x the Linux hosted runner rate. Self-hosted runners become cost-effective at roughly 3,000 build minutes per month, but only when paired with autoscaling that terminates idle nodes. Below that threshold, or without autoscaling, hosted runners are cheaper and operationally simpler.

A 20-person team on self-hosted Jenkins typically pays $50-150/month in EC2 cost, $200-600/month in engineer maintenance time (2-4 hours/month at $100-150/hour), plus storage and egress charges and security patch overhead, for a total real cost of $800-2,500/month. The largest cost in any self-hosted deployment is human time. Industry estimates converge on 4 to 20 hours per month of operator time for a typical mid-size setup, covering plugin upgrades, security patches, troubleshooting failed builds, capacity tuning, certificate rotation, and agent registration.

Self-hosted is not free. Software cost is zero, infrastructure is small, but operator time is real and dominates total cost at small scale. A team that believes they have free CI on Drone or Jenkins is implicitly paying $300-1,200 monthly in operator time at fully loaded engineering rates.

Seat-Based Charges

Some platforms layer per-user seat fees on top of compute charges. Because most providers charge a per-minute rate multiplied for larger or non-Linux runners and layer a per-seat fee on top, the cheapest platform changes depending on whether your spend is driven by compute or by team size. GitLab Premium is $29/user/month; GitHub Team is $4/user/month, but with limited CI minutes. At a team of 50, the seat-fee differential between platforms can exceed the compute-minute differential, making seat cost the dominant variable in total spend.

---

CI/CD Cost Drivers: Reference Table

The following table summarises the major cost dimensions, what triggers each one, and the most effective way to reduce it. All figures are indicative ranges; verify current vendor pricing before building a budget.

---

Realistic Cost Profiles by Team Size

Solo Developers and Small Teams: Living on Free Tiers

A solo developer on a small project typically consumes 200-500 build minutes per month. A small team of five developers with moderate CI consumes 2,000-5,000 minutes per month. At that volume, most teams stay entirely within free-tier allocations, provided they run Linux and keep individual build times short.

For a solo developer or 2-3 person early-stage team on private repos, free tiers on major platforms cover typical usage. Two thousand monthly Linux minutes covers typical small-team usage. Most small teams of two to five engineers spend $0-$200/month on continuous deployment in 2026, with GitHub Actions free-tier minutes covering most runner needs.

The free-tier picture looks straightforward until a team adds preview deployments or matrix testing. Every pull request triggering a preview deployment means a full build run. A 5-person team with 10 active pull requests rebuilt three to five times per day burns 10,000+ build minutes per month, several times the GitHub Actions free-tier allowance. At that point the bill is no longer zero, but it is also not large: overage at $0.006/min on 8,000 additional minutes is roughly $48.

Storage is the more common budget surprise at this scale. A default artifact retention window and a test suite that uploads coverage reports on every run will quietly consume the 500 MB free tier and begin accruing charges. Teams at this stage should set a spending cap, verify retention window defaults, and ensure macOS runners are only triggered where the OS is genuinely necessary.

Approximate monthly spend, solo to 5 developers, private repos: $0-$100 for compute on Linux; potentially $0-$50 for artifact storage depending on retention configuration; effectively $0 if the team stays within free-tier limits with deliberate pipeline design.

Growing Teams of 10-30: Hitting Concurrency and Minute Ceilings

For a 20-developer team running 100-150 builds per day at an 8-minute average, expect $300-$1,500 per month on hosted CI/CD platforms. This is the team-size band where two cost pressure points arrive simultaneously: build volume exceeds free-tier minutes, and concurrent job limits begin causing queue delays that push teams to raise their concurrency tier.

A five-developer team running 30 daily builds at 6 minutes each consumes about 3,800 minutes per month, almost double the GitHub Actions free-tier allowance. Scaling that to 20 developers running more frequent builds quickly reaches 15,000-30,000 minutes per month. At $0.006/min with a 3,000-minute plan allowance, 27,000 overage minutes cost $162. Add seat fees for a 20-person GitHub Team plan ($80/month) and artifact storage, and the total reaches $300-$400/month before any macOS or Windows runners are introduced.

Concurrency becomes the more significant operational problem in this band. Parallelism is the single most misunderstood cost lever in CI. Engineers reach for it to make builds faster. Finance teams discover that "more parallel jobs" doubled the bill without obviously delivering 2x feedback loop speed. Teams in this range often hit the concurrent-job cap on their plan during busy merge periods, leading to queued builds and reactive tier upgrades.

This is also the range where build discipline, caching, path filtering, conditional jobs, has the highest marginal return. Audits of CI/CD costs across engineering teams consistently find that 40-60% of CI spend is pure waste: builds that could run in 4 minutes take 12 because nobody configured caching; test suites that could run in parallel instead execute sequentially, billing 3x more minutes; and workflows that trigger on every push to every branch, including typo-fix commits to documentation files.

Approximate monthly spend, 10-30 developers, Linux-only, private repos: $200-$800 for compute on a hosted platform with standard plan seat fees and moderate overage. Add $100-$200 for storage and egress if not actively managed. macOS or Windows runners can double or triple the compute component.

Larger Organisations: When Self-Hosted Runners Start to Pay for Themselves

For a 50-developer team running 200 builds per day at 10 minutes each, monthly costs range from $1,200 to $4,800 depending on platform and runner selection. The average 50-person development team spends $3,000-8,000 per month on CI/CD pipeline compute alone, not the platform subscription, just the compute minutes that run builds and tests.

At this scale, the economics of self-hosted infrastructure shift. A 50-developer team running roughly 40,000 build minutes per month pays $240/month for compute on GitHub-hosted Linux runners. On a single spot instance at $0.17/hour with 60% utilisation, the compute cost drops to approximately $90/month, a saving of around $150/month. At an annual saving of roughly $1,800, the labour cost of running a runner controller cluster slightly exceeds the compute saving at this volume. That math flips dramatically once monthly minutes pass 100,000, where the compute saving from self-hosting overwhelms the labour overhead.

Teams over 100 developers or exceeding 100,000 monthly build minutes often find that self-hosted runners on Kubernetes with dynamic agent provisioning justify their operational cost. At this scale, per-minute fees on SaaS platforms exceed the fixed costs of self-hosted infrastructure plus operator time.

Seat fees become a significant factor at this scale. The GitLab value proposition at this size is the all-in-one platform: SCM, CI, container registry, security scanning, and deployment in one subscription. If a team is paying for a separate SCM platform plus a separate CI platform, GitLab Premium at $29/user can be cheaper than the combined total. Modelling total cost of ownership, including seat fees across every tool in the pipeline, is more important than comparing per-minute rates in isolation.

Approximate monthly spend, 50-100 developers: $1,200-$8,000+ depending on platform, runner type, build volume, and OS mix. Self-hosted infrastructure with autoscaling can reduce compute costs materially at this scale, but engineering time to maintain it is a real offset that must be included in the comparison.

---

The Hidden Cost Multipliers

The cost drivers described above are visible on the invoice. The following factors inflate build volume quietly, making the invoice larger than anyone expected without any obvious single cause.

Slow Test Suites Running Without a Time Budget

Test suites accumulate over time without anyone actively managing their runtime. Individual tests get slower, new tests are added without pruning old ones, and the total suite duration drifts upward by minutes every quarter. Because the regression is gradual, no single commit looks expensive, but the compound effect on monthly build minutes is substantial.

A 30-second test hiding in a 6-minute suite is invisible until you look. These are often the easiest wins, and a hard time budget prevents regression. Instrumentation, parsing JUnit XML, tracking the slowest tests per service, and enforcing a time budget in CI, surfaces the problem and creates accountability. Teams that do this work routinely find tests making unnecessary network calls, creating excessive test data, or duplicating coverage that a faster unit test already provides.

Unnecessary Full Rebuilds

For languages like Go, Rust, and Java, intermediate build files can be reused between job runs. Recompiling the same code every time wastes compute and developer time, so setting up intermediate artifact caching allows for faster rebuilds, especially in monorepos or large projects with multiple build stages.

Dependency installation is an equally common source of waste. When cache keys are misconfigured or absent, every job downloads and installs the same dependency tree from scratch. Docker layer caching reduces per-build image sizes when base layers do not change. A cache miss on a base layer forces a full rebuild, adding 4-6 minutes of runner compute and a new full-image push to the registry.

Running Full Suites on Every Commit Across a Matrix

A full test suite is appropriate, until it is run on every commit. A more sustainable approach runs smoke tests on every commit, full suites on merge or deploy events, splits tests to parallelise across runners, and skips unchanged modules using intelligent test orchestration. This avoids overloading infrastructure and reduces cost per test run.

Matrix builds compound the problem. A workflow that tests across three Node.js versions, two operating systems, and two database versions produces twelve concurrent jobs for every single commit. Most of that coverage is redundant for the majority of pull requests. Restricting the full matrix to the main branch and merge queue, while running a representative single-axis build on pull request commits, dramatically reduces monthly minutes without meaningfully reducing defect coverage.

Monorepo Builds That Do Not Scope to Changed Packages

The problem in monorepo CI is the 95% of pull requests that do not touch a shared base. Most changes touch a narrow slice of the dependency graph: one consumer's internal helper, a single service's route handler, a leaf-package test. The CI cost of those pull requests should be small. In practice, most teams run the full suite anyway, because nobody is computing what the change actually affected.

Path-based filtering tells your CI to skip jobs when only certain files change. A backend-only pull request can skip slow end-to-end tests. A documentation typo fix can skip the entire pipeline. This filtering is worth a few hours of configuration work because it can cut billable minutes by 20-40% on a busy monorepo. Both GitHub Actions and GitLab CI support it natively.

For monorepos with a dependency graph, tools that compute the affected package set per commit allow the pipeline to run only the builds and tests that are actually relevant to a given change. Without a precomputed dependency graph, the build system has two options: rebuild everything, or rebuild based on a hand-maintained list that is always out of date. Most teams pick the first option and pay for it on every pull request. The teams who have fixed this compute the impact set per change.

---

Best Practices and Expert Tips for Controlling CI/CD Costs

The following practices are supported by engineering teams across a range of organisation sizes and consistently reduce CI/CD spend without degrading developer experience.

Set a Spending Cap Before You Need One: Every platform supports a spending cap. A single misconfigured workflow that triggers on every push of every branch can rack up four-figure bills overnight. Spending limits will not stop bad workflows, but they will stop the invoice. GitHub Actions, GitLab CI, and CircleCI all support hard caps at the organisation level.

Audit Your Slowest Build Phase First: Find the concurrent-job cap and the price of lifting it. The minute rate is rarely the binding constraint at scale; the concurrency cap is. Before optimising the per-minute rate, determine whether the real bottleneck is compute minutes, concurrency limits, or pipeline design, and address the most expensive one first.

Right-Size Runners Before Choosing Self-Hosted: The instinct to move to self-hosted infrastructure is often triggered by a high bill that could be addressed by right-sizing the hosted runner class. It is common to default to the biggest runners available "just to be safe," but this leads to chronic underutilisation. Benchmarking the same job across two runner sizes before committing to a larger machine class frequently reveals that the performance gain does not justify the cost increase.

Configure Dependency and Layer Caching on Every Job: Caching is the highest-return optimisation available to most teams. Correct cache keys on dependency installs and Docker base layers eliminate the most common source of unnecessary compute time. A properly cached dependency install step typically takes seconds instead of minutes.

Scope Monorepo Jobs to Affected Packages: Tools like Nx, Turborepo, or Bazel detect which projects are impacted by a commit, enabling the pipeline to run targeted tasks rather than rebuilding the entire repository on every change. This is the single most impactful optimisation available to teams operating a monorepo.

Apply Short Artifact Retention Windows: Artifact storage charges accumulate under default retention settings without anyone noticing. Reducing retention from 90 days to 7-14 days for non-release artifacts eliminates the majority of storage cost with no operational impact on most teams.

Co-Locate Runners and Registries: Cross-region downloads add a separate egress charge on inter-region transfers. Pinning CI artifacts to one region and pulling from runners in the same region eliminates this charge wherever the workflow allows.

Model Self-Hosted Break-Even Honestly: Below 25,000 monthly build minutes, self-hosting does not pay back. The middle band, roughly 25,000 to 100,000 minutes, is where the answer depends on a team's appetite for owning runner infrastructure. Above 100,000 minutes, the compute saving generally exceeds the engineering time cost, making self-hosted infrastructure financially rational.

Use Trigger Conditions to Skip Irrelevant Pipelines: Full pipeline runs triggered on every commit to every branch, including branches that will never be merged, consume minutes for no meaningful quality signal. Restricting triggers to pull requests, merge queues, and protected branches, while running lightweight lint-and-build-only jobs on other branches, reduces monthly volume without reducing actual coverage.

---

The True Cost of CI/CD: Beyond the Invoice

The vendor invoice captures compute minutes, storage, and seat fees. It does not capture the developer time lost to slow pipelines, the productivity tax of build queues during busy merge periods, or the engineering hours spent maintaining self-hosted infrastructure. A CI/CD cost analysis that accounts for only the invoice will consistently underestimate the real investment and make optimisation decisions based on incomplete data.

The average 50-person engineering team spends $3,000 to $8,000 per month on CI/CD compute alone. That figure excludes platform subscriptions, storage, and engineering time spent maintaining pipelines. When those are factored in, the real number can double.

The most durable CI/CD cost management practice is treating pipeline efficiency the same way teams treat production infrastructure efficiency: with instrumentation, attribution, regular review, and ownership. Teams that instrument build times, set time budgets per suite, track concurrency utilisation, and review storage consumption monthly will consistently spend less on CI/CD than teams that address cost only after a surprising invoice arrives.

---

CI/CD Cost Optimisation Checklist

Use this checklist as a starting point before each billing cycle or after any significant team growth:

• Set an org-level spending cap on your CI/CD platform to prevent runaway costs from misconfigured workflows
• Audit the five slowest build jobs and determine whether the runtime is driven by missing caches, unnecessary steps, or genuinely slow tests
• Configure dependency caching on every job that installs packages, with cache keys keyed to the lockfile hash
• Configure Docker layer caching on every job that builds a container image
• Add path-based filters to skip large job groups when only unrelated files change (documentation, configuration unrelated to the failing scope, etc.)
• Restrict full matrix builds to the main branch and merge queue; run a representative single-axis build on pull request commits
• Scope monorepo jobs using an affected-package tool (Nx, Turborepo, Bazel, or equivalent) rather than building the full repository on every commit
• Review artifact retention windows and reduce default retention for non-release artifacts to 7-14 days
• Check runner sizing on your top five jobs by monthly spend; verify that a smaller runner class does not complete the job within acceptable time
• Co-locate runners and registries in the same region to eliminate cross-region egress charges
• Model self-hosted break-even using current hosted rates; include engineering time at a fully loaded rate, not just infrastructure cost
• Audit inactive seats on paid plans and remove contributors who are no longer active
• Review trigger conditions and restrict pipelines from firing on commits to branches that are not part of the review or merge process
• Verify current vendor pricing before finalising any budget; hosted-runner rates changed significantly in January 2026 and can change again

---

FAQs About CI/CD Costs at Different Team Sizes

What does CI/CD cost for a solo developer or very small team?

Most small teams of two to five engineers spend $0-$200/month on continuous deployment, with GitHub Actions free-tier minutes covering most runner needs. For private repositories on Linux runners, the free-tier allowance on major platforms is sufficient for typical early-stage usage. The bill rises materially when macOS runners, preview environments per pull request, or matrix builds across multiple OS versions are introduced. Artifact storage overages under default retention settings are the most common unexpected cost at this scale.

When does a team start spending meaningfully on CI/CD?

A five-developer team running 30 daily builds at 6 minutes each consumes about 3,800 minutes per month, almost double the GitHub Actions free-tier allowance. A two-to-three person early-stage team running CI on pull request pushes only consumes 1,000-1,800 minutes typically. Spend becomes material when a team consistently exceeds the free-tier minute allowance, adds per-user seat fees on paid plans, or introduces macOS or Windows runners. At that inflection point, monthly CI/CD spend typically reaches $100-$500 before any significant pipeline optimisation has taken place.

What are the biggest hidden costs in CI/CD pipelines?

The most consistently overlooked CI/CD costs are artifact storage accumulation under default retention windows, egress charges from pulling container images across region boundaries, self-hosted runner idle compute from instances running at low utilisation without autoscaling, and the engineering time required to maintain self-hosted infrastructure. Beyond the per-minute rate, cost categories that catch teams off guard include artifact storage overages, macOS runner costs, concurrent job limits forcing tier upgrades, data egress from pulling large Docker images, and SSO or enterprise security features requiring expensive tier upgrades.

At what scale do self-hosted runners make financial sense?

The math for self-hosted runners flips in favour of self-hosting once monthly minutes pass roughly 100,000, where the compute saving overwhelms the labour overhead. Below 25,000 minutes it does not pay back. The middle band between those thresholds requires an honest model that includes engineering time at a fully loaded rate, not just infrastructure cost. For most teams spending over $1,000/month on CI/CD compute, the economics work out in favour of self-hosting, but only with proper autoscaling and infrastructure discipline.

How much does a slow test suite cost in real dollars?

A test suite that runs in 12 minutes when it could run in 4 minutes with proper caching triples the compute cost of every run. Audits consistently find that 40-60% of CI spend is pure waste, with builds taking three times as long as necessary because nobody configured caching. For a team running 200 builds per day at an inflated 12-minute runtime versus an optimised 4-minute runtime, the difference is approximately 1,600 build minutes per day, or roughly $9.60/day at $0.006/min, adding up to nearly $3,000/year for a single optimisation that requires only pipeline configuration work.

Why do macOS CI builds cost so much more than Linux builds?

macOS costs roughly 10x more than Linux on GitHub Actions ($0.062 vs $0.006/min). Windows costs approximately 1.67x. This is both a per-minute rate difference and a free-tier quota difference: macOS minutes consume the free-tier allowance at 10x the rate of Linux minutes. Teams that run integration tests or cross-platform checks on macOS runners when a Linux runner would produce identical results are paying a significant premium. The macOS rate is only justified for workloads that genuinely require the Apple platform, iOS builds, macOS app compilation, or tests verifying macOS-specific behaviour.

How often do CI/CD vendor prices change?

CI/CD pricing changes with enough frequency that any figures cited in editorial content can be outdated within months. GitHub reduced hosted-runner rates by up to 39% in January 2026. Free tiers change; CircleCI revised free-tier credit allowances multiple times between 2023 and 2025; GitLab tightened OSS programme eligibility in 2024. Any budget built on specific per-minute rates or included-minute allowances should be validated against current vendor documentation at the time of planning, not taken from guides written months earlier.