İstemciniz yeniden denerken erişilebilirlik ne demek

İki rakam, aynı yirmi üç model üzerinde aynı öğleden sonra ölçüldü, 2026-08-31. İlk denemelerin yüzde yetmiş beşi cevapla döndü. Üç deneme içinde yüzde doksan üçü döndü. İkisi de doğru ve yalnızca birini yayınlayan bir durum sayfası, bir yönde ya da diğerinde yanıltıcıdır.

Hangisinin kullanıcılarınızı anlattığı, muhtemelen hiç değiştirmediğiniz bir varsayılana bağlı.

SDK’nız zaten yeniden deniyor

Resmi OpenAI ve Anthropic istemci kütüphaneleri başarısız istekleri otomatik olarak yeniden dener. İkisi de varsayılan olarak iki yeniden deneme — toplam üç deneme — ile gelir, üstel geri çekilmeyle, ve ikisi de bunu bağlantı hatalarına, 408, 409, 429 ve 5xx yanıtlarına uygular.

Ayarı her kütüphanenin kendi dokümanında görebilirsiniz: OpenAI Python SDK ve Anthropic Python SDK, ikisi de max_retries sunar ve ikisi de varsayılanı 2 yapar. Karşılık gelen Node kütüphaneleri de aynısını yapar.

Neredeyse kimse bunu değiştirmez. Yani bu API’ler üzerine kurulmuş neredeyse her uygulama için, reddedilen tek bir istek kullanıcının gördüğü bir hata değildir — bir yeniden deneme, kısa bir bekleme ve bir cevaptır. Başarısızlık sağlayıcının loglarında vardır, müşterinin deneyiminde hiçbir yerde yoktur.

Aradaki fark gerçekte neydi

2026-08-31’de, platform gerçek trafik altında yük atarken, kataloğun tamamında ölçüldü:

On sekiz puan. Reddetmeler ezici çoğunlukla aşırı yük mesajı taşıyan 503’lerdi, yarım saniyenin altında geliyordu ve bir sonraki denemede geçiyordu. Elle izlediğimiz bir vaka: bir model 503 döndürdü, iki saniye sonra aynı istek 200 döndürdü.

Yalnızca %75’i yayınlarsanız, müşterilere servisin dört çağrıdan birinde başarısız olduğunu söylemiş olursunuz; standart bir istemci kullanan hiç kimse bunu tanımaz. Yalnızca %93’ü yayınlarsanız yük atmayı sessizce yok saymış olursunuz. O yüzden ikisini de yan yana yayınlayın ve etiketleyin: platformun ilk temasta yaptığı, ve doğru kurulmuş bir istemcinin elde ettiği.

Neyi yeniden denemeli, neyi asla

Yeniden denemek yargıdan bağımsız değildir. Önemli olan ayrım, koşulun geçip geçemeyeceğidir.

O tablonun ikinci yarısı, insanların yanlış yaptığı yarıdır ve yanlış yapmak hiç denememekten kötüdür. Bir 401’i üç kez denemek, müşterinin kendi yazım hatasını üç saniyelik görünür kararsızlığa çevirir ve müşteri bunu sizin servisinizin dengesizliği olarak raporlar. 404 için de aynısı geçerli: OpenAI uyumlu bir uçta bu çok sık, base URL’de bir yol parçası fazla olması demektir — yeniden denemelerin ancak gizleyebileceği bir yapılandırma hatası.

Geçici görünüp olmayan bir tane daha: askıda kalan istek. Bağlantıyı zaman aşımınız dolana kadar açık tutan bir model, yeniden denemede genellikle tam olarak aynısını yapar. Askıda kalan bir uca üç deneme, üç zaman aşımı demektir — saniyeler değil, dakikalar — ve sonunda ilk denemeden sonra bilmediğiniz hiçbir şeyi bilmezsiniz.

Yeniden denemek saklamakla aynı şey değildir

Bu argümanın bir mazerete dönüşen bir versiyonu var ve adını koymaya değer. Bir platform dört çağrıdan birini reddediyorsa ve siz yalnızca yeniden denemeli rakamı raporluyorsanız, gerçek bir tekniği gerçek bir sorunu gömmek için kullanmış olursunuz. Yeniden deneme başarılı olsa bile reddetmeler kullanıcılarınıza gecikme olarak yansır, ve oran yükselirse yeniden denemeler onu örtmeyi bırakır.

Tekniği dürüst tutan üç alışkanlık:

1. 01Her örnekte iki sonucu da kaydedin. Biri diğerinden türetilmiş değil — ilk deneme sonucu ve nihai sonuç, ayrı saklanmalı ki sonradan hiçbiri geri hesaplanıp yok edilemesin.
2. 02Yeniden denemenin gerektiğini söyleyin. Üçüncü denemede cevap veren bir API deneme alanı bunu belirtmeli. “Çalıştı” ile “sonunda çalıştı” bir servis hakkında farklı olgulardır.
3. 03Sınırlayın. Üç deneme SDK varsayılanıdır ve dolayısıyla dürüst tavandır. On kez deneyen bir sonda kendi ısrarını ölçüyordur.

Sayma kuralı buradan çıkar: sondanızın tetiklediği bir reddetme veri noktası değildir, müşterinin de karşılaşacağı bir reddetme ise veridir. Monitörünüz hiçbir müşterinin göndermediği trafiği gönderiyorsa ikisini ayıramazsınız — ki bu farklı bir başarısızlık, kendini ölçen sondalar hakkındaki yazıda ele alınıyor.

Müşterilere ne söylemeli

Model erişimi satıyor veya aktarıyorsanız, kullanıcılarınıza vereceğiniz pratik tavsiye kısa:

• Resmi SDK’yı kullanın ve max_retries’a dokunmayın. Doğru geri çekilmeyi ve doğru sınıflandırmayı bedavaya alırsınız.
• Ham curl veya fetch ile çağırıyorsanız hiç yeniden denemeniz yok demektir. Yalnızca bağlantı hataları ve 5xx için, kabaca bir ve iki saniyelik geri çekilmeyle iki deneme ekleyin.
• İstemci zaman aşımını modelin kuyruğunun epey üstüne alın. Bazı modeller akışta iki saniyede, akışsız otuz saniyede cevap verir — kısa bir zaman aşımı bunu yeniden denemelerin düzeltemeyeceği bir hataya çevirir.
• 429 dışında hiçbir 4xx’i yeniden denemeyin. Bir istek hatalıysa üç kez de hatalıdır.

Ve herhangi bir sağlayıcının durum sayfasında bakılacak rakam, diğerinin yanında göstermeye razı oldukları rakamdır. Kaç denemeye izin verdiğini belirtmeyen tek bir erişilebilirlik rakamı hiçbir şeyle karşılaştırılabilir değildir.

Devamı

• AI API relay’leri, açıklandı — yeniden denemelerin, yönlendirmenin ve hız sınırlarının gerçekte gerçekleştiği katman.
• Sondanız arızanın kendisi olduğunda — bir monitörün kendini ölçmesinin üç yolu ve kendi yükünüzü onların arızasından ayıran tek test.
• “OpenAI uyumlu” gerçekte ne demek — yukarıdaki 404’lerin çoğunun arkasındaki base URL hatası dahil.

İki rakamımız da durum sayfasında: manşet rakam yeniden denemelere izin veriyor, çünkü istemciniz de veriyor; ilk deneme rakamı da ikisi ayrıştığı her yerde onun yanında duruyor.