CometAPI 401, 404, 429 ve 5xx Hataları: Yeniden dene mi, yoksa başarısız mı olsun?

Kısa yanıt: Her başarısız istekte Claude’dan GPT’ye geçmeyin. 401, kimlik doğrulamanın düzeltilmesi gerektiğini; yol ile ilgili bir 404, URL veya endpoint’in düzeltilmesi gerektiğini gösterir. 429 veya geçici 5xx artan bekleme (backoff) ile yeniden denenebilir; sınırlı yeniden denemeler yine de başarısız olursa, uyumlu bir yedek model devreye girebilir.

Önemli bir istisna var: error.code: invalid_request içeren bir 500 yanıtı hâlâ istekle ilgili bir problemdir. Bunu yeniden denemek—ya da aynı bozuk payload’ı başka bir modele göndermek—yalnızca hatayı gizler.

Bu makale 20 Ağustos 2026 tarihinde CometAPI’nin hata, yeniden deneme, temel URL, oran sınırı ve model yedekleme dokümantasyonuna karşı doğrulanmıştır. Yalnızca hata sınıflandırmasını kapsar. Rota tasarımı, sağlayıcı kimlik bilgileri ve çok katmanlı failover için kapsamlı model yedekleme öğreticisini ve teknik yedekleme kılavuzunu kullanın.

Yeniden Dene mi Yoksa Hemen Hata mı Kararıyla Başlayın

Pratik soru “Claude başarısız oldu mu?” değil, “Bu isteğin hatalı kısmını değiştirmeden farklı bir model başarılı olabilir mi?” olmalıdır. Kimlik doğrulama ve yol hataları bağlantının kendisini etkiler; modeli değiştirmek bunu çözmez. Geçici kapasite ve sunucu hataları rota bazlı olabilir; bu yüzden yedek bir rota yardımcı olabilir.

Modelleri Değiştirmeden Önce Hata Mesajını Okuyun

HTTP durumunu error.code ve error.message ile birlikte kullanın. Birçok CometAPI hatası şu zarfı kullanır:

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

Durum kodunun yalnızca ilk basamağına göre sınıflandırma yapmayın. Bir 500 yine de invalid_request taşıyabilir; yanlış bir CometAPI yolu temiz bir JSON 404 yerine yönlendirme ya da HTML döndürebilir.

401 Unauthorized: Durdurun ve Kimlik Doğrulamayı Düzeltin

Bir 401, API anahtarının eksik, hatalı biçimlendirilmiş, süresi dolmuş veya yanlış ortamdan yüklendiği anlamına gelir. Başlık şu şekilde olmalıdır:

Authorization: Bearer $COMETAPI_KEY

Yeniden denemeyin ve modellere geçmeyin. Her iki rota da aynı bozuk kimlik doğrulamayı kullanır. Dağıtılmış hizmetin eski bir sırrı yükleyip yüklemediğini, anahtara boşluk eklenip eklenmediğini ve isteğin hedef ortamına ulaşıp ulaşmadığını kontrol edin. Anahtarı yalnızca sır yönetimi süreciniz üzerinden döndürün veya yeniden yükleyin.

404 Not Found: Yedek Geçişten Önce URL’yi Düzeltin

OpenAI uyumlu istekler için bu temel URL’yi aynen kullanın:

https://api.cometapi.com/v1

Eksik /v1, yinelenen bir yol segmenti veya yanlış endpoint 404, bir yönlendirme, bir HTML yanıtı ya da bir SDK ayrıştırma hatası üretebilir. Hata ayıklarken otomatik yönlendirme takibini devre dışı bırakın ve son istek yolunu API referansıyla doğrulayın.

Yanıt açıkça bir modelin kullanılamadığını veya bulunamadığını söylüyorsa, güncel CometAPI Models API içinde model kimliğini doğrulayın. Her 404’ü model kullanılamazlığı olarak sınıflandırmayın. Yalnızca bu sinyali yakalayıp test ettikten sonra model özelinde yedekleme ekleyin.

429 Too Many Requests: Başarısız Olmadan Önce Geri Çekin

Bir 429 yeniden denenebilir. Jitter ile artan bekleme kullanın, patlama anındaki eşzamanlılığı düşürün ve hangi rotanın doygunlaştığını ölçün. Her işleyiciden anında yeniden deneme kısa bir oran sınırını daha büyük bir trafik dalgasına çevirebilir.

Küçük ve sınırlı sayıda denemeden sonra, bir sonraki model aynı girdi/çıktı sözleşmesini ve gerekli yetenekleri destekliyorsa yedek geçiş uygun olabilir. Yedek geçiş bedavadır demeyin: gecikme ekler ve maliyet ya da davranışı değiştirebilir, bu yüzden ne sıklıkla kullanıldığını kaydedin.

5xx Hataları: Kodu Kontrol Edin, Sonra Yeniden Deneyin

500, 503, 504 ve 524 genellikle platform, sağlayıcı veya zaman aşımı sınıfı hatalarıdır. İstek kimliğini, endpoint’i, modeli ve zaman damgasını saklayın, ardından artan bekleme ile yeniden deneyin. Aynı geçici hata yeniden deneme bütçesini tüketiyorsa, bir sonraki uyumlu rotaya geçin.

Ancak önce gövdeyi inceleyin. Bir 500, error.code: invalid_request veya invalid_request_error içeriyorsa, istek gövdesini düzeltin ve yalnızca değişiklikten sonra yeniden deneyin. Yaygın nedenler arasında eksik messages alanı veya seçilen endpoint’in kabul etmediği sağlayıcıya özel bir parametre yer alır.

Kodda Tek, Küçük Bir Politika Kullanın

Bu Python örneği yeniden denemeleri ve yedek geçişi uygulama içinde tutar. Tek bir CometAPI anahtarı, OpenAI uyumlu temel URL ve geçerli Claude ile GPT model kimlikleri için ortam değişkenleri kullanır. Yalnızca geçici hataları yeniden dener, sonra yeniden deneme bütçesi tükendiğinde modeli değiştirir.

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’nin otomatik yeniden denemeleri devre dışı bırakılmıştır; böylece uygulama toplam yeniden deneme ve yedek geçiş bütçesine sahip olur. Bu kontrol olmadan, SDK yeniden denemeleri ile uygulama yeniden denemeleri çağrıların sayısını katlayabilir ve nihai yanıtı geciktirebilir.

Politikayı Tahmin Etmeden Test Edin

Bunlar politika testleridir; canlı sağlayıcı güvenilirliği hakkında iddia değildir. Staging ortamında, durumu ve hata gövdesini sınıflandırıcıya enjekte edin, çağrıların sayı ve sırasını doğrulayın ve nihai hatanızın hâlâ özgün istek bağlamını içerdiğini onaylayın.

Claude’dan GPT’ye Yedek Geçiş Ne Zaman Gerçekten Güvenlidir

Model aileleri arasında geçiş yalnızca her iki rotanın da aynı uygulama sözleşmesini karşılayabildiğinde güvenlidir. İstek ve yanıt alanlarını normalize edin, her iki modelde yapılandırılmış çıktı veya araç davranışını test edin ve gerekli görüntü, belge, bağlam veya akıl yürütme yeteneklerini doğruladıktan sonra rotayı etkinleştirin.

Yedek geçiş yan etkileri de gözetmelidir. İlk rota bir aracı tetiklediyse, veri yazdıysa veya kısmi bir yanıt akıttıysa, isteği körü körüne tekrarlamak eylemleri çoğaltabilir veya kullanıcıyı şaşırtabilir. Bir kontrol noktasından devam edin veya kontrollü bir hata döndürün.

Üretimde Yeniden Denemeleri Sınırlı Tutan Kontroller

• Tek bir toplam gecikme bütçesi belirleyin. Tüm yeniden deneme ve yedek geçiş denemelerini aynı son teslim süresine sayın.
• Yeniden denemeleri sınırlayın. Jitter ile artan bekleme kullanın ve küçük, yapılandırılmış bir sınırdan sonra durun.
• Eşzamanlılığı kontrol edin. İstekler uygulamadan çıkmadan önce ani patlamaları azaltın.
• Bir devre kesici ekleyin. Sürekli başarısız olan bir rotayı geçici olarak durdurun.
• Kararları kaydedin. Durum, hata kodu, istek kimliği, model, deneme, gecikme ve yedekleme gerekçesini gizli bilgileri saklamadan yakalayın.
• Yedek geçiş oranını izleyin. Sürekli artış operasyonel bir sinyaldir, normal bir başarı metriği değildir.

Sıkça Sorulan Sorular

401 bir model yedeklemesini tetiklemeli mi?

Hayır. API anahtarını düzeltin veya yeniden yükleyin. Aynı geçersiz kimlikle çağrılan farklı bir model aynı nedenle başarısız olur.

404 yedek geçişi tetiklemeli mi?

Varsayılan olarak hayır. Önce temel URL’yi veya endpoint’i düzeltin. Yalnızca ayrı olarak doğrulanmış model-kullanılamaz sinyali yedekleme sınıflandırıcısına girmelidir.

429’u kaç kez yeniden denemeliyim?

Kullanıcıya dönük gecikme bütçesine uyan küçük, uygulama tanımlı bir sınır kullanın. Jitter ile artan bekleme yapın ve eşzamanlılığı azaltın; hemen veya süresiz yeniden denemeyin.

Tüm 5xx hataları yeniden denenebilir mi?

Hayır. Geçici 500, 503, 504 ve 524 yanıtları yeniden deneme adaylarıdır, ancak invalid_request içeren 500 yük düzeltilene kadar sert şekilde başarısız olmalıdır.

Claude ve GPT aynı isteği değişmeden kullanabilir mi?

Yalnızca uygulamanızın test ettiği ortak alanlar için. Sağlayıcıya özel parametreler, araç formatları, yapılandırılmış çıktılar ve çoklu ortam girdileri adaptör gerektirebilir. Yalnızca model kimliğini değiştirmek uyumluluk kanıtı değildir.

Tam yedekleme uygulaması nerede?

Daha geniş mimari için Nasıl Sağlam LLM Model Yedekleme Stratejileri Kurulur ve uygulama ayrıntıları için CometAPI model yedekleme kılavuzu bölümüne bakın.

Hata Sınıflandırıcısını Kapı Bekçisi Yapın

Otomatik yedekleme, dar ve gözlemlenebilir olduğunda faydalıdır. Kimlik doğrulama, yol ve hatalı istek hatalarının yüksek sesle başarısız olmasına izin verin. Oran sınırlarını ve geçici sunucu hatalarını artan bekleme ile yeniden deneyin, ardından yeniden deneme bütçesi tükendiğinde yalnızca uyumlu bir rotaya geçin. Bu politika, yedek geçişi yapılandırma hatalarını gizleyen bir araç yerine bir güvenilirlik kontrolüne dönüştürür.

Kaynaklar

• CometAPI hata kodları ve işleme
• CometAPI hata ve yeniden deneme stratejisi
• CometAPI oran sınırları ve eşzamanlılık
• CometAPI temel URL kılavuzu
• CometAPI model ve sağlayıcı yedekleme kılavuzu
• CometAPI kapsamlı model yedekleme öğreticisi