CometAPI-fejl 401, 404, 429 og 5xx: Skal der forsøges igen eller opgives?

Kort svar: lad være med at skifte fra Claude til GPT for hver mislykket forespørgsel. En 401 betyder, at autentificeringen skal rettes, og en sti-relateret 404 betyder, at URL eller endpoint skal korrigeres. En 429 eller midlertidig 5xx kan prøves igen med backoff; hvis begrænsede genforsøg stadig fejler, kan en kompatibel fallback-model tage over.

Der er én vigtig undtagelse: et 500-svar med error.code: invalid_request er stadig et anmodningsproblem. At forsøge igen—eller sende den samme defekte payload til en anden model—skjuler blot fejlen.

Denne artikel blev verificeret den 20. august 2026 mod CometAPI's dokumentation om fejl, retry, base-URL, rate limits og model-fallback. Den dækker kun fejlkategorisering. For rutedesign, udbyderoplysninger og flerlagede failover-løsninger, brug den komplette model-fallback-vejledning og den tekniske fallback-guide.

Start med beslutningen: genforsøg eller fejle

Det praktiske spørgsmål er ikke "Fejlede Claude?". Det er "Kunne en anden model lykkes uden at ændre den ugyldige del af denne anmodning?". Autentificerings- og stifejl påvirker selve forbindelsen, så det løser dem ikke at skifte model. Midlertidige kapacitets- og serverfejl kan være rutespecifikke, så en fallback kan hjælpe.

Læs fejlen, før du skifter modeller

Brug HTTP-status sammen med error.code og error.message. Mange CometAPI-fejl bruger en konvolut som denne:

{
  "error": {
    "message": "human-readable detail and request id",
    "type": "comet_api_error",
    "param": "problematic_parameter_or_empty",
    "code": "error_code_or_empty"
  }
}

Klassificér ikke kun efter første ciffer i statuskoden. En 500 kan stadig indeholde invalid_request, mens en forkert CometAPI-sti kan returnere en redirect eller HTML i stedet for en ren JSON-404.

401 Unauthorized: Stop og ret autentificeringen

En 401 betyder typisk, at API-nøglen mangler, er forkert formateret, udløbet eller indlæst fra det forkerte miljø. Headeren skal være:

Authorization: Bearer $COMETAPI_KEY

Forsøg ikke igen og skift ikke modeller. Begge ruter bruger den samme defekte autentificering. Tjek om den deployede tjeneste indlæste en gammel hemmelighed, om der blev tilføjet blanktegn til nøglen, og om anmodningen rammer det tilsigtede miljø. Rotér eller genindlæs nøglen kun gennem jeres secret management-proces.

404 Not Found: Ret URL'en før fallback

For OpenAI-kompatible anmodninger skal du bruge denne base-URL præcist:

https://api.cometapi.com/v1

En manglende /v1, et duplikeret path-segment eller et forkert endpoint kan give 404, en redirect, et HTML-svar eller en SDK-parsningsfejl. Deaktiver automatisk følge af redirects under fejlsøgning og bekræft den endelige anmodningssti mod API-referencen.

Hvis svaret udtrykkeligt siger, at en model er utilgængelig eller ikke fundet, så verificér model-ID'et i den aktuelle CometAPI Models API. Behandl ikke enhver 404 som model-utilgængelighed. Tilføj kun en model-specifik fallback efter du har opfanget og testet netop det signal.

429 Too Many Requests: Backoff før failover

En 429 kan prøves igen. Brug eksponentiel backoff med jitter, sænk burst-samtidighed, og mål hvilken rute der mættes. Et øjeblikkeligt genforsøg fra hver worker kan forvandle en kortvarig rate limit til en større trafikspids.

Efter et lille, begrænset antal genforsøg kan fallback være passende, når den næste model understøtter samme input, outputkontrakt og påkrævede kapaciteter. Fallback er ikke gratis: den tilføjer latenstid og kan ændre omkostninger eller adfærd, så registrér hvor ofte den bruges.

5xx-fejl: Tjek koden, forsøg derefter igen

500, 503, 504 og 524 repræsenterer ofte platform-, udbyder- eller timeout-lignende fejl. Bevar request-ID, endpoint, model og tidsstempel, og forsøg derefter igen med backoff. Hvis den samme midlertidige fejl overlever genforsøgene, gå videre til den næste kompatible rute.

Men inspicér først body. Når en 500 indeholder error.code: invalid_request eller invalid_request_error, skal anmodningskroppen rettes, og der må først forsøges igen efter den er ændret. Almindelige årsager omfatter et manglende messages-felt eller en udbyderspecifik parameter, som det valgte endpoint ikke accepterer.

Brug én lille politik i koden

Dette Python-eksempel holder genforsøg og fallback i applikationen. Det bruger én CometAPI-nøgle, den OpenAI-kompatible base-URL og miljøvariabler til de aktuelle Claude- og GPT-model-ID'er. Det forsøger kun igen ved midlertidige fejl og skifter først model, når genforsøgsbudgettet er opbrugt.

import os, random, time
from openai import APIError, OpenAI

client = OpenAI(
    api_key=os.environ["COMETAPI_KEY"],
    base_url="https://api.cometapi.com/v1",
    max_retries=0,
)
MODELS = [os.environ["CLAUDE_MODEL"], os.environ["GPT_MODEL"]]
RETRYABLE = {429, 500, 503, 504, 524}

def complete(messages):
    for model in MODELS:
        for attempt in range(3):
            try:
                response = client.chat.completions.create(model=model, messages=messages)
                return response.choices[0].message.content
            except APIError as error:
                status = getattr(error, "status_code", None)
                code = getattr(error, "code", None)
                if status in {401, 404} or code in {
                    "invalid_request", "invalid_request_error"
                }:
                    raise
                if status not in RETRYABLE:
                    raise
                if attempt < 2:
                    time.sleep(2**attempt + random.random())
                    continue
                break
    raise RuntimeError("No configured route completed.")

print(complete([{"role": "user", "content": "Summarize this ticket."}]))

SDK'ets automatiske genforsøg er deaktiveret, så applikationen ejer det samlede genforsøgs- og fallbackbudget. Uden den kontrol kan SDK-genforsøg plus applikationsgenforsøg multiplicere kald og forsinke det endelige svar.

Test politikken uden gætteri

Dette er policy-tests, ikke påstande om live-udbyderes pålidelighed. I staging injicer status og fejlbody i klassifikatoren, verificér antallet og rækkefølgen af kald, og bekræft at din endelige fejl stadig inkluderer den originale anmodningskontekst.

Når Claude-til-GPT-fallback faktisk er sikker

At skifte modelfamilie er kun sikkert, når begge ruter kan opfylde den samme applikationskontrakt. Normalisér anmodnings- og svarfelter, test struktureret output eller værktøjsadfærd på begge modeller, og verificér enhver krævet billed-, dokument-, kontekst- eller ræsonnementskapacitet, før ruten aktiveres.

Fallback skal også respektere sideeffekter. Hvis den første rute allerede har trigget et værktøj, skrevet data eller streamet et delvist svar, kan en blind gentagelse af hele anmodningen duplikere handlinger eller forvirre brugeren. Genoptag fra et checkpoint eller returnér i stedet en kontrolleret fejl.

Produktionskontroller, der holder genforsøg begrænsede

• Indstil ét samlet latenstidsbudget. Tæl hvert genforsøg og hver fallback mod den samme deadline.
• Begræns genforsøg. Brug backoff med jitter og stop efter en lille, konfigureret grænse.
• Kontroller samtidighed. Reducér bursts, før anmodninger forlader applikationen.
• Tilføj en circuit breaker. Stop midlertidigt med at kalde en gentagne gange fejllende rute.
• Log beslutninger. Fang status, fejlkode, request-ID, model, forsøg, delay og fallback-årsag uden at gemme hemmeligheder.
• Spor fallback-rate. En vedvarende stigning er et driftsignal, ikke en normal succesmetrik.

Ofte stillede spørgsmål

Skal en 401 nogensinde udløse en modelfallback?

Nej. Ret eller genindlæs API-nøglen. En anden model, der kaldes via samme ugyldige legitimationsoplysninger, vil fejle af samme grund.

Skal en 404 udløse fallback?

Ikke som standard. Ret først base-URL eller endpoint. Kun et separat verificeret signal om model-utilgængelighed bør gå ind i fallback-klassifikatoren.

Hvor mange gange bør jeg genforsøge en 429?

Brug en lille applikationsdefineret grænse, der passer til det brugerorienterede latenstidsbudget. Backoff med jitter og reducer samtidighed; genforsøg ikke øjeblikkeligt eller uendeligt.

Er alle 5xx-fejl genforsøgsbare?

Nej. Midlertidige 500, 503, 504 og 524-svar er kandidater til genforsøg, men 500 med invalid_request bør hard-faile, indtil payloaden er rettet.

Kan Claude og GPT bruge den samme anmodning uændret?

Kun for de fælles felter, din applikation har testet. Udbyderspecifikke parametre, værktøjsformater, strukturerede outputs og multimodale input kan kræve adaptere. En ændring af model-ID alene beviser ikke kompatibilitet.

Hvor findes den fulde fallback-implementering?

Se How to Build Robust LLM Model Fallback Strategies for den bredere arkitektur og CometAPI model fallback guide for implementeringsdetaljer.

Gør fejlkklassifikatoren til portvagt

Automatisk fallback er nyttigt, når det er snævert og observerbart. Lad autentificerings-, sti- og fejlformede anmodninger fejle højlydt. Genforsøg rate limits og midlertidige serverfejl med backoff, og skift derefter til en kompatibel rute først efter at genforsøgsbudgettet er brugt. Den politik gør fallback til en pålidelighedskontrol i stedet for en måde at skjule konfigurationsfejl på.

Kilder

• CometAPI-fejlkoder og håndtering
• CometAPI-fejl og retry-strategi
• CometAPI rate limits og samtidighed
• CometAPI base-URL-guide
• CometAPI model- og udbyder-fallback-guide
• CometAPI komplet model-fallback-vejledning