When a job goes wrong

The machines serving your request are somebody's desktop. They get switched off, they lose Wi-Fi, their owner starts a game. A network built on that has to treat failure as ordinary rather than exceptional — and be plain about what you are charged when it happens.

A host takes a job and vanishes

Every claimed job has a deadline for producing its first output. Miss it and the job is taken back and returned to the queue for another machine — once. You see a slower response; you do not see an error, and you are not charged twice.

If the host dies after output has reached you — it crashes mid-answer, or the stream goes quiet for longer than the stall window — the job is handed to a continuation: another machine receives the original conversation plus the exact text you already saw, and the same stream picks up where it stopped. The engine continues from the prefix — mid-word if that is where it died — so nothing you received is contradicted or repeated. This happens at most once per request: a fleet losing two hosts on one answer fails loudly rather than thrashing.

The dead host is not paid for its segment (it signed no receipt), and you are not billed for the re-processed prompt — a continuation bills its new tokens only. A failure that was never yours should never appear on your bill twice.

Nothing can serve it

If the request carries a placement requirement no live host satisfies, you get a 503 immediately, naming what was required. If the queue simply has no free machine, the request waits, and a wall clock — two minutes by default — ends it with a timeout rather than letting it hang.

What you pay

Tokens that were produced. A job that fails before producing anything costs nothing. A job that fails partway bills the tokens you actually received, which is also what the host is paid 80% of. No failure surcharge, no minimum. How the price itself is set is in what you pay and why.

What the host sees

A model that will not load on a machine is recorded as a failed capability for that build, with the error, on the machine's page — not silently dropped. Usually the honest answer is that the card does not have the VRAM the catalogue estimated, which is why a benchmark on your own hardware is the only figure the dashboard treats as real.

A host that repeatedly claims work and fails to deliver earns nothing from those jobs, because payment follows produced tokens.

What is not there yet

• One continuation per request. If the continuation host dies too, the request fails for real. Two dead machines on one answer is a fleet problem, not something to paper over with a third attempt.
• A continuation is a new machine continuing your text — coherent with everything already received, but not the byte-for-byte stream the first machine would have produced. For deterministic pipelines, treat a failed_over job in your logs as the signal it is.

Named here because a reliability page that only describes what works is not a reliability page. (And the old gaps this section used to admit — no alerting, no cross-host continuation — are gone: a quiet machine emails its owner, and a mid-answer death continues on another host.)