# Back-upmodellen voor AI-agents: zo blijft je agent werken als een model uitvalt

> Hoe back-upmodellen voor AI-agents werken, welke fouten een fallback moeten activeren, waarom de back-up zich anders gedraagt en hoe je deze vóór een storing test.

Last updated: 2026-09-28T14:00:00

Canonical URL: https://crevio.co/nl/blog/ai-agent-backup-models

*Laatst bijgewerkt: september 2026. Statuspagina's, incidentrapporten en documentatie gecontroleerd op 28 september 2026.*

**Het model van je agent valt uit — en het back-upmodel dat je daarvoor hebt ingesteld, gedraagt zich niet zoals het model waarmee je hebt getest.** Op 28 september 2026 liet de statuspagina van de Claude API een uptime van 99,52% zien over de voorafgaande 90 dagen. Dat klinkt bijna perfect, totdat je de rekensom maakt: 0,48% van 90 dagen staat gelijk aan ongeveer 10 uur verminderde beschikbaarheid of uitval in één kwartaal. Een back-upmodel voor je AI-agent zorgt ervoor dat je agent ook tijdens die uren blijft werken. Als je het onzorgvuldig instelt, zorgt het er juist voor dat een taak stilletjes half wordt afgerond door een model dat niemand ooit heeft getest.

Deze gids is bedoeld voor bedrijfseigenaren en operators die agents volgens een schema of rechtstreeks voor klanten laten werken. We bespreken wat er mis kan gaan, welke fouten een omschakeling moeten activeren, hoe de belangrijkste routingtools ermee omgaan en hoe je vóór het zover is kunt aantonen dat je fallback werkt.

- **Van buitenaf zien drie verschillende storingen er hetzelfde uit:** uitval, rate limits en modellen die uit gebruik worden genomen. Slechts bij sommige daarvan heb je een back-upmodel nodig
- **Probeer eerst opnieuw, schakel daarna pas over.** Veel storingen verdwijnen na een korte retry of op een andere host waarop hetzelfde model draait
- **Een back-upmodel is geen één-op-éénkopie.** Nieuwere modellen weigeren parameters die oudere modellen wel accepteerden, tool calling werkt anders en de warme promptcache is weg
- **Fallbacks kosten per stap meer dan je verwacht,** omdat de back-up met een koude cache begint
- **Een fallback die je niet hebt getest, is een gok.** Forceer expres een storing, voer echte taken uit op de back-up en log welk model antwoordde

## Wat is een back-upmodel voor een AI-agent?

Een back-upmodel voor een AI-agent, ook wel een LLM-fallback genoemd, is een tweede model dat vooraf is ingesteld om het over te nemen wanneer het hoofdmodel van de agent geen antwoord kan geven. De omschakeling gebeurt meestal automatisch: een router of gateway detecteert de fout, stuurt hetzelfde verzoek naar het volgende model in een lijst en geeft het antwoord terug alsof er niets is gebeurd.

Het is één van vier beschermingslagen. Je grijpt er pas als derde naar, niet als eerste:

| Laag | Wat doet deze laag? | Lost op | Verandert het model? |
|---|---|---|---|
| **Retry** | Stuurt hetzelfde verzoek na een korte wachttijd opnieuw | Korte pieken, eenmalige time-outs | Nee |
| **Host-failover** | Stuurt het verzoek naar een andere provider waarop hetzelfde model draait | Uitval van één datacenter of host | Nee |
| **Model-fallback** | Stuurt het verzoek naar een ander model | Volledige uitval, opgebruikte quota | Ja |
| **Geplande migratie** | Verplaatst de agent bewust naar een nieuw model | Uitfasering en beëindiging van ondersteuning | Ja, permanent |

De volgorde is belangrijk, omdat elke stap verderop in de tabel meer verandert aan het gedrag van je agent. Een retry verandert niets. Een ander model verandert bijna alles, zoals de volgende secties laten zien.

## Drie manieren waarop je primaire model uitvalt

### Storingen

Elke grote provider heeft ermee te maken gehad en de incidentrapporten zijn openbaar. Op 11 december 2024 waren [alle OpenAI-services ernstig verstoord of niet beschikbaar](https://status.openai.com/incidents/ctrsv3lwd797) van 15.16 tot 19.38 uur Pacific Time: 4 uur en 22 minuten lang waren ChatGPT, de API en Sora getroffen. De oorzaak was een nieuwe telemetrieservice die de Kubernetes-controlplane van OpenAI overbelastte. De bug kwam alleen in grote clusters aan het licht, waardoor tests hem niet detecteerden.

![Incident op de OpenAI-statuspagina van 11 december 2024, gemarkeerd als Resolved en Full outage, met 9 getroffen API-componenten en 5 getroffen ChatGPT-componenten met rode en oranje statusbalken](https://crevio.co/vite/assets/openai-status-december-2024-incident-gqiohlkd.png)

Kortere storingen komen veel vaker voor. Op 4 maart 2026 meldde OpenAI [30 minuten met verhoogde API-fouten](https://status.openai.com/incidents/01KJXQDJ6P1CG5YNXKZRY2H6RX/write-up), nadat een reeks uitgestelde capaciteitswijzigingen tegelijk werd uitgevoerd en inference-engines buiten gebruik stelde. Op de statuspagina van Anthropic zie je hetzelfde patroon: lange perioden met groen, afgewisseld met een gestage stroom korte rode en oranje dagen.

![Claude-statuspagina met All Systems Operational en uptimebalken over 90 dagen voor claude.ai met 99,43%, Claude Console met 99,95% en de Claude API met 99,52%](https://crevio.co/vite/assets/claude-status-page-eal06oie.png)

Een storing van 30 minuten merk je nauwelijks tijdens een chat. Voor een geplande taak die precies in dat tijdvenster wordt uitgevoerd, maakt het veel uit: er is dan niemand om op ‘opnieuw proberen’ te klikken.

### Rate limits en 429-fouten

Een 429-fout betekent dat de provider beschikbaar is, maar je verzoek nu niet verwerkt. Meestal gaat het om een limiet per minuut: de API van Anthropic gebruikt een [token bucket die continu wordt aangevuld](https://platform.claude.com/docs/en/api/rate-limits) en stuurt een `retry-after`-header met het aantal seconden dat je moet wachten. Zo lang wachten en vervolgens hetzelfde model opnieuw proberen is dan de juiste aanpak.

Niet elke 429 is tijdelijk. Wanneer een organisatie bij Anthropic de maandelijkse bestedingslimiet bereikt, geeft de API een 429 terug **zonder** `retry-after`-header. De documentatie zegt daar zonder omhaal over: "Retrying, including the SDKs' automatic retries, fails until access resumes." De toegang wordt aan het begin van de volgende maand hersteld. Een agent die elke 429 behandelt als ‘wachten en opnieuw proberen’, blijft dus de hele nacht proberen op een limiet die mogelijk wekenlang niet wordt gereset.

### Uitfasering en beëindiging

Modellen worden volgens een schema uitgefaseerd en een uitgefaseerd model werkt niet geleidelijk steeds slechter. Het [deprecationbeleid van Anthropic](https://platform.claude.com/docs/en/about-claude/model-deprecations) belooft voor publiek uitgebrachte modellen minimaal 60 dagen van tevoren een aankondiging en stelt dat "requests to models past the retirement date will fail." Claude Opus 4.1 is een recent voorbeeld: ontwikkelaars werden op 5 juni 2026 geïnformeerd en het model werd op 5 augustus 2026 uitgefaseerd.

![Pagina over modeluitfasering in de Claude Platform-documentatie met de levenscyclusfasen Active, Legacy, Deprecated en Retired, plus de waarschuwing dat uitgefaseerde modellen waarschijnlijk minder betrouwbaar zijn dan actieve modellen](https://crevio.co/vite/assets/claude-model-deprecations-gt44ujck.png)

De [uitfaseringpagina van OpenAI](https://developers.openai.com/api/docs/deprecations) geeft algemeen beschikbare modellen minimaal zes maanden van tevoren een aankondiging, maar previewmodellen "may be retired with much shorter notice, such as 2 weeks." In juni 2026 kondigde OpenAI aan dat de GPT-5- en o3-snapshots op 11 december 2026 zouden worden uitgezet. Een back-upmodel lost uitfasering niet op. Het verbergt het probleem alleen totdat ook de uitfaseringsdatum van de back-up aanbreekt.

### De storing die geen enkele fallback opvangt

De duurste storing geeft nooit een foutmelding. In 2025 publiceerde Anthropic [een postmortem over drie infrastructuurbugs](https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues) die de antwoorden van Claude wekenlang verslechterden. Op het slechtste moment werd 16% van de Sonnet 4-verzoeken door één van die bugs getroffen. Een van de redenen waarom het zo lang duurde om het probleem te vinden: "Claude often recovers well from isolated mistakes," waardoor het probleem verborgen bleef.

Geen enkele fallbackketen wordt geactiveerd door een slechter antwoord, want een slechter antwoord levert nog steeds een 200-statuscode op. Daarvoor heb je [steekproeven van de output van je agent](/nl/blog/human-in-the-loop-ai-agents) nodig, niet routing.

## Welke storingen moeten overschakelen naar een back-upmodel voor een AI-agent?

Lees de fout voordat je reageert. ‘Het model is mislukt’ kan betekenen dat je vijf seconden moet wachten, dat je nu moet overschakelen of dat je je eigen verzoek moet aanpassen.

![Vijf providerstoringen en de juiste reactie op elke storing: wachten en opnieuw proberen bij een 429 met retry-after, overschakelen naar de back-up bij een 429 zonder retry-after, eerst opnieuw proberen, daarna van host wisselen en vervolgens overschakelen bij 5xx-fouten of time-outs, het verzoek aanpassen bij een 400 en de vervanger activeren vóór de uitfaseringsdatum](https://crevio.co/vite/assets/which-failures-need-a-backup-model-mvzdhotu.svg)

Twee rijen verdienen wat extra aandacht:

- **5xx-, overbelastings- en time-outfouten.** In de [foutreferentie van Anthropic](https://platform.claude.com/docs/en/api/errors) staat een 529 `overloaded_error` voor veel verkeer bij alle gebruikers. De SDK's proberen tijdelijke fouten al twee keer opnieuw met exponentiële back-off. Nog één retry kan prima. Vijf retries veranderen een hapering van 30 seconden in een stilstand van 10 minuten
- **400-fouten.** Een ongeldige parameter of verkeerd opgemaakt verzoek mislukt ook bij de back-up, vaak om dezelfde reden. De uitzondering is een prompt die te lang is: sommige routers sturen die in plaats daarvan naar een model met een groter contextvenster. Dat is een fallback die wel helpt

## Hoe fallbackketens en routing werken

Meestal bouw je fallbacklogica niet zelf. Een routinglaag tussen je agent en de providers doet dat voor je. Vier opties komen vaak voor:

| Tool | Zo stel je de back-up in | Wat activeert deze? | Zo zie je welk model antwoordde |
|---|---|---|---|
| **OpenRouter** | Een `models`-array in volgorde van prioriteit | Uitval, rate limits, fouten door de contextlengte, moderatievlaggen | Het veld `model` in het antwoord |
| **LiteLLM** | `fallbacks`, plus afzonderlijke fallbacks voor contextvenster en contentbeleid | Rate limits en serverfouten, met cooldowns na herhaalde fouten | Proxyl logs en callbacks |
| **Vercel AI Gateway** | Een `models`-array, gecombineerd met een provider `order` | Elke fout bij alle providers voor een model | Een `modelAttempts`-lijst in de providermetadata |
| **Cloudflare AI Gateway** | Een lijst met stappen op het Universal-endpoint | Fouten en time-outs van verzoeken | De `cf-aig-step`-responseheader |

De [modelfallbacks van OpenRouter](https://openrouter.ai/docs/guides/routing/model-fallbacks) zijn het eenvoudigst voor te stellen: je geeft een lijst met model-ID's door en "if the first model returns an error, OpenRouter will automatically try the next model in the list." Je betaalt het tarief van het model dat uiteindelijk antwoordt. De [providerrouting](https://openrouter.ai/docs/guides/routing/provider-selection) van OpenRouter regelt daarnaast host-failover voor hetzelfde model. Standaard geeft OpenRouter de voorkeur aan providers die "have not seen significant outages in the last 30 seconds" en `allow_fallbacks` blijft ingeschakeld totdat je dit uitzet.

![OpenRouter-documentatiepagina over Model Fallbacks, waarin wordt uitgelegd dat de parameter models automatisch andere modellen probeert als de providers van het primaire model uitgevallen zijn, rate-limited zijn of niet willen antwoorden](https://crevio.co/vite/assets/openrouter-model-fallbacks-docs-k3qy0sqx.png)

De [betrouwbaarheidsinstellingen van LiteLLM](https://docs.litellm.ai/docs/proxy/reliability) splitsen het probleem verder op. Gewone `fallbacks` vangen rate limits en serverfouten op, `context_window_fallbacks` stuurt een te grote prompt naar een groter model en `content_policy_fallbacks` vangen fouten door het contentbeleid op. `allowed_fails` en `cooldown_time` halen een model dat fouten geeft tijdelijk uit de roulatie, zodat een haperende provider niet bij elk verzoek opnieuw wordt belast.

De [modelfallbacks van Vercel AI Gateway](https://vercel.com/docs/ai-gateway/models-and-providers/model-fallbacks) combineren beide lagen: eerst worden alle toegestane providers voor het primaire model geprobeerd, daarna het volgende model in de `models`-array. Elke poging wordt vastgelegd. De [fallbacks van Cloudflare AI Gateway](https://developers.cloudflare.com/ai-gateway/configuration/fallbacks/) werken op het Universal-endpoint en laten in een header zien waar het antwoord vandaan kwam: `cf-aig-step: 0` betekent dat het primaire model antwoordde, `1` dat de eerste fallback dat deed.

Voor alle vier geldt één waarschuwing. **De gateway is zelf ook een afhankelijkheid.** Het eigen netwerk van Cloudflare had op [18 november 2025](https://blog.cloudflare.com/18-november-2025-outage/) een grote storing, van 11.20 tot 17.06 uur UTC, nadat een verkeerd configuratiebestand zich door het netwerk had verspreid. Een fallbackketen beschermt je tegen het uitvallen van een modelprovider. Niet tegen de laag die de keten uitvoert.

## Waarom een back-upmodel voor een AI-agent zich anders gedraagt

Een fallback die een antwoord geeft, heeft zijn taak niet per se uitgevoerd. Agents zijn hier kwetsbaarder dan chatbots, omdat een agent midden in een meerstapstaak zit wanneer de omschakeling plaatsvindt. Het nieuwe model moet daarbij een lange geschiedenis van toolaanroepen overnemen.

![Wat er verandert wanneer een agent van model wisselt: overschakelen naar hetzelfde model op een andere host behoudt promptgedrag, tool-callindeling, parameters en contextvenster, terwijl een nieuwer model van dezelfde leverancier of een model van een andere leverancier de meeste hiervan verandert en elke omschakeling de warme promptcache verliest](https://crevio.co/vite/assets/what-changes-when-an-agent-switches-models-nxjdqm6x.svg)

### Parameters die het ene model accepteert en het andere weigert

Dit probleem doet zich zelfs voor binnen één leverancier. Volgens de [uitfaseringsnotities](https://platform.claude.com/docs/en/about-claude/model-deprecations) en de [foutreferentie](https://platform.claude.com/docs/en/api/errors) van Anthropic geldt het volgende:

- Als je `temperature`, `top_p` of `top_k` instelt op een andere waarde dan de standaardwaarde, geeft Claude Opus 4.7 en hoger een 400-fout
- Een specifieke tool afdwingen met `tool_choice` geeft een 400-fout bij Claude Opus 5.5, Sonnet 5.5 en Fable 5.1
- Het begin van het antwoord van de assistant vooraf invullen geeft bij Claude 4.6 en latere modellen een 400-fout

Een keten die van een ouder model terugvalt op een nieuwer, ‘beter’ model kan dus direct mislukken met een fout die het primaire model nooit gaf. De optie [`require_parameters` van OpenRouter](https://openrouter.ai/docs/guides/routing/provider-selection) bestaat deels om dit probleem op te lossen: deze routeert alleen naar providers die alle meegestuurde parameters ondersteunen.

### Tool calls en prompts

Verschillende leveranciers verwachten tools, resultaten en redeneerstappen in verschillende indelingen. Een cross-vendor fallback hangt daarom af van de gateway die het gesprek correct vertaalt. Zelfs als de indeling behouden blijft, is de back-up niet het model waarop je je instructies hebt afgestemd. Het kan tools in een andere volgorde aanroepen, eerder stoppen of ‘wees beknopt’ interpreteren als ‘sla de controle over’. Sommige redeneergegevens gaan helemaal niet mee: Anthropic merkt op dat een thinking block "from a model the target model can't read is dropped."

### Contextvensters

Als de back-up minder kan lezen dan het primaire model, kan een lange agentrun op het moment van de omschakeling al te groot zijn. Daarom noemt OpenRouter fouten door de contextlengte als fallbacktrigger en geeft LiteLLM hiervoor een afzonderlijke fallbacklijst. Voeg een back-up toe met minstens hetzelfde contextvenster als het primaire model, of laat de agent oudere geschiedenis samenvatten voordat hij overschakelt.

## Wat fallbacks kosten

Een back-upmodel verandert je rekening op drie manieren. Geen daarvan zie je terug in een prijstabel.

**De warme cache is weg.** Promptcaching is een belangrijk onderdeel van betaalbare agents: de instructies, toold definities en geschiedenis worden bij elke stap opnieuw verstuurd en grotendeels tegen het cached tarief in rekening gebracht. Caches horen bij een specifiek model op een specifieke provider. Daarom gebruikt OpenRouter [sticky routing](https://openrouter.ai/docs/guides/best-practices/prompt-caching) "to route your subsequent requests to the same provider endpoint after a cached request." Schakel je over, dan betaal je voor de volgende stap het volledige tarief. Bij de [lijstprijs van Claude Sonnet 5.5](https://platform.claude.com/docs/en/about-claude/pricing) van $2,00 per miljoen inputtokens en $0,20 voor cached tokens kost een agentgeschiedenis van 50.000 tokens ongeveer $0,01 om opnieuw vanuit de cache te versturen en ongeveer $0,10 zonder cache. Dat is tien keer zoveel per stap, totdat de eigen cache van de back-up is opgewarmd.

**Je betaalt voor het model dat antwoordde, met diens eigen tokens.** OpenRouter brengt het model in rekening dat uiteindelijk antwoordde. Een fallback naar een duurder model kost dus meer, maar een goedkopere back-up die extra stappen nodig heeft om de taak af te ronden kan ook duurder uitvallen. Tokenaantallen zijn bovendien niet uitwisselbaar: op de [prijspagina](https://platform.claude.com/docs/en/about-claude/pricing) van Anthropic staat dat de Claude 4.7-modellen en latere modellen een nieuwe tokenizer gebruiken die voor dezelfde tekst ongeveer 30% meer tokens produceert.

**Retries kosten ook geld.** Een verzoek dat halverwege een stream mislukt, heeft vaak al betaalde tokens geproduceerd. Bovendien verstuurt elke retry de volledige context opnieuw. We hebben in [Kosten van AI-agents](/nl/blog/ai-agent-running-costs) besproken hoe dit optelt: mislukte runs en loops vormen een staart die groter kan zijn dan het gemiddelde.

Dit alles is geen argument tegen back-ups. Het is een argument om ze als back-ups te gebruiken. Laat retries en host-failover de alledaagse fouten opvangen, zodat de dure omschakeling alleen plaatsvindt bij echte storingen.

## Test je fallback voordat je hem nodig hebt

De meeste fallbackketens worden voor het eerst gebruikt tijdens een incident. Dat is het slechtste moment om te ontdekken dat de back-up je tools niet kan aanroepen. Een korte oefening elk kwartaal en na elke modelwijziging vangt het meeste op:

1. **Forceer de storing.** Laat het primaire model verwijzen naar een niet-bestaande model-ID of gebruik de testswitch van je router. LiteLLM biedt `mock_testing_fallbacks=True` in de SDK en adviseert voor de proxy om in een niet-productieomgeving een echte providerfout te activeren
2. **Voer echte taken uit, geen hello-worldprompt.** Neem drie of vier echte taken van je agent, waaronder een lange run met veel toolaanroepen, en laat ze volledig op de back-up uitvoeren
3. **Vergelijk de output.** Heeft de agent dezelfde tools aangeroepen, is hij op hetzelfde punt gestopt en heeft hij je opmaakregels gevolgd? Lees de transcripties, niet alleen het uiteindelijke antwoord
4. **Controleer welk model antwoordde.** Bekijk het `model`-veld, `modelAttempts` of de `cf-aig-step`-header van het antwoord. Een test waarbij het primaire model stilletjes antwoordde, bewijst niets
5. **Stel meldingen in voor fallbacks.** Een back-up die elke dag wordt geactiveerd, is geen back-up meer. Het is je echte model, ongetest op dat volume, en je wilt daarvan op de hoogte zijn
6. **Zet uitfaseringsdata in je agenda.** Controleer de deprecationpagina's voor zowel het primaire model als de back-up en stap ruim vóór een van beide data over op de vervanger

Combineer dit voor geplande taken met een plan voor runs die toch mislukken. Onze gids over [terugkerende AI-agenttaken plannen](/nl/blog/schedule-recurring-ai-agent-tasks) beschrijft hoe een goede mislukking eruitziet: een gedeeltelijk resultaat, een duidelijke melding en een taak die zichzelf stopt in plaats van eindeloos opnieuw te proberen.

## Hoe de agent van Crevio omgaat met modelfouten

[Crevio](https://crevio.co/) is een AI-businessbuilder: je beschrijft wat je wilt verkopen en de agent bouwt, lanceert en beheert het werk eromheen. Crevio kiest de modellen achter die agent en voert ze uit. Je beheert dus geen provideraccounts, sleutels of modelversies. Hieronder leggen we duidelijk uit wat er gebeurt wanneer een model zich misdraagt — inclusief wat Crevio niet doet.

**Wat de agent nu doet:**

- **Probeert automatisch opnieuw met hetzelfde model.** Wanneer een modelaanroep mislukt door overbelasting, een rate limit, een serverfout, een time-out of een antwoord dat halverwege de stream afbreekt, probeert de agent het maximaal drie keer opnieuw. Elke keer wacht hij iets langer (ongeveer 2, 4 en 8 seconden). Fouten die je niet met opnieuw proberen kunt oplossen, zoals een verkeerd opgemaakt verzoek, worden niet opnieuw geprobeerd
- **Vermijdt een host die net is uitgevallen.** Als een model vanaf meerdere hosts kan worden aangeboden, slaat een retry na een hostfout de host over die de fout zojuist veroorzaakte
- **Vat lange gesprekken samen.** Als een gesprek langer wordt dan het model kan lezen, vat de agent oudere geschiedenis samen en probeert hij het nog één keer, in plaats van te stoppen
- **Controleert de modellijst bij elke release.** Bij elke update van Crevio wordt gecontroleerd of elk model waarvan de agent afhankelijk is nog steeds wordt aangeboden. Als een model is verdwenen, wordt de release als mislukt gemarkeerd

![Nieuw taakformulier van Crevio voor een dagelijks Morning sales summary, met instructies om te vermelden welke gegevensbron niet kon worden bereikt, ingesteld op dagelijks herhalen, en Notify via ingesteld op in-appmelding en e-mail](https://crevio.co/vite/assets/crevio-task-failure-notifications-cq6okyoe.png)

**Wat er gebeurt als het toch misgaat:** een mislukte run van een geplande taak wordt gemeld via de kanalen in de instelling **Notify via**, met informatie over wat er wel is uitgevoerd en wat er misging. Een terugkerende taak wordt standaard na drie opeenvolgende mislukte runs automatisch uitgeschakeld en laat het je weten, in plaats van elke ochtend ongemerkt te mislukken. In een livechat stopt een antwoord dat al zijn retries heeft opgebruikt gewoon en stuur je het bericht opnieuw.

**Wat de agent nog niet doet:** de agent van Crevio schakelt niet automatisch midden in een taak over naar een ander model wanneer het hoofdmodel niet beschikbaar is. Op dit moment bestaat de bescherming uit retries en host-failover voor hetzelfde model. Je kunt het model van de agent ook niet kiezen of je eigen provider key koppelen. Als je een zorgvuldig afgestemde fallbackketen over meerdere leveranciers nodig hebt, biedt een routingtool uit de bovenstaande tabel die controle binnen je eigen stack.

[Crevio](https://crevio.co/) kun je gratis gebruiken. Het Starter-abonnement bevat 20 AI-credits per maand.

## Veelgestelde vragen

### Heb ik een back-upmodel nodig als ik al een AI-gateway gebruik?

De gateway is de plek waar je de back-up configureert, maar is niet zelf een back-up. Sommige gateways proberen zelfstandig opnieuw of schakelen tussen hosts voor hetzelfde model, maar een modelfallback vindt alleen plaats als je een ander model opgeeft. Ze voegen bovendien een eigen afhankelijkheid toe. Controleer dus hoe je gateway zich bij eerdere incidenten heeft gedragen.

### Moet een back-upmodel voor een AI-agent van een andere provider komen?

Bij storingen: ja. Een back-up van dezelfde provider valt vaak uit tijdens hetzelfde incident. Voor rate limits kan een tweede model van dezelfde provider voldoende zijn, omdat limieten meestal per model worden ingesteld. De afweging is compatibiliteit: hoe verder de back-up van je primaire model af staat, hoe uitgebreider je prompts, tool calls en parameters moet testen.

### Hoe vaak moet ik mijn LLM-fallback testen?

Voer na elke wijziging aan het primaire model, de back-up of de instructies en tools van je agent een oefening uit. Doe dit anders minimaal één keer per kwartaal. Controleer ook telkens de uitfaseringsdata van beide modellen, want een back-up die is uitgefaseerd, faalt precies wanneer je hem nodig hebt.

## Een back-up die je nooit hebt uitgevoerd, is een gok

Storingen, rate limits en uitfaseringen zijn inmiddels alledaagse gebeurtenissen. Een goed back-upmodel voor een AI-agent verandert een gemist ochtendrapport in een rapport dat iets later komt. De waarde zit echter in de volgorde waarin je de maatregelen toepast: eerst opnieuw proberen, dan een andere host en daarna een ander model — en alleen met een back-up waarvan je al hebt gezien dat deze echt werk afrondt. Als je de back-up niet hebt getest, heb je geen fallback. Je hebt alleen een tweede ding dat kan mislukken.

## Gerelateerde blogposts

- [Kosten van AI-agents: wat kost één agent echt per maand?](/nl/blog/ai-agent-running-costs)
- [Zo plan je terugkerende AI-agenttaken die zonder jou worden uitgevoerd](/nl/blog/schedule-recurring-ai-agent-tasks)
- [AI-agents met human-in-the-loop: wat keur je goed en wat laat je automatisch uitvoeren?](/nl/blog/human-in-the-loop-ai-agents)
- [AI-agents voor bedrijven: wat implementeer je eerst, per afdeling](/nl/blog/ai-agents-for-business)