CometAPI 401, 404, 429 og 5xx-feil: Prøv på nytt eller feile?

Kort svar: ikke bytt fra Claude til GPT for hver mislykket forespørsel. En 401 betyr at autentiseringen må fikses, og en bane-relatert 404 betyr at URL eller endepunkt må korrigeres. En 429 eller midlertidig 5xx kan prøves på nytt med backoff; hvis et begrenset antall forsøk fortsatt feiler, kan en kompatibel fallback‑modell ta over.

Det finnes ett viktig unntak: en 500‑respons med error.code: invalid_request er fortsatt et forespørselsproblem. Å prøve på nytt—eller å sende samme ødelagte nyttelast til en annen modell—skjuler bare feilen.

Denne artikkelen ble verifisert 20. august 2026 mot CometAPIs dokumentasjon for feil, retry, base‑URL, rate limit og modell‑fallback. Den dekker kun feilkategorisering. For rutedesign, leverandørlegitimasjon og flerlagets failover, bruk complete model fallback tutorial og technical fallback guide.

Start med beslutningen om å prøve på nytt eller feile

Det praktiske spørsmålet er ikke «Feilet Claude?» Det er «Kunne en annen modell lykkes uten å endre den ugyldige delen av denne forespørselen?» Autentiserings- og bane‑feil påvirker selve forbindelsen, så å bytte modell kan ikke løse dem. Midlertidig kapasitets- og serverfeil kan være rutespesifikke, så en fallback kan hjelpe.

Les feilen før du bytter modell

Bruk HTTP‑status sammen med error.code og error.message. Mange CometAPI‑feil bruker et omslag som dette:

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

Ikke klassifiser kun etter første siffer i statuskoden. En 500 kan fortsatt inneholde invalid_request, mens en feil CometAPI‑sti kan returnere en redirect eller HTML i stedet for en ren JSON‑404.

401 Uautorisert: Stopp og fiks autentiseringen

En 401 betyr vanligvis at API‑nøkkelen mangler, er feil formatert, utløpt, eller lastet fra feil miljø. Headeren må være:

Authorization: Bearer $COMETAPI_KEY

Ikke prøv på nytt og ikke bytt modeller. Begge rutene bruker den samme ødelagte autentiseringen. Sjekk om den deployede tjenesten lastet en gammel hemmelighet, om det ble lagt til whitespace i nøkkelen, og om forespørselen når riktig miljø. Roter eller last inn nøkkelen på nytt kun via prosessen for hemmelighetshåndtering.

404 Ikke funnet: Fiks URL‑en før fallback

For OpenAI‑kompatible forespørsler, bruk denne base‑URL‑en nøyaktig:

https://api.cometapi.com/v1

En manglende /v1, et duplisert baneelement, eller feil endepunkt kan gi 404, en redirect, en HTML‑respons eller en SDK‑parsefeil. Deaktiver automatisk redirect‑følging under feilsøking og bekreft den endelige forespørselsbanen mot API‑referansen.

Hvis responsen eksplisitt sier at en modell er utilgjengelig eller ikke funnet, verifiser modell‑ID i gjeldende CometAPI Models API. Ikke behandl hver 404 som modellutilgjengelighet. Legg kun til en modellspesifikk fallback etter at du har fanget og testet akkurat det signalet.

429 Too Many Requests: Backoff før failover

En 429 kan prøves på nytt. Bruk eksponentiell backoff med jitter, senk burst‑samtidigheten, og mål hvilken rute som mettes. Et umiddelbart nytt forsøk fra hver worker kan gjøre en kort rate limit til en større trafikktopp.

Etter et lite, begrenset antall forsøk kan fallback være riktig når neste modell støtter samme input, output‑kontrakt og nødvendige kapabiliteter. Fallback er ikke gratis: den øker latens og kan endre kostnad eller oppførsel, så registrer hvor ofte den brukes.

5xx‑feil: Sjekk koden, prøv deretter på nytt

500, 503, 504 og 524 representerer ofte plattform‑, leverandør‑ eller timeout‑klassefeil. Behold request‑ID, endepunkt, modell og tidsstempel, og prøv deretter på nytt med backoff. Hvis samme forbigående feil overlever forsøkbudsjetttet, gå videre til neste kompatible rute.

Men inspiser kroppen først. Når en 500 inneholder error.code: invalid_request eller invalid_request_error, fiks forespørselens body og prøv på nytt bare etter at den er endret. Vanlige årsaker inkluderer et manglende messages‑felt eller en leverandørspesifikk parameter som valgt endepunkt ikke aksepterer.

Bruk én liten policy i kode

Dette Python‑eksemplet holder retries og fallback i applikasjonen. Det bruker én CometAPI‑nøkkel, den OpenAI‑kompatible base‑URL‑en og miljøvariabler for gjeldende Claude‑ og GPT‑modell‑ID‑er. Det prøver bare på nytt for forbigående feil og bytter deretter modell etter at forsøkbudsjetttet er brukt opp.

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‑ens automatiske retries er deaktivert slik at applikasjonen eier det totale budsjettet for nye forsøk og fallback. Uten den kontrollen kan SDK‑forsøk pluss applikasjonsforsøk multiplisere kallene og forsinke den endelige responsen.

Test policyen uten gjetting

Dette er policytester, ikke påstander om live‑leverandørers pålitelighet. I staging, injiser status og feilkropp i klassifisereren, verifiser antall og rekkefølge på kall, og bekreft at din endelige feil fortsatt inkluderer opprinnelig forespørselskontekst.

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

Å bytte modellslekter er bare trygt når begge rutene kan oppfylle samme applikasjonskontrakt. Normaliser felt i forespørsel og respons, test strukturert output eller verktøyoppførsel på begge modeller, og verifiser eventuelle nødvendige bilde‑, dokument‑, kontekst‑ eller resonneringskapabiliteter før du aktiverer ruten.

Fallback bør også ta hensyn til sideeffekter. Hvis den første ruten allerede trigget et verktøy, skrev data, eller strømmet en delvis respons, kan blind gjentakelse av hele forespørselen duplisere handlinger eller forvirre brukeren. Gjenoppta fra et sjekkpunkt eller returner en kontrollert feil i stedet.

Produksjonskontroller som holder forsøk begrenset

• Sett ett samlet latensbudsjett. Tell hvert forsøk og hver fallback mot samme tidsfrist.
• Begrens antall forsøk. Bruk backoff med jitter og stopp etter en liten, konfigurert grense.
• Kontroller samtidighet. Reduser bursts før forespørsler forlater applikasjonen.
• Legg til en circuit breaker. Stans midlertidig kall til en rute som feiler gjentatte ganger.
• Logg beslutninger. Fang status, feilkode, request‑ID, modell, forsøk, forsinkelse og fallback‑årsak uten å lagre hemmeligheter.
• Spor fallback‑rate. En vedvarende økning er et operasjonelt signal, ikke en normal suksessmåling.

Ofte stilte spørsmål

Skal en 401 noen gang trigge en modell‑fallback?

Nei. Fiks eller last inn API‑nøkkelen på nytt. En annen modell kalt gjennom samme ugyldige legitimasjon vil feile av samme grunn.

Skal en 404 trigge fallback?

Ikke som standard. Fiks først base‑URL eller endepunkt. Bare et separat verifisert signal om at modellen er utilgjengelig bør slippe inn i fallback‑klassifiseringen.

Hvor mange ganger bør jeg prøve på nytt ved 429?

Bruk en liten applikasjonsdefinert grense som passer brukerrettet latensbudsjett. Backoff med jitter og reduser samtidighet; ikke prøv umiddelbart eller på ubestemt tid.

Er alle 5xx‑feil forsøkbare?

Nei. Midlertidige 500, 503, 504 og 524 er kandidater for nye forsøk, men 500 med invalid_request skal hardfeile til nyttelasten er fikset.

Kan Claude og GPT bruke den samme forespørselen uendret?

Bare for de delte feltene applikasjonen din har testet. Leverandørspesifikke parametere, verktøyformater, strukturert output og multimodale input kan kreve adaptere. En ren endring av modell‑ID beviser ikke kompatibilitet.

Hvor finnes den fullstendige fallback‑implementasjonen?

Se How to Build Robust LLM Model Fallback Strategies for den bredere arkitekturen, og CometAPI model fallback guide for implementasjonsdetaljer.

La feilklassifisereren være portvakten

Automatisk fallback er nyttig når den er snever og målbar. La autentiserings‑, bane‑ og feilformatert‑forespørsel‑feil feile tydelig. Prøv rate limits og midlertidige serverfeil på nytt med backoff, og gå deretter til en kompatibel rute først etter at forsøkbudsjetttet er brukt opp. Denne policyen gjør fallback til en pålitelighetskontroll i stedet for en måte å skjule konfigurasjonsfeil.

Kilder

• CometAPI error codes and handling
• CometAPI error and retry strategy
• CometAPI rate limits and concurrency
• CometAPI base URL guide
• CometAPI model and provider fallback guide
• CometAPI complete model fallback tutorial