Reliability:
How requests are handled

If an upstream source has a problem, a request can try another available source. If none is available, the request returns an error.

See how a request can try another source See Public Verification Results

What happened in this requestTotal 5.0s

Source 10

No response

Source 2200

Took over

Generation

3077 tokens · 39.4 tok/s

Example: when one source has a problem, a request switches to another available source.

How a request can switch sources

Each request checks source health; a switch is possible only when another source is available.

Source status

Your request

Is the primary source available?

Source 1 (primary)Unavailable

Failed the health check, skipped

Source 2 (alternate)

Can handle the request if available

Response status

If the primary source cannot handle a request, the system may try another available source. If none is available, it returns an error.

Long-running jobs from real customers

Historical records include a text stream lasting up to 60 minutes and a video job lasting up to 9.8 hours.

60 minutes

Longest observed text stream

67,462 tokens in a recorded run

9.8 hours

Longest observed video job

Asynchronous generation, recorded run

Historical platform data, not a service commitment.

Long-running jobs can use api.bazaarlink.ai, an API entry deployed separately from the website.

How it works

Four facts about how requests are handled in different situations.

More than one upstream source can be configured for the same model

Each source is monitored separately; a request may switch when another source is available.

Repeated errors can temporarily skip a source

If another source is available, a request may switch to it; otherwise, the request returns an error.

Retries happen before you see any content

We check for a model response before streaming content. After streaming starts, the response does not continue through a different source.

Failures show up in your usage log

You can see retries and failure codes in your usage log; it does not show the name of the source used.

If the connection drops after content has already started

If no source can serve a request, you'll see a clear error instead of an incomplete response; that request isn't charged. This describes the mechanism, not an availability guarantee. Any SLA in your contract applies.

Want to see how source switching and circuit breakers work?

The docs explain how source health is checked, how circuit-breaker thresholds work, and what usage-log fields mean.

Read about upstream source behavior

Point your own traffic at it

Connect in five minutes; if a source has a problem, a request may switch to another available source.

See how a request can try another source

Reliability:How requests are handled