Reliability and routing

Automatic failover#

A model has an ordered list of routes: a primary host and, for many models, one or more backups serving the same model. A call goes to the primary first and moves to the next route when the host:

• can't be reached, or answers with a server error (5xx);
• is still busy (429) after one short retry;
• doesn't start answering within 60 seconds.

A host that keeps failing is skipped for a while, so calls go straight to a healthy one instead of waiting on it each time. You pay the model's listed price whichever route answers, and a call that failed over shows a Backup provider badge in Logs.

Failover covers chat on both APIs, embeddings and rerank. You only see a 502, 503 or 504 when every route has failed; retry those with backoff (which errors to retry). Live and past uptime per model is on the status page.

US-only routes#

Every route, backups included, runs on a host serving from the United States. The rule is checked on every call, not just when a route is set up, so a backup outside the USA is never used, even when every US route is down: the call fails instead. More on where data goes on Data privacy.

Precision guarantee#

Hosts can run the same open-weight model at different numeric precisions, and lower precision can mean lower quality. Each model states the precision it's served at, and a call is never routed to a host running it at a lower one. A backup at the same or a higher precision is fine; one below is never used.

The stated precision is the precision field of each model in GET /v1/models. It's null when the model doesn't state a precision; then any route may serve it. See Listing models from code.

curl https://fullsendai.com/v1/models -H "Authorization: Bearer $FULLSEND_API_KEY" | jq '.data[] | {id, precision}'

The fullsend/auto model#

Send "model": "fullsend/auto" and FullsendAI picks a live model for each request. It works on both APIs and is listed in GET /v1/models while it's available.

How it picks

1. Only models that can take the request. One with images goes to a model that reads images; one with tools to a model that calls tools; and the model's context window has to hold the request plus its max_tokens (1,024 when you don't set it).
2. The default pick first. FullsendAI's chosen default model answers whenever it can take the request.
3. Else the best grade under a price ceiling. The model with the highest overall grade whose blended price (three input tokens to one output) is under FullsendAI's ceiling.
4. Else the cheapest that fits. When nothing under the ceiling can take the request, the lowest-priced model that can.

If no model can take it (a huge context with images, say), the call is refused with 400 model_not_found and a message saying what it needed. A key locked to certain models picks only among those, unless fullsend/auto itself is on its allowed list.

What you get back

The response is the picked model's, and its model field names that model, not fullsend/auto. On the OpenAI-compatible API the x-fullsend-model response header names it too. The call is billed at the picked model's price and listed under it in Logs.

curl -i https://fullsendai.com/v1/chat/completions \  -H "Authorization: Bearer $FULLSEND_API_KEY" \  -H "Content-Type: application/json" \  -d '{"model": "fullsend/auto", "max_tokens": 200, "messages": [{"role": "user", "content": "Summarise this diff: ..."}]}'

HTTP/1.1 200 OKx-fullsend-model: deepseek-v4.1-flashx-request-id: req_b7fc216b3c39b963328f4ff1{  "id": "chatcmpl-1f53ee9bbae0356362c4e391",  "object": "chat.completion",  "model": "deepseek-v4.1-flash",  "choices": [{ "index": 0, "message": { "role": "assistant", "content": "…" }, "finish_reason": "stop" }],  "usage": { "prompt_tokens": 14, "completion_tokens": 120, "total_tokens": 134 }}

The pick can change between requests as models, prices and grades change, so name a model yourself when you need the same one every time, such as for an agent mid-task or a test suite.