Back to Blog

The Real Cost of LLM-Driven Test Runs: A Token Math Breakdown

The Real Cost of LLM-Driven Test Runs: A Token Math Breakdown

The real cost of LLM-driven test runs is not the model. It is the meter. Your AI bill is about to become your testing bill, and you will notice it the first time a finance partner forwards you an API invoice with a subject line that just says "what is this".

Over the last 18 months the industry quietly slid from one bad pricing model to a worse one. Percy and Applitools charged per screenshot, which was annoying but at least deterministic. The new wave of LLM-driven test runners charges per token, per run, per commit. Nobody has done the token math out loud.

So let's do it, then show the one structural fix that takes the recurring cost to zero.

The new testing cost model

In the old world, your testing line item was a fixed SaaS seat plus a variable per-screenshot fee. You could forecast it. You could cap it. You could stare at a dashboard and know, roughly, what a 30% increase in test coverage would cost you next quarter.

In the new world, an LLM agent drives the browser on every run. It reads the DOM, reasons about state, retries when things look off, and occasionally decides to patch your test. Every one of those steps is tokens. Every token is money. And critically: every replay is a fresh bill. Not once per test authored. Once per test executed. Per commit. Per PR. Per CI retry. Per nightly. Per preview branch.

That is the structural shift. Your test suite stopped being an asset you built once and started being a metered API call you pay for forever.

Two-column comparison of where the LLM runs. Left red column shows an LLM-per-run model where the agent fires on every commit, PR, retry and nightly, so each replay is a fresh token bill. Right teal column shows the generate-once model where AI runs only when a test is created or fixed, and every replay is plain Playwright execution at zero tokens.
The only question that sets your testing bill: does the LLM fire on every run, or only when a test is authored or fixed?

The math for a small team

Let's make the assumptions explicit so you can argue with them. These are plausible mid-2026 numbers, not measurements from a specific vendor.

  • Team: 5 engineers pushing roughly 50 commits/day between them
  • Suite: 25 E2E tests
  • Per test attempt, a browser-driving agent consumes roughly 15k to 40k input tokens (DOM snapshots, prior turns, tool schemas, screenshots if multimodal) and 3k to 8k output tokens (tool calls, reasoning, assertions).
  • Retries and self-correction loops push the effective per-test cost up by roughly 1.5x on average.
  • API pricing, as of early 2026, for a frontier-class model (Claude Opus / GPT-5 tier): input in the range of ~$15 per million tokens, output in the range of ~$75 per million. Cheaper models exist, but "cheap" models also retry more, so the per-run cost converges.

Crunching the middle of each range: call it 25k input + 5k output per attempt, times 1.5 for retries = ~37.5k input + ~7.5k output per test per run. That is ~$0.56 + ~$0.56 = roughly $1.10 per test per run on the expensive end, and around $0.20 per test per run if you're lucky with a smaller model and low retry rates.

Take a middle estimate of ~$0.40 per test per run. At 25 tests, that is ~$10 per full suite run. At 50 commits/day with CI triggered on each, that is ~$500/day, or ~$10,500/month for 21 working days. For 5 engineers.

Scaled out:

Team sizeTestsFull suite runs/dayEst. monthly token cost
Small (5 eng)2550~$10,500
Medium (20 eng)80200~$134,000
Large (100 eng)300800~$2,000,000

Adjust those by 2x in either direction depending on model choice, retry discipline, and how aggressive your CI triggers are. The absolute number isn't the point. The point is that a testing line item measured in seven figures per year is trivially reachable without anyone making a bad decision.

And that's just the happy path

The numbers above assume well-behaved runs. Reality has a few extra meters running:

  • Retries on flaky runs. LLMs are non-deterministic. A test that passes 9 times out of 10 will, at scale, cost you 10 to 30% more than the baseline just from re-attempts. Flake becomes a direct P&L item.
  • Context inflation. As your app grows, so does the DOM. So does the number of user flows. So does the codebase context the agent pulls in to "understand" a failure. The token cost per test is not constant - it grows with your product. You are paying a tax on your own success.
  • Maintenance loops. When a test breaks, an LLM-driven runner will typically try to fix it. That means multi-turn reasoning, additional tool calls, sometimes a full re-read of surrounding code. A single stubborn failing test can quietly burn $5 to $10 in a single CI run before giving up.

None of this shows up in a product screenshot. All of it shows up on the invoice.

Why this is structurally worse than the old pricing

Percy's per-screenshot model was bad. It punished teams for testing more. But it had one redeeming property: the cost was deterministic and visible. You knew, before you ran anything, what it would cost. You could budget it. You could argue with it.

LLM token costs are variable, invisible until the month closes, and - here's the worst part - they scale with problems, not with value delivered. A flaky test costs more than a stable one. A broken build costs more than a green one. A growing codebase costs more than a small one. Every structural pain point in your engineering org is now also a line item on your API bill. This is the wrong direction for an incentive gradient.

The fix is a single design decision: spend tokens only when the AI creates or fixes a test, never when it replays one. That is exactly the model Lastest is built on - zero-token replays. Every subsequent execution - a CI commit, a manual re-run, a scheduled cron - is plain Playwright at $0 in tokens. The recurring, per-run bill that the math above projects doesn't shrink; it collapses into a one-time authoring cost. And if you author against a local Ollama model on your own hardware, even that authoring cost is $0 tokens. On self-hosted infra, screenshots and replays are unlimited regardless of volume, so the horizontal axis of every table above - run frequency - stops mattering entirely.

The escape hatch: generate once, replay forever

There is a clean structural fix, and it is almost embarrassingly simple: use the LLM exactly once.

Use AI to generate the test. Capture the output as plain deterministic Playwright code. Commit that code. Run it on CI with zero model calls. The AI did its job - it turned "log in, add item to cart, check out, verify receipt" into a real script - and then it goes home. Your CI pipeline never pings an API again.

The math changes shape entirely. Instead of a recurring cost per run, you pay a one-time generation cost of roughly $1 to $3 per test authored, and then $0 per run forever. Compare the cumulative 12-month cost for the small team from above:

Two cumulative cost lines over twelve months for the same five-engineer team and the same test coverage. The red per-run line climbs steeply to roughly $126,000. The teal generate-once line stays nearly flat near $250, only nudging up when tests are added or rewritten. The gap is about two orders of magnitude.
Same coverage, same team: per-run cost climbs linearly while generate-once flattens almost immediately, a two-order-of-magnitude gap by month 12.
MonthLLM-driven re-runs (cumulative)Generate-once, replay forever (cumulative)
1~$10,500~$50
3~$31,500~$80
6~$63,000~$130
12~$126,000~$250

One line climbs linearly. The other flattens almost immediately, with a tiny slope that only moves when you add or rewrite tests. Over a year, the difference is two orders of magnitude for the same coverage.

Want to see the flat line in practice? Browse real generate-once replay runs - each was authored by AI once and has replayed at $0 tokens ever since - or spin up your own in a couple of minutes on Lastest Cloud. Bring your own AI for authoring: Claude CLI, the Anthropic API, OpenRouter, OpenAI, or a local Ollama model for $0 local tokens.

What about AI test fixing?

Honest answer: yes, when a test legitimately breaks, AI is useful, and you should use it. The difference is when and how bounded.

In the LLM-driven-run model, AI touches every execution, whether or not anything is wrong. In the generate-once model, AI is only invoked when a human or the system flags a real breakage - and even then, a well-designed tool classifies the failure before burning tokens on a fix. Lastest auto-classifies every failure as real regression, flaky, environment, or test-maintenance, with a confidence score and reasoning, so a flaky run never triggers a paid fix loop. When a fix is warranted, attempts are capped and control returns to the human if it can't resolve cleanly. The cost is bounded, visible, and tied to actual signal instead of noise.

Pipeline showing how bounded AI fixing avoids runaway token spend. A failure first hits an AI classifier that labels it flaky, environment, real regression, or test-maintenance. Flaky and environment failures route straight to a human verdict with no tokens spent. Only a real regression triggers a capped fix loop, which either heals the test or hands control back to a human after the attempt limit.
Tokens are spent only after a failure is classified as a real regression, and even then the fix loop is capped before it returns to a human.

This is the model Lastest is built around: AI writes the test once with a 7-layer self-healing selector stack, deterministic Playwright code runs it forever, and AI only re-enters the loop on a flagged failure with strict attempt limits. Self-hosted via docker-compose, FSL-1.1-ALv2 licensed and free forever on your own infra, with zero tokens per replay by design.

The one-line takeaway

Use AI where it creates leverage (writing the test). Don't use AI where it creates a subscription (running the test).

If you're a solo builder or a small team shipping fast and watching every dollar of your API spend, the generate-once model is not a nice-to-have - it is the only version of AI testing that doesn't quietly become your largest infrastructure line item by end of year. More on that philosophy over on the vibe coders page, and the broader pattern is in the flake tax and the 2026 AI testing scale gap.

Do the math for your own team before your next renewal cycle. The assumptions above are rough on purpose - plug in your own commit volume, your own suite size, your own model choice. The conclusion tends to hold regardless of which numbers you pick: paying per run for something you can pay for once is a structural mistake, and it gets more expensive the more your team grows.

Stop renting your test suite back from an API. Self-host Lastest for free (open source, FSL-1.1-ALv2, unlimited screenshots and replays on your infra), or skip the ops and run on Lastest Cloud at $299/month flat - no per-seat and no per-screenshot fees, with zero-token replays either way. The full source is on GitHub.

The three-step path from this page: see it working in the demos gallery → start a run on Lastest Cloud or self-host in minutes → watch every replay land at $0 tokens on the test management dashboard. Do the math once, then never pay it per run again.