Claude 529-fejl: når LLM-drift bliver en rigtig afhængighed

Det mest interessante ved nattens Claude-hændelse er ikke, at en AI-tjeneste havde fejl. Det sker. Det interessante er, at fejlen ramte præcis de dele af stakken, som flere udviklingsmiljøer nu behandler som produktionsinfrastruktur: Claude API, Claude Code og Claude Cowork.

Anthropic markerede hændelsen som løst kl. 02:06 UTC den 22. juni 2026. Før det havde statusopdateringerne peget på forhøjede fejlraters for Opus 4.8, Opus 4.7, Opus 4.6, Sonnet 4.6 og Haiku 4.5. Hændelsen påvirkede både claude.ai, API’et, Claude Code og Claude Cowork. På Hacker News dukkede den samme fejltype op i brugerrapporter som 529 Overloaded, altså en server-side belastningsfejl, hvor klienten typisk kun kan vente, forsøge igen eller skifte leverandør.

Det er en lille hændelse. Men den rammer et stort punkt: sprogmodeller er ved at flytte fra værktøj til afhængighed. Hvis din build-proces, kodeassistent, research-agent eller supportrobot antager, at én bestemt model altid svarer, har du ikke en AI-strategi. Du har en single point of failure med flot chatinterface.

529 er ikke bare en irriterende fejlbesked

En 529-fejl fra en LLM-tjeneste er operationelt mere alvorlig end den ser ud. Den betyder ikke nødvendigvis, at din kode er forkert. Den betyder, at leverandørens kapacitet, routing eller modelbackend ikke leverer stabilt nok til dit kald lige nu. For et menneske i en browser er det irriterende. For et automatiseret flow kan det betyde halve pull requests, tabte agentkæder, ufuldstændige kundesvar eller CI-jobs, der fejler uden god grund.

Det er her, mange teams stadig undervurderer LLM-drift. De tester prompts, evaluerer svar og diskuterer modelkvalitet, men de designer ikke for timeout, rate limit, degraded quality, overload og leverandørskift. Det er lidt som at bygge mod en database uden retry-politik, backup eller migrationsplan, fordi demoen virkede på scenen.

Der er også en styringsdimension. Hvis en intern agent må læse kode, skrive filer, oprette tickets eller foreslå merges, skal fejltilstanden være kendt. Skal agenten stoppe? Skal den falde tilbage til en billigere model? Skal den skifte til en anden leverandør? Skal den fortsætte i read-only? Det er ikke noget, man bør overlade til tilfældige exceptions i en wrapper.

Claude Code gør problemet synligt

Claude Code er relevant her, fordi det bringer LLM’en tæt på udviklerens faktiske arbejdskontekst. Det er ikke bare chat om kode. Det er læsning, analyse, ændringer, kommandoer og feedbacksløjfer i et repository. Når en sådan assistent bliver ustabil, mærker man det ikke som et langsomt website. Man mærker det som afbrudt arbejde.

Det passer med det bredere mønster, jeg tidligere har skrevet om i Claude Design gør design systems til LLM-kontrolplan: LLM-produkter bliver kontrolflader oven på rigtige arbejdsgange. Når de rammer design systems, pull requests, dokumentation og kundedata, bliver deres oppetid og governance lige så vigtig som deres benchmarkscore.

Det samme gælder økonomien. I LLM-forbrug bliver nu noget CFO’en kan styre handlede pointen om forbrugskontrol. Men forbrug og drift hænger sammen. Hvis man kun styrer budgettet og ikke styrer fejltilstandene, ender man med et pænt dashboard over en ustabil afhængighed.

Det praktiske svar er kedeligt – og nødvendigt

Der er ikke brug for panik over en kort Claude-hændelse. Der er brug for modenhed. Hvis LLM’er er kritiske i et flow, skal de behandles som enhver anden ekstern produktionsafhængighed.

Definér timeout og retry-politik pr. use case. En kodeagent og en kundevendt chatbot skal ikke nødvendigvis opføre sig ens.
Log modelnavn, latency, fejltype, tokenforbrug og fallback-beslutning. Ellers kan du ikke forklare hændelser bagefter.
Byg en fallback-plan. Det kan være en anden model hos samme leverandør, en anden leverandør eller manuel behandling.
Adskil kritiske handlinger fra kreative forslag. En model, der fejler midt i en analyse, må ikke efterlade sideeffekter uden transaktionsgrænse.
Test degraded mode. Det er ikke nok at teste happy path med varm cache og ledig kapacitet.

Det sidste punkt er det vigtigste. Mange organisationer tester LLM’er, som om leverandørens platform altid er rask. Det er naivt. Nattens hændelse viser, at selv store leverandører med stærke modeller kan have korte, men mærkbare driftsproblemer på tværs af modelklasser og produkter.

For danske udviklere og IT-arkitekter er konklusionen enkel: vælg gerne Claude, OpenAI, Gemini, Mistral eller noget femte. Men design ikke som om valget er en fast naturkonstant. LLM-laget skal have observability, fejlbudget, fallback og klare rettighedsgrænser. Ellers flytter man bare skrøbelighed fra mennesker til automatisering.

Det er måske mindre spændende end endnu en modelnyhed. Til gengæld er det sådan, man undgår at en midlertidig 529-fejl bliver til en intern produktionshændelse.