Reference
How screens are matched, what counts against your allowance, and what each result means.
How a screen is matched to its baseline
A picture is compared against the baseline that shares all four of:
| Part | Where it comes from |
|---|---|
| Project | The project you captured into. Never guessed. |
| Screen name | The name you gave it — or, for an upload, the filename. |
| Browser and OS | The browser it was taken on. Uploads are recorded as upload on ci unless you pass --browser and --os. |
| Width | The width of the window, or for an upload the width of the picture. |
Change any one of them and you get a separate baseline. That is usually what you want: a mobile layout and a desktop layout are different screens and should have separate histories.
Height is not part of the match. A full-page screenshot is as tall as the page, so adding a row to a table changes its height. If height were part of the match, that would silently become a brand-new screen and the comparison you were waiting for would never happen. Instead it stays the same screen, and the extra row is a change to review.
Results
| Result | Meaning | Counts against your allowance |
|---|---|---|
new / baseline | First picture of this screen | Yes |
same / identical | No difference | Yes |
CHANGED | Different — waiting for a person | Yes |
failed | We could not compare it | No |
A failed picture is safely stored. Running the capture again is enough —
nothing is lost, and nothing is charged for the attempt.
Review states
| State | Meaning |
|---|---|
| Approved | Someone looked and said it is correct. It is the baseline now. |
| Unreviewed | It changed and nobody has decided. |
| Reported as a bug | Someone looked and said it is wrong. |
Allowances
Visual is counted in snapshots — one picture compared is one snapshot. It is its own subscription and does not draw on Live or Automate.
Uploading and comparing never starts a session or claims a device, so nothing is billed against those plans. Capturing from inside a Live session uses that Live session as normal — the session is what costs, not the picture.
Current allowances and prices are on the pricing page.
CLI exit codes
| Code | Meaning |
|---|---|
0 | Nothing to review |
1 | Something changed, or a picture could not be uploaded |
2 | The command was wrong — nothing was created |
Limits worth knowing
Uploads are PNG. The CLI picks up **/*.png by default; change it with
--files.
Five uploads at a time, adjustable with --concurrency up to 10. If you ask
for more than that it is quietly treated as 10 rather than refused.
If you upload faster than we accept, the CLI waits and retries rather than failing the screen. You do not need to add sleeps to your pipeline.
A build stays open until it is finished. If a CI machine crashes mid-run, its build is closed for you later — but the pictures it did upload are already reviewable.
What we never do
We never take your image data through our API. The CLI uploads straight to storage; our API hands out the address and receives the result.
We never create a session for an upload. No device is claimed, no minute is consumed, and nothing appears in your Live or Automate history.
We never invent a project. A --project that does not exist is an error, not
a new project — a typo that quietly made an empty project would compare nothing
and pass.
Getting help
If a screen is behaving in a way this page does not explain — comparing when it should not, or not comparing when it should — the screen's history is the fastest answer. It shows every capture, what it was compared against at the time, and who decided what.