What Happens When My Free Credits Run Out?

Signup includes $10 free credits, and once they are spent the account keeps running with usage billed per minute at the published rate for each runner label. There is no plan to pick and no subscription sitting underneath the balance, so the only change is that minutes start landing on an invoice instead of drawing down credit.

Answer

The credit balance is a prepaid amount against the same rates that apply after it empties. Pricing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee, which means the rate for a job on day one and the rate for the same job after the credits are gone are identical. Rates below come from the cloud runners documentation and the pricing page, checked on 2026-08-13.

How far $10 goes depends entirely on which label the jobs run on. The per-minute rate scales with vCPU count, so the label choice sets the drawdown speed.

The arithmetic is one division per row. Ten dollars divided by $0.004 per minute is 2,500 minutes on the entry Linux x64 label. The same ten dollars divided by $0.08 per minute is 125 minutes on a 6 vCPU macOS runner. One macOS minute draws the balance down as fast as twenty entry Linux x64 minutes, which is why an iOS pilot reaches paid usage on far fewer runs than a Linux pilot.

The entry Linux label is also where the list-price gap is easiest to check: warp-ubuntu-latest-x64-2x costs $0.004 per minute against $0.006 per minute for GitHub-hosted ubuntu-latest at the same 2 vCPU, 8 GB shape on private repositories, which is 33 percent lower list price (GitHub Actions per-minute rates, checked on 2026-08-13). GitHub gives public repositories a 4 vCPU, 16 GB Linux shape at no charge, so that comparison applies to private repositories.

Detail

How far $10 goes on a pilot workflow

A typical first workflow after the quick start runs three jobs on every pull request. Assume lint takes 2 minutes on the 2 vCPU Linux x64 label, unit tests take 6 minutes on the 4 vCPU label, and an ARM64 image build takes 5 minutes.

At $0.086 per pull request run, $10 in credits covers 116 full runs before the balance reaches zero. A repository that opens 30 pull requests a week crosses that point in about four weeks. Adding a 12 minute macOS job at $0.08 per minute takes the same run to $1.046 and cuts the credits to 9 runs, so a pilot that includes iOS should expect to reach paid usage inside the first week.

Watching the balance draw down

Estimating the burn rate matters less than measuring it. The reports documentation describes a Billing section with CI, Docker Builder, and Cache tabs. The CI tab shows a daily stacked cost chart that can be grouped by repository or by runner label, summary cards for total cost, runner cost, snapshot cost, and job count, and a table with one row per job execution carrying repository, job name, runner label, stack, execution time, billed time, and the runner and snapshot cost split. Every tab supports date range selection, filtering, and CSV export.

Grouping the daily chart by runner label is the fastest way to see what is consuming the balance, since one macOS minute at $0.08 costs as much as twenty 2 vCPU Linux x64 minutes at $0.004. The Jobs section adds duration, queue time, CPU, and memory percentiles per job, which finds the jobs paying for vCPU they never use before the credits are gone.

What the first paid invoice looks like

Nothing about the account changes when the balance empties. Jobs keep queuing on the same labels at the same rates, and the credits show up as a reduction on the invoice rather than as a plan boundary.

Take the pilot workflow above at 400 runs in the first month. Runner cost is 400 multiplied by $0.086, or $34.40. The $10 in signup credits comes off that total, leaving $24.40 on the first invoice. Cache storage at $0.20 per GB-month, cache operations at $0.0001 each, and snapshot restores at $0.04 per job are added alongside the runner line when those features are in use, per the pricing page.

Billing runs on the last day of each month by default. Each account also carries a usage threshold based on its history, and crossing that threshold can trigger a charge to the payment method on file mid-cycle. Once real usage is visible, the bill estimation walkthrough turns one month of report data into a model, and the minutes budget guide turns that model into a rolling forecast.

The one case where credits do not apply

Accounts that subscribe through AWS Marketplace are the exception. The AWS Marketplace billing documentation states that AWS Marketplace billing does not support free credits, and that organization usage is billed daily at 12:15 AM UTC for the previous day. Because of that daily cadence, the totals shown in AWS Marketplace can lag the numbers on the WarpBuild billing dashboard. Teams that want the $10 starting balance should sign up directly and connect a payment method there instead.

Related Questions

How many GitHub Actions minutes do $10 in free credits cover?

At $0.004 per minute on warp-ubuntu-latest-x64-2x, $10 covers 2,500 minutes. On the 2 vCPU Linux ARM64 label at $0.003 per minute it covers about 3,333 minutes, and on a 6 vCPU macOS runner at $0.08 per minute it covers 125 minutes. Every rate is listed on the pricing page.

Do I have to pick a plan when my free credits run out?

No. Pricing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee, so the account keeps running at the same per-minute rates once the balance reaches zero. The minutes budget guide covers how to forecast the monthly total that follows.

Where do I see how fast my credits are being spent?

The Billing section of the reports view breaks cost down per job, per repository, and per runner label, with execution time, billed time, and the runner and snapshot split on every row. Group the daily chart by runner label to find the expensive corner, and export any tab to CSV to model it. The bill estimation walkthrough shows the arithmetic that turns those rows into a monthly number.