Why your Chromatic bill exploded in the agent era

Per-snapshot pricing was a fair deal for a long time. When a human opened a handful of pull requests a week, the bill tracked your team size and it barely moved. Then coding agents made every developer multiples faster, pull request and commit volume went vertical, and the same visual coverage started costing many times more. Nobody added a single test. If your Chromatic bill exploded this year and you cannot point at new tests to explain it, this is why.

Here is the whole thing in one line. A snapshot is one story rendered in one browser at one viewport, and every per-snapshot tool bills for each one on every build. So your bill is roughly commits times stories times browsers times viewports. Three of those four terms are fixed by your app. The fourth, commits, is the one agents just multiplied.

Chromatic, like most hosted visual testing, prices per snapshot: a fraction of a cent for each story rendered in each browser at each viewport, on each build you send. Run on every commit, every pull request update, and every merge to main, and a single UI change can trigger three full builds. The model is not sneaky and it is not wrong. It was designed for a world where a person is the thing generating builds, and a person is slow. The rate per snapshot is small precisely because the commit count it multiplied against used to be small.

Take a mid-size Storybook: 500 stories, 2 browsers, 2 viewports. That is 2,000 snapshots per full build. Now count builds. Pre-agent, one developer might land around 10 UI commits a week. In the agent era, one lead I talked to measured pull request volume up roughly 3x per person, before you even count the agents opening PRs in parallel.

The bills match the math. Put illustrative dollars on it: a suite that ran a team around $1,200 a month at pre-agent commit volume lands near $3,500 once that volume roughly triples, on the exact same tests. Run the arithmetic forward and it does not stop there: say the suite grows to half a million snapshots a quarter, and even a keen enterprise rate of half a cent per snapshot lands you in five figures a year. The coverage never moved to get there. The commit count did.

Per-snapshot pricing quietly assumed a human bottleneck on the commit term. A person reviews their work, batches changes, opens a pull request when it is ready, and does that a few times a week. That rhythm kept the multiplier small and stable, so the tool could charge per snapshot and stay cheap. Agents removed the bottleneck. They push more often, they open pull requests in parallel, and every push re-renders the suite. The term that used to be a small constant is now the entire shape of the bill.

There is a second, quieter problem. When your pull request volume triples, you are not spending triple the time reviewing visual checks. So most of those extra runs are renders nobody actually looks at. You are paying full price per snapshot for builds that get a glance at best, which is a strange thing to scale linearly with your commit count.

There are exactly two levers, and they compose. One shrinks the terms you control. The other changes how the commit term is billed.

Cut the snapshot count

Fewer stories means fewer of every term: fewer snapshots per browser, per viewport, per commit. Two patterns do most of the work, dense gallery stories and data-driven states, and they can cut a component's snapshot count up to 10x with the same coverage. This is the cheapest change you can make and it works on any per-snapshot tool, Chromatic included. I wrote the full playbook in How I cut my Chromatic bill 10x.

Stop re-billing unchanged work

The deeper fix is to stop paying to re-render stories that did not change. With skip-unchanged, a 3-line change renders only the stories it actually affects and carries the rest forward, so a busy branch does not re-bill 2,000 snapshots on every push. That defuses the commit multiplier directly: more commits stop meaning proportionally more snapshots. On UI Verify it is the `--only-changed` flag. The other half is review. If your tool renders a diff and hands it to a human, every extra commit is another image you have to eyeball. An AI judge triages the diffs and tells an intended change from a real regression, and over MCP your agent reviews and accepts, so the review cost stops scaling with commits either. That difference is the whole of UI Verify vs Chromatic.

Chromatic is very good, and for plenty of teams it is still the right tool. It is deeply integrated with Storybook, it has a mature design-versus-development sign-off workflow that a lot of teams standardize on, it offers unlimited concurrency, and it is built by the team behind Storybook itself. If your bottleneck is designer and developer sign-off rather than commit volume, or you are simply not commit-bound, the per-snapshot model is fine and Chromatic runs it well. The point of this post is narrow: the assumption that made per-snapshot cheap is the one the agent era changed.

For the record, our own numbers are public and flat. UI Verify includes 10,000 snapshots a month free, paid plans start at $89 a month for 30,000 snapshots, and overage is $0.004 per snapshot. The pricing is not the moat, though. Skip-unchanged and an AI judge are, because they attack the term that actually exploded.

If your bill jumped this year and your test count did not, you are not imagining it, and you are not doing anything wrong. The input changed. Cut the stories you can, stop paying to re-render the ones that did not move, and let review scale with real changes instead of raw commits. The economical stories skill will refactor the exploding stories for you, and it is free.