Using a tool
When a run fails
A failed run costs nothing, tells you which kind of failure it was, and carries an id that lets someone find it.
Runs fail. Providers have outages, models reject inputs they do not like, and occasionally something here is wrong. The useful question is which of those happened, because the three want different responses from you. **A failed run costs nothing.** The credits reserved at Run are released, so a provider erroring leaves your balance where it started. ## Three kinds of failure, and how to tell them apart Every failure carries a code, and every code carries a tier. The tier is what decides whether Plnty interrupts you. | Tier | What it means | What you see | |---|---|---| | A | Something about the input, and you can act on it | A toast plus a panel that opens itself, because you are the one who can fix it | | B | Transient. The retry is likely to work | A toast, and nothing blocks you | | C | Something broke badly enough that retrying will not help | A toast, and it is on us | If a panel opened itself, read it. That is the system saying the fix is on your side of the line, and it names the action: change the input, pick a different model, free some space, top up. If a toast came and went, the honest first move is to press Run again. :::note[The catalog is not vague on purpose] Around 1,350 distinct failure codes are defined, each with its own message, its own suggested action, and a flag for whether it is worth retrying. When a message says something specific, that specificity is real rather than a template. ::: ## What to do about each **Tier A, the input.** Common causes are an image below a model's minimum size, a prompt past its character limit, an unsupported format, or a combination a particular model refuses. The message says which. Scene Director, for example, checks that every cast image is at least 300x300 before any credits burn, and names the slot that failed. **Tier B, transient.** Press Run again. If three attempts fail the same way it is not transient and the provider is probably having a bad afternoon; swap the model pill and carry on with a different engine. **Tier C, ours.** Report it. The bug reporter takes a screenshot before it opens, so the report costs you a sentence. ## Provider outages Plnty routes to external providers and they go down. When one is unavailable the tool says so rather than queueing quietly, so you are never waiting on something that was never going to arrive. The work that runs on your own machine is unaffected. Remeshing, retopology, pathtraced rendering, vectorizing with Precise Trace, and the ffmpeg edit suite all carry on through any provider outage, because none of them leave your browser. :::tip[Swapping the pill is the fastest recovery] Most cards carry several engines from different providers. One being down rarely blocks the job, it just changes which pill you run. ::: ## When you need to report one Every failure carries a correlation id, which is how a run gets found later in the logs. Include it and someone can trace the exact request; leave it out and they are searching by timestamp. <kbd>Ctrl</kbd> <kbd>Shift</kbd> <kbd>B</kbd> opens the bug reporter from anywhere, screenshotting first. :::caution[Charged but nothing arrived] This one is worth reporting rather than shrugging at. The ledger has a specific code for it, a sweep that reconciles stranded reservations, and a settlement path that distinguishes "the run failed" from "the run worked and the confirmation was lost". If your balance moved and no asset landed, say so and it can be traced. :::Runs fail. Providers have outages, models reject inputs they do not like, and occasionally something here is wrong. The useful question is which of those happened, because the three want different responses from you.
A failed run costs nothing. The credits reserved at Run are released, so a provider erroring leaves your balance where it started.
Three kinds of failure, and how to tell them apart
Section titled “Three kinds of failure, and how to tell them apart”Every failure carries a code, and every code carries a tier. The tier is what decides whether Plnty interrupts you.
| Tier | What it means | What you see |
|---|---|---|
| A | Something about the input, and you can act on it | A toast plus a panel that opens itself, because you are the one who can fix it |
| B | Transient. The retry is likely to work | A toast, and nothing blocks you |
| C | Something broke badly enough that retrying will not help | A toast, and it is on us |
If a panel opened itself, read it. That is the system saying the fix is on your side of the line, and it names the action: change the input, pick a different model, free some space, top up.
If a toast came and went, the honest first move is to press Run again.
What to do about each
Section titled “What to do about each”Tier A, the input. Common causes are an image below a model’s minimum size, a prompt past its character limit, an unsupported format, or a combination a particular model refuses. The message says which. Scene Director, for example, checks that every cast image is at least 300x300 before any credits burn, and names the slot that failed.
Tier B, transient. Press Run again. If three attempts fail the same way it is not transient and the provider is probably having a bad afternoon; swap the model pill and carry on with a different engine.
Tier C, ours. Report it. The bug reporter takes a screenshot before it opens, so the report costs you a sentence.
Provider outages
Section titled “Provider outages”Plnty routes to external providers and they go down. When one is unavailable the tool says so rather than queueing quietly, so you are never waiting on something that was never going to arrive.
The work that runs on your own machine is unaffected. Remeshing, retopology, pathtraced rendering, vectorizing with Precise Trace, and the ffmpeg edit suite all carry on through any provider outage, because none of them leave your browser.
When you need to report one
Section titled “When you need to report one”Every failure carries a correlation id, which is how a run gets found later in the logs. Include it and someone can trace the exact request; leave it out and they are searching by timestamp.
Ctrl Shift B opens the bug reporter from anywhere, screenshotting first.