Set Up Burki LLM Fallback Providers

Your receptionist has approved opening hours and a clear answer to give, but its primary language-model request is rejected. A configured backup can be useful in that situation. A connection disappearing after part of an answer is a different problem: starting another model could repeat work whose outcome is still uncertain.

Burki LLM fallback providers let an operator configure ordered backup candidates for a Standard pipeline assistant. The current implementation uses a conservative distinction between a known rejection before output and an uncertain or partially delivered response. This guide explains the configuration and that boundary with a fictional reception example.

Download the free fallback setup worksheet. It includes a secret-free candidate inventory, a shared-budget record and proposed acceptance cases. No provider key was entered, setting saved, failure induced or paid request run for this guide. The resource is free; later evaluation and production voice usage have their own costs.

Choose the correct fallback layer

Here, a candidate is the language model that generates the assistant's reply. It is not a backup phone number, a second voice, an alternate booking action or a carrier failover route.

The separate Inworld first-token fallback guide explains a provider's request-level router. Its model list and first-token timeout are not fields to paste into Burki's native fallback form. This article covers the product's own configured language-model candidates.

A useful first version has one primary and one backup, with the same approved business facts and answer expectations. More candidates introduce more credentials, rates and behaviors to review. They do not create additional session allowances or guarantee that another attempt will be permitted.

Confirm the assistant's conversation engine

Open Assistants and the intended saved assistant. Go to Voice → Model and provider choices and inspect Conversation engine. This walkthrough applies to Standard pipeline · advanced provider choices.

GPT Live does not support these fallback providers. The editor can retain earlier choices while showing that they are unavailable in that mode, and admission rejects actual fallback candidates for GPT Live. A separately configured announcement voice does not supply a backup conversation model.

Use an existing assistant intended for the standard pipeline. Changing engines also changes the model and speech requirements, supported controls, credentials and funding to inspect. Do not treat an engine change as a harmless way to expose one field.

The current Fallback providers section was opened read-only on a saved standard-pipeline assistant. Its switch was off and was left off. The conditional row fields below were checked against current product source, rather than represented as fields opened in that live session.

Prepare one candidate before enabling it

Expand Fallback providers under Voice → Model and provider choices. For an authorized configuration, the enabled form provides Add fallback provider, followed by an ordered row such as Fallback #1.

Each enabled row contains Provider, Model and API Key. A Custom Provider row also exposes Base URL. The editor offers Add fallback provider while fewer than three rows exist. This worked setup uses one backup so its account, behavior and cost can be reviewed clearly.

Before intentionally entering or saving a candidate, record:

A candidate-specific API key is a credential, not worksheet content. Record its owner or secret reference without copying the value. Recheck ownership and model access after changing the selected provider. A key that authorizes one provider is not automatically valid for another.

In the current admission mapping, an explicit candidate key selects that candidate's own external credential path. A BYO candidate missing its required key cannot silently borrow platform credentials. A managed candidate still needs the applicable managed configuration and admitted rates. The presence of a row is not proof that either route is ready.

Work through a simple reception setup

For a fictional Alder Reception, the operator-approved fact is: “Reception is open Monday to Friday, 09:00–17:00 in the business timezone, and closed on public holidays.” The caller asks, “Can I visit reception at noon on a public holiday?”

Keep the current primary model as the baseline. Add one supported backup model only after checking the account and credential requirements. For example, the current Claude selector includes claude-sonnet-4-6; seeing that identifier in Burki's catalog does not establish that a particular account can invoke it. This example does not rank it above the primary or claim it is the latest model.

The intended answer from either candidate is that reception is closed on public holidays. Neither should infer availability from the weekday hours, invent an exception or claim an appointment was booked. The worksheet holds the exact primary and backup identifiers and the approved fact so a later comparison changes the candidate rather than quietly changing the task.

For the operator's later authorized setup, use the section's enable switch, add the intended row, choose the provider and model, and supply the appropriate credential through the actual secret field. Keep one deliberate order. Review the entire row before Save changes; a row's label alone does not establish the complete saved candidate configuration.

Understand when the implementation switches

The current controller tries candidates in their admitted order. A replacement is permitted only when the owned request has a supported, definitive provider rejection before any response chunk was emitted, with the required closure evidence.

That is narrower than “switch whenever the primary fails.” The implementation verifies a finite combination of official endpoint, status and error meaning. For example, Claude distinguishes authentication, permission and rate-limit errors, while its documentation also warns that a streaming error can occur after HTTP 200. Those situations should not be collapsed into one generic failure label. Claude API error documentation.

Custom HTTP and WebSocket endpoints do not inherit an authoritative no-generation rejection contract from their names. The current implementation does not automatically switch after an arbitrary custom request that might already have run. A native provider's documented error meaning should not be assumed for another host or an equivalent-looking proxy.

Configuration and source-contract illustration. It contains no recorded provider failure, timing measurement or successful production failover.

Keep the selected model and budget visible

Once the controller moves to a backup, that selection is sticky for later turns in the same session. It does not periodically probe the original model and switch back just because the next question is easy. Keep that behavior in the evaluation record when reviewing a longer conversation.

The candidates share one token allowance and deadline. Earlier work can consume the capacity that a later candidate would need. A valid backup configuration can therefore still be blocked by the remaining allowance. Failed attempts do not create a fresh budget.

Externally billed provider usage and Burki's platform charge also remain separate. Review the rates and funding for the actual selected setup and telephone route, rather than treating the backup as free insurance. The pricing page explains the broader cost components; it is not a fixed all-in quote for every candidate sequence.

Save, publish and evaluate the intended version

Inspect Publish → Published version before saving an existing assistant. With versioned publication, saved edits remain a draft until the applicable publication action, and telephone calls use the published version. A legacy live settings warning means saving affects connected calls. Do not assume every assistant has an isolated draft.

Follow the appropriate authorized review before Publish assistant or Publish saved changes where shown. No such action was performed for this article. An AI receptionist should have an approved response when a request cannot complete, as well as correct normal answers.

The worksheet separates seven cases: normal primary completion, supported rejection, sticky continuation, partial output, generic timeout, budget exhaustion and caller interruption. Fill the observed result only when the corresponding evidence exists. Do not manufacture failures with invalid live keys or paid traffic merely to populate a worksheet.

The implementation documentation and bounded tests establish the behavior described in source. They do not establish the exact deployed voice-worker revision, a provider-accepted fallback or what a real caller heard. Those remain separate acceptance questions. Use this guide to prepare a reviewable configuration and an honest test plan, without turning an enabled switch into a claim that every outage is covered.