TestVibe meters everything through a single unit: credits. The same balance covers the AI tokens spent generating tests and the cloud session time spent running them, so you don't juggle separate meters for "AI" and "compute." This guide explains exactly what draws down credits, how the two kinds of credits are applied, where to watch usage, and how a workspace behaves when the balance hits zero.
One balance, two kinds of work
A credit is the accounting unit for two very different costs. When AI drafts a feature or generates Playwright code, it consumes credits based on the AI tokens it uses. When your tests execute in an isolated cloud session, they consume credits based on how long that session runs. Both draw from the same workspace balance.
Everything else is free. Reviewing run results, reading traces and screenshots, editing a feature's steps, and browsing around the workspace do not cost credits. You only pay when the system does real work on your behalf — generating or running.
Credits belong to the workspace, not to you personally. If you're a member of more than one workspace, each carries its own plan, its own balance, and its own bill.
What actually consumes credits
Four kinds of activity draw down the balance. Two are AI (billed on tokens), two are compute (billed on session time):
| Activity | What's metered |
|---|---|
| Test generation | AI tokens used while drafting features, generating Playwright code, and repairing tests. |
| Test runs | Cloud session time while your tests execute and evidence is collected. |
| Load testing | Cloud session time for load-test sessions. |
| Assistant | AI tokens used by the in-app assistant when it works on your behalf. |
The practical takeaway: generation cost scales with how much the AI has to reason and write, and run cost scales with how long your suite takes to execute in the cloud. Because runs are billed by session time, the biggest lever you control is not spending it idle. Web-first assertions wait exactly as long as needed instead of parking the session on a fixed sleep:
// Waits only until the condition holds, up to the timeout
await expect(page.getByRole('alert')).toContainText('Saved');
// Avoid: burns session time and flakes under load
await page.waitForTimeout(3000);A tight, well-scoped test that finishes fast costs less to run than one that waits around on slow pages or retries. This is one more reason to keep tests focused — TestVibe verifies every generated test by actually running it, so a lean suite is cheaper on both sides of the meter.
Monthly credits vs purchased credits
There are two pools, and the order they're spent in matters.
Included plan credits come with your plan. On a paid plan this is a monthly allowance: it resets at the start of each billing month and does not carry over — use it or lose it. The Free plan is different: it gets a one-time credit grant that does not reset.
Purchased credit packs are top-ups you buy on a paid plan. They're persistent — they never expire and they don't reset with the billing period.
When a workspace spends credits, TestVibe always draws from the monthly allowance first, then from purchased packs. That ordering protects your top-ups: your renewing monthly credits get consumed before the balance you paid extra for, so a pack you bought in a busy month is still there next month.
Public plan allowances look like this:
| Plan | Monthly price | Included credits |
|---|---|---|
| Free | $0 | 5,000 (one-time grant, does not reset) |
| Starter | $58 | 5,000 / month |
| Pro | $289 | 19,000 / month |
| Enterprise | $2,099 | 145,000 / month |
Annual billing is 10% cheaper than paying monthly, and the full year's credits are granted up front. Credit packs come in 5,000, 15,000, and 50,000 sizes; a pack grants exactly the credits it lists with no bonus, and the larger packs carry a better per-credit price. Settings > Billing is always the source of truth if a number here ever looks out of date.
Checking where your credits go
Two panels answer two different questions.
Settings > Billing answers "how much do I have?" It leads with available credits, split into the two pools — included (monthly) and purchased — so you can see your renewing allowance and your persistent top-up balance side by side. It's also where owners change plans and buy packs. Non-owners see the panel read-only.
Settings > Credit Usage answers "where did it go?" It totals what the workspace spent this cycle and breaks it down by area — test generation, test runs, load testing, and assistant — with each area split into compute (session time) and AI (tokens). A chronological list shows individual entries with a readable reason, so you can trace a spike back to the specific generation or run that caused it.
If a bill surprises you, start with Credit Usage. Nine times out of ten the by-area split points straight at the cause: a big generation batch, a load test, or a suite that's been running longer than it should.
Running out without surprises
Zero doesn't mean the same thing on every plan. On the Free plan, the included credits are a one-time grant that doesn't reset, so once the balance reaches zero, generation and runs won't start again until you move to a paid plan. On Pro and Enterprise plans, usage past the balance is tracked as overage and billed at the end of the period, so ongoing work keeps flowing.
The clean way to avoid a mid-cycle scramble on a paid plan is a purchased pack: because packs never expire and sit behind your monthly allowance, they act as a buffer that absorbs a heavy month without tripping overage charges. Owners buy them from the Credit card in Settings > Billing.
Credits keep TestVibe honest — you pay for generation and cloud runs, and nothing else. To dig into the specifics, see the pricing docs, and if you'd like to try it on your own app, get early access.