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.
Reviewing results, browsing the workspace, and ordinary feature edits do not consume credits. AI-assisted work, exploration, generation and its verification sessions, test runs, and load runs can consume credits. Storage has a separate plan quota.
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
Common chargeable activities include the following. Scans, triage or optional AI plugins can add model work; generation can include both tokens and compute:
| Activity | What's metered |
|---|---|
| Test generation | AI tokens while drafting and repairing tests, plus sandbox time for exploration and verification. |
| 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 monthly at the configured cycle boundary and does not carry over. 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 | 1,500 (one-time grant, does not reset) |
| Personal | $29 | 2,500 / month |
| Team | $199 | 16,000 / month |
| Business | $699 | 56,000 / month |
| Enterprise | Contact sales | Negotiated allowance |
Annual billing is 10% cheaper than paying monthly, while included credits still renew monthly. The reset boundary can be calendar-month or billing-anniversary based on installation settings. Credit packs come in 5,000, 15,000, and 50,000 sizes; each grants the listed credits. Compare the current pack prices in Billing rather than assuming the largest has the lowest price per credit. 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. The by-area split can help locate 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 hosted paid plans, a zero spendable balance also blocks new chargeable work. Add a credit pack or change your plan before starting another generation or run; a paid plan does not promise unlimited overage.
A purchased pack can provide a buffer on a hosted paid plan: packs do not expire, and monthly credits are spent first. Owners can buy them from the Credit card in Settings > Billing. Check Credit Usage to decide whether a pack or a plan change fits the workload.
Check Billing for the available balance and Credit Usage for the work that consumed it. Storage is managed separately. See the pricing docs for metering details, or get early access to try TestVibe on your app.