OpenAI API 429 Hatası: Rate Limit ve insufficient_quota Nasıl Çözülür?

OpenAI API 429 hatası nedir ve hemen ne yapmalısınız?

OpenAI API 429 hatası, sunucunun isteğinizi anlayıp bilerek reddettiği durumdur. İki ayrı kök neden vardır: kısa sürede çok istek ya da token göndermeniz (hız sınırı) veya hesabınızdaki bakiye, harcama limiti ya da kullanım hakkının bitmesi (kota). Önce hata gövdesindeki kodu okuyun.

Panik yapmayın, çünkü 429 çoğu zaman anahtarınızın bozulduğu anlamına gelmez. Kod bir yönlendirme işareti taşır. Hız sınırıysa bekleyip yavaşlayarak geçer. Kota sorunuysa bekleme işe yaramaz, faturalandırma tarafında işlem yapmanız gerekir.

Bu yazıda sahada gördüğümüz teşhis sırasını izliyoruz. Önce en olası nedeni kontrol edin, çünkü en sık sorun orada çıkar. Ardından daha seyrek nedenlere geçin. Yani rastgele ayar değiştirmek yerine sırayla ilerlemek zaman kazandırır.

OpenAI API 429 hatası için hızlı çözüm listesi nedir?

Aşağıdaki sıra, en olası nedenden en az olası nedene doğru gider. Her adımı bitirip sonucu görmeden sonrakine geçmeyin. Böylece hangi değişikliğin işe yaradığını net olarak anlarsınız.

1. Hata gövdesindeki error.code ve error.type alanlarını okuyun. Hız sınırı mı, bakiye mi olduğunu bu alan söyler.
2. Kod bakiye, harcama limiti ya da kullanım limitine işaret ediyorsa faturalandırma ayarlarını açın. Bakiyeyi, aylık harcama limitini ve proje limitini kontrol edin.
3. Hız sınırıysa isteklerin hızını düşürün. Retry-After başlığı varsa en az o kadar bekleyin.
4. Beklemeye küçük bir rastgele süre ekleyin ve deneme sayısına üst sınır koyun.
5. Aynı organizasyondaki diğer uygulamaların ve ekip arkadaşlarının kullanımını kontrol edin. Limit paylaşımlıdır.
6. max_tokens değerini beklediğiniz cevap boyuna yaklaştırın ve istemi kısaltın.
7. Acil olmayan işleri kuyruğa ya da toplu işlemeye taşıyın.
8. Hâlâ düzelmiyorsa kullanım katmanınızı ve limit artırma yollarını resmi sayfadan kontrol edin.

Not: Sınır değerleri modele ve hesaba göre değişir, hatta zamanla güncellenir. Güncel değerleri OpenAI panelindeki limit sayfasından okuyun, bu yazıda rakam vermiyoruz.

OpenAI API 429 hatası neden iki ayrı sorundan gelir?

Aynı durum kodu iki farklı kapıyı kapatır. Birincisi trafik kontrolüdür: sistem, kısa bir zaman diliminde çok yüklendiğinizi söyler. İkincisi hesap kontrolüdür: sistem, kullanabileceğiniz hakkın bittiğini söyler.

Bu ayrım önemlidir, çünkü çözümler zıt yönlere gider. Trafik sorununda yavaşlarsınız ve bir süre sonra aynı istek başarıyla geçer. Hesap sorununda ise ne kadar yavaşlarsanız yavaşlayın istek geçmez.

Örneğin gece yarısı çalışan bir toplu iş birden hız sınırına çarpabilir. Sabah aynı kodu çalıştırdığınızda sorun yoksa neden büyük olasılıkla trafiktir. Buna karşılık sabah da, akşam da aynı hata geliyorsa bakiye ya da harcama limitine bakın.

Resmi hata kodları sayfası bu iki grubu ayrı başlıklar altında anlatır. Bağlantıyı yazının sonundaki kaynaklar bölümünde veriyoruz.

Hız sınırı ile insufficient_quota nasıl ayırt edilir?

Ayırt etmenin en güvenilir yolu yanıt gövdesidir. Hata nesnesinde bir tür ve bir kod alanı bulunur. Resmi sayfaya göre faturalandırma kaynaklı hatalarda tür alanı insufficient_quota olabilir. Bakiye bitince ayrıca credit_balance_exhausted gibi daha özel kodlar da görürsünüz.

Mesaj metinleri zamanla değişebilir. Bu yüzden metnin birebir aynısını aramak yerine kodu kontrol edin. Ekranınızda "benzeri bir uyarı" görüyorsanız yine kodu esas alın.

• Hız sınırı belirtisi: mesaj, isteklerin çok hızlı gönderildiğini söyler ve Retry-After gelebilir.
• Ani artış belirtisi: limitin altında olsanız bile istek oranı çok hızlı yükseldiği için slow_down benzeri bir kod gelebilir.
• Bakiye belirtisi: ön ödemeli kredi bitmiştir, bekleme çözmez.
• Harcama limiti belirtisi: organizasyon ya da proje, kendi koyduğu aylık sınıra ulaşmıştır.
• Kullanım limiti belirtisi: OpenAI tarafından atanan aylık sınıra ulaşmışsınızdır ve yardım ekibiyle iletişime geçmeniz gerekir.

Kısacası kod "kota" ya da "bakiye" diyorsa kodunuzu değil, faturalandırma panelinizi düzeltin.

Hata gövdesi ve yanıt başlıkları ne anlatır?

Yanıt gövdesi nedeni, başlıklar ise zamanlamayı anlatır. OpenAI belgelerine göre yanıtlar, kalan istek ve token hakkını ve sıfırlanmaya kalan süreyi gösteren başlıklar taşıyabilir. Bu başlıkları günlüğe yazmak, sorunu sonradan analiz etmenin en ucuz yoludur.

Retry-After başlığı geçici hatalarda en az ne kadar beklemeniz gerektiğini söyler. Ancak bu başlık, bakiye ya da kota sorununun kendiliğinden düzeleceği anlamına gelmez. Belgeler bunu özellikle vurgular.

Pratikte iki alanı kaydedin: hata kodu ve kalan hak başlıkları. Böylece bir gün "neden 429 aldık?" sorusu geldiğinde tahmin yürütmek yerine kayda bakarsınız.

Ayrıca isteğin hangi model, hangi proje ve hangi anahtarla gittiğini de günlüğe ekleyin. Bu üçlü, hangi uygulamanın sınırı tükettiğini hızla gösterir.

Hız sınırı türleri nelerdir?

Hız sınırı tek bir sayı değildir. Belgelere göre dakikadaki istek sayısı ve dakikadaki token sayısı gibi birden çok ölçü vardır. Bazı modellerde günlük sınırlar, görüntü ya da ses için ayrı sınırlar da bulunabilir.

Hangisine önce çarparsanız o geçerli olur. Örneğin çok sayıda kısa istek gönderen bir uygulama istek sınırına, az sayıda ama devasa metin gönderen bir uygulama token sınırına takılır. Bu yüzden iki ölçüyü ayrı ayrı izlemelisiniz. Panelde modelinize ait limit satırlarını açıp hangi ölçünün sizin için dar boğaz olduğunu not edin. Ardından uygulamanızın günlüğüne her dakika kullanılan istek ve token sayısını yazın. Böylece sınıra yaklaştığınızı çarpmadan önce görürsünüz.

Sınırlar organizasyon ve proje düzeyinde tanımlanır ve modele göre değişir. Bazı modeller ortak bir havuzu paylaşır. Dolayısıyla bir modele yüklenmek, başka bir modelin payını da etkileyebilir.

Token kavramını netleştirmek isterseniz token ve maliyet hesabı rehberimize bakın.

Üstel geri çekilme ve jitter nasıl çalışır?

Üstel geri çekilme (exponential backoff), her başarısız denemeden sonra bekleme süresini katlayarak artırma yöntemidir. Jitter ise bu süreye eklenen küçük rastgele farktır. Amaç, tüm istemcilerin aynı saniyede yeniden denemesini engellemektir.

Benzetme yapalım. Kapıda bekleyen yüz kişi aynı anda içeri girmeye çalışırsa kapı tıkanır. Herkes biraz farklı bir süre bekleyip tek tek girerse akış rahatlar. Rastgele bekleme tam olarak bunu sağlar.

Kavramsal akış şöyledir: ilk hatada kısa bir süre bekleyin, ikinci hatada daha uzun, üçüncüde daha da uzun. Her beklemeye rastgele bir pay ekleyin. Toplam bekleme süresine ve deneme sayısına mutlaka üst sınır koyun.

Başlık varsa önce başlığa uyun. Belgelere göre Retry-After bir alt sınırdır. Yani en az o kadar bekleyin, üstüne küçük bir rastgele süre ekleyin. Başlık yoksa ya da geçersizse geri çekilme formülüne dönün.

Hemen yeniden denemek neden durumu kötüleştirir?

Başarısız istekler de dakikalık sınıra sayılır. OpenAI belgeleri bunu açıkça belirtir. Dolayısıyla 429 alınca anında aynı isteği tekrar göndermek, sınırı daha da hızlı doldurur ve sizi daha uzun süre kilitler.

Bir diğer tuzak iç içe yeniden deneme döngüleridir. SDK kendi içinde yeniden dener, sizin kodunuz da yeniden dener, üstüne bir iş kuyruğu da yeniden dener. Sonuçta tek bir kullanıcı işlemi onlarca isteğe dönüşebilir.

• SDK yeniden denemesini ve kendi yeniden deneme kodunuzu aynı anda açık bırakmayın.
• Yeniden denemeleri sayıca ve toplam süre olarak sınırlandırın.
• Faturalandırma ya da kota kaynaklı hataları yeniden denemeyin, çünkü bunlar beklemekle düzelmez.
• Trafiği ani sıçramalarla değil, kademeli artırarak büyütün.

Sonuç olarak güvenilir bir istemci, kendini yavaşlatmayı bilen istemcidir. Ayrıca bu istemci, sağlayıcının altyapısına da saygı gösterir ve uzun vadede daha az kesinti yaşar. Küçük bir bekleme maliyeti, büyük bir kesintiyi önler.

İstekleri kuyruğa almak ve toplu işlemek nasıl yardımcı olur?

Kuyruk, istekleri bir hız sınırlayıcının arkasına dizmenize izin verir. Uygulamanız istekleri anında göndermek yerine kuyruğa bırakır, bir işçi de bunları kontrollü hızla API'ye iletir. Böylece ani yük sıçramaları sınıra çarpmadan emilir.

Acil olmayan işler için toplu işleme (batch) ayrı bir yoldur. OpenAI belgelerine göre Batch API, anında cevap gerektirmeyen büyük iş kümelerini eşzamanlı istek sınırlarınızı kullanmadan işleyebilir. Toplu işlerin kendi kuyruk sınırı vardır.

Örnek senaryo: bir e-ticaret ekibi gece boyunca binlerce ürün açıklamasını özetletmek istiyor. Bu iş kullanıcıyı bekletmediği için toplu işleme uygundur. Canlı sohbet cevapları ise anlık kalır ve sınırın büyük kısmını rahatça kullanır.

Eğer istek sayısı darboğazsa ama token payınız duruyorsa, birkaç küçük istemi tek istekte birleştirmek de verimi artırabilir. Ancak bunu cevap kalitesini bozmayacak ölçüde yapın.

Önbellek ve prompt caching 429 hatasını azaltır mı?

Kendi tarafınızdaki önbellek doğrudan etkilidir. Aynı soru aynı cevabı üretecekse, ikinci kez API'ye gitmeye gerek yoktur. Sık sorulan sorular, sabit sınıflandırmalar ve değişmeyen özetler önbelleğe uygundur.

Prompt caching ise farklı bir mekanizmadır. Tekrar eden uzun istem öneklerinin işlenmesini hızlandırır ve maliyeti düşürebilir. Bu, hız sınırı sorununu tek başına çözen bir araç değildir. Bunun için sağlayıcının resmi belgesinde, önbelleğe alınmış tokenların limite nasıl sayıldığını kontrol edin.

Mekanizmayı ayrıntılı anlattığımız prompt caching yazımıza göz atın. Orada yapıyı tekrar etmiyoruz, burada yalnızca 429 bağlamını ele alıyoruz.

Kısacası önce gereksiz çağrıyı ortadan kaldırın, sonra kalan çağrıyı ucuzlatın. Bu sıra hem limitinizi hem bütçenizi korur ve kodunuzu da sadeleştirir. Önbellek anahtarını belirlerken kullanıcıya özel verilerin başka kullanıcıya sızmamasına dikkat edin.

Max token ve istem kısaltma neden önemlidir?

Belgelere göre hız sınırı tahmini, max_tokens değerini hesaba katar. Bu değeri gereğinden yüksek bırakırsanız, gerçekte kullanmadığınız token kapasitesi de sayılabilir. Böylece sınıra olması gerekenden önce yaklaşırsınız.

Çözüm basit: beklediğiniz cevap boyuna yakın bir üst sınır verin. Kısa cevap beklediğiniz yerde çok yüksek bir değer bırakmayın.

• Sistem istemini gereksiz tekrarlardan arındırın.
• Sohbet geçmişini her turda baştan göndermek yerine özetleyin.
• Çok uzun belgeleri parçalayıp yalnızca ilgili bölümleri gönderin.
• Gönderdiğiniz metnin uzunluğunu önceden ölçün; kelime ve karakter sayacı kaba bir fikir verir.

Bu adımlar hem 429 riskini hem de faturanızı aynı anda azaltır. Ayrıca cevap sürenizi de kısaltır.

Kullanım katmanı nedir ve limitleri nasıl etkiler?

Kullanım katmanı (usage tier), organizasyonunuzun ödeme geçmişine bağlı olarak atanan seviyedir. OpenAI belgelerine göre toplam kredi satın alımınız arttıkça katmanınız otomatik yükselir. Daha yüksek katmanlar genellikle daha yüksek hız sınırları ve daha yüksek aylık kullanım üst sınırları getirir.

Burada rakam vermiyoruz, çünkü eşikler ve limitler değişebilir. Eski bir blog yazısındaki ya da forumdaki sayıya güvenmek, yanlış kapasite planına yol açar. Güncel değerleri panelinizdeki limit sayfasından ve resmi belgeden kontrol edin.

Yeni açılmış bir hesapla üretime çıkan ekipler bu yüzden sık şaşırır. Geliştirme sırasında sorunsuz çalışan bir uygulama, gerçek kullanıcı geldiğinde düşük katman sınırına çarpar. Dolayısıyla canlıya çıkmadan önce beklenen trafiği limitlerle karşılaştırın.

Kurumsal ihtiyaçlarda sağlayıcının daha yüksek kapasite seçenekleri de olabilir. Ancak bunlar, yukarıdaki toparlanma adımlarının yerine geçmez.

Proje ve anahtar bazında kullanım nasıl izlenir?

Limitler organizasyon ve proje düzeyinde işler. Bu yüzden izlemeyi de aynı düzeyde yapın. Her uygulama için ayrı bir proje ve ayrı bir anahtar oluşturmak, hangi uygulamanın payı tükettiğini görünür kılar.

Örnek senaryo: aynı organizasyonda bir sohbet botu, bir raporlama aracı ve bir içerik otomasyonu çalışıyor. Hepsi tek projede toplanmışsa gece çalışan rapor işi gündüz sohbet botunun payını yiyebilir. Ayrı projelerde ise sorunun kaynağı hemen görünür.

• Her uygulamaya ayrı proje ve ayrı anahtar verin.
• Projelere aylık harcama limiti ve uyarı eşiği koyun; belgeler uyarı ve sert üst sınır seçeneklerini ayırır.
• Kendi uygulamanızda model, proje ve istek sayısını günlüğe yazın.
• Düzenli aralıklarla panel kullanım ekranını kontrol edin.

Menü adları değişebileceği için kesin buton metnine yaslanmıyoruz. Panelde kullanım ve limit bölümlerini arayın.

Aynı anahtarı birden çok uygulamada paylaşmak neden risklidir?

Paylaşılan anahtar iki sorun doğurur. Birincisi görünürlük kaybıdır: hangi uygulamanın kaç istek yaptığını ayıramazsınız. İkincisi güvenliktir: anahtar ne kadar çok yerde durursa sızma ihtimali o kadar artar.

Belgeler, limitlerin organizasyon düzeyinde de işlediğini ve ekip arkadaşlarının kullanımının da payı tüketebileceğini söyler. Yani siz kodunuzu düzeltmişken başka biri deneme betiğiyle sınırı doldurabilir. Teşhis sırasında bunu mutlaka kontrol edin.

Anahtarları kaynak koduna gömmeyin, sunucu tarafında ortam değişkeni ya da gizli anahtar yönetimiyle saklayın. Tarayıcıya ya da mobil uygulama paketine koymayın. Bir anahtarın sızdığından şüphelenirseniz hemen yenisini üretip eskisini iptal edin.

API'nin temel kullanımı için OpenAI API nasıl kullanılır rehberimize bakabilirsiniz.

429 aldığınızda adım adım teşhis akışı nasıl işler?

Sahada kullandığımız akış kısadır ve her adım bir sonrakini eler. Önce kodu okuyun, sonra kapsamı belirleyin, sonra zamanlamaya bakın. Böylece tahmin yürütmek yerine kanıta dayanırsınız.

1. Kodu okuyun: hız sınırı mı, bakiye mi, harcama limiti mi?
2. Kapsamı belirleyin: hata yalnız bir modelde mi, tüm projede mi, tüm organizasyonda mı görünüyor?
3. Zamanlamaya bakın: hata yoğun saatlerde mi, belirli bir toplu iş sırasında mı çıkıyor?
4. Son değişikliği sorun: yeni bir özellik, yeni bir döngü ya da yeni bir ekip arkadaşı trafiği artırmış olabilir.
5. Tek bir küçük isteği elle gönderin. Başarılıysa sorun yük kaynaklıdır, başarısızsa hesap kaynaklıdır.

Örnek senaryo: bir ekip salı sabahı toplu 429 görüyor. Kod hız sınırını gösteriyor, kapsam tek model, zamanlama ise sabah dokuzdaki rapor işiyle çakışıyor. Çözüm, raporu geceye almak ve kuyruğa bağlamak oluyor.

Bu örnek kurgudur, gerçek bir müşteriyi anlatmaz. Yine de mantık aynıdır: kapsam ve zamanlama çoğu zaman nedeni kendisi söyler.

Kullanıcıya hata nasıl gösterilmeli?

Son kullanıcı için 429 teknik bir kavram değildir. Ona "sistem yoğun, birkaç saniye sonra tekrar deneyin" gibi sade bir mesaj gösterin. Ham hata metnini ya da anahtar bilgisini ekrana basmayın.

Arka planda ise iş kaybolmamalı. İstek kuyruğa geri girmeli, geri çekilme kuralıyla yeniden denenmeli ve sonuç hazır olunca kullanıcıya iletilmelidir. Sohbet arayüzlerinde yazıyor göstergesi bu bekleme için doğal bir yoldur.

• Kısa ve sakin bir bekleme mesajı verin.
• Ham hata gövdesini kullanıcıya göstermeyin.
• Aynı kullanıcı peş peşe istek gönderiyorsa arayüzde gönder düğmesini kısa süre kapatın.
• Bakiye kaynaklı hatalarda kullanıcıya değil, yöneticiye bildirim gönderin.

Ayrıca bakiye bitince ekibe otomatik uyarı gitmesi gerekir. Müşteriler sizden önce fark ederse güven kaybı yaşarsınız.

Geliştirme ortamında 429 davranışını nasıl test edersiniz?

Yeniden deneme kodunu ilk kez canlıda sınamak kötü bir fikirdir. Bunun yerine istemci ile API arasına sahte bir katman koyun. Bu katman belirli aralıklarla 429 benzeri cevap döndürsün ve sizin kodunuzun tepkisini ölçsün.

Test ederken üç şeye bakın. Birincisi, kodunuz başlıktaki bekleme süresine uyuyor mu? İkincisi, deneme sayısı üst sınırda duruyor mu? Üçüncüsü, bakiye benzeri bir hata gelince yeniden denemeyi bırakıp uyarı üretiyor mu?

Gerçek API'yi kasıtlı olarak limite zorlamayın. Bu hem maliyetlidir hem de hesabınızı gereksiz yere yorar. Sahte katman aynı bilgiyi risksiz verir.

Yük testinde de aynı ilke geçerlidir. Trafiği kademeli artırın, sınırı gördüğünüz anda durun ve ölçüm sonuçlarını kaydedin. Her testten sonra hangi yükte hangi hatanın çıktığını bir tabloya yazın. Böylece üretim trafiğiniz için güvenli bir çalışma aralığı çıkarırsınız.

429 hatasında en sık yapılan yanlışlar nelerdir?

Aynı yanlışları farklı ekiplerde tekrar tekrar görüyoruz. Bunları bilmek, teşhis süresini kısaltır. Aşağıdaki maddeler en olası olandan en az olasıya doğru sıralanmıştır.

1. Kota hatasını hız sınırı sanıp sonsuza kadar yeniden denemek.
2. Bekleme süresine rastgelelik eklememek, böylece tüm işçilerin aynı anda dönmesi.
3. SDK ve uygulama düzeyinde çifte yeniden deneme yazmak.
4. Tüm uygulamaları tek anahtarda toplamak.
5. max_tokens değerini gereksiz yüksek bırakmak.
6. Harcama uyarısı kurmayıp bakiyeyi ay sonunda öğrenmek.

Bunlardan ilk ikisi tek başına bile bir olayı büyütebilir. Çünkü yeniden deneme fırtınası, küçük bir sorunu uzun bir kesintiye çevirir.

Çözüm genellikle kod değil, süreçtir. Yani birisi bakiyeyi ve limitleri düzenli izlemeli, birisi de uyarıları almalıdır.

Çok kullanıcılı uygulamada adil paylaşım nasıl sağlanır?

Tek bir kullanıcı ya da tek bir müşteri, tüm payı tüketebilir. Bu durumda diğer kullanıcılar 429 görür, oysa suçlu onlar değildir. Bu yüzden kendi uygulamanızda kullanıcı başına bir iç sınır koymak mantıklıdır.

İç sınır, OpenAI sınırından önce devreye girer. Böylece yoğun bir kullanıcı yavaşlatılır ama diğerleri etkilenmez. Buna sıra tabanlı adil paylaşım denir ve kuyruk yapınızla birlikte çalışır.

• Kullanıcı ya da müşteri başına dakikalık iç bir istek sınırı belirleyin.
• Uzun işleri kullanıcıdan bağımsız arka plan kuyruğuna alın.
• Öncelikli işleri, örneğin canlı sohbeti, toplu işlerden ayırın.
• Ücretsiz deneme kullanıcıları için daha sıkı iç sınır kullanın.

Örneğin kurumsal müşteriniz gece toplu özet isterken, canlı destek sohbeti aynı anda çalışabilir. Öncelik ayrımı sayesinde sohbet hiç beklemez.

Ayrıca iç sınırlar maliyet kontrolünü de kolaylaştırır. Bir kullanıcının hatalı bir döngüyle yüzlerce istek göndermesi, tüm bütçenizi tüketmeden önce durdurulur.

Otomasyon araçlarında ve düşük kodlu akışlarda 429 neden sık görülür?

İş akışı araçları genellikle kayıtları paralel işler. Yüz satırlık bir tablo, yüz eşzamanlı API çağrısına dönüşebilir. Sonuç, saniyeler içinde hız sınırına çarpmaktır.

Çözüm, akışta eşzamanlılığı düşürmek ve satırlar arasına küçük bir bekleme koymaktır. Çoğu araç bunun için bir iterasyon ya da paralellik ayarı sunar. Ayar adı araca göre değiştiği için ilgili aracın belgesine bakın.

• Paralel çalışan adım sayısını azaltın.
• Her satırdan sonra kısa bir bekleme ekleyin.
• Hata durumunda akışın tamamını durdurmak yerine yalnız o satırı yeniden deneyin.
• Büyük tabloları gece çalışacak toplu işlere ayırın.

Bu tür akışları sağlam kurmak istiyorsanız, mimariyi baştan düşünmek zaman kazandırır. Çünkü sonradan eklenen yamalar çoğu kez yeni hatalar doğurur.

OpenAI API 429 hatası türleri karşılaştırma tablosunda nasıl görünür?

Aşağıdaki tablo, teşhis ekranında en sık gördüğümüz durumları yan yana koyar. Kod adları resmi hata sayfasındaki başlıklara dayanır. Mesaj metni değişebilir, o yüzden kodu esas alın.

Tablodaki ilk iki satır beklemeyle düzelir. Alttaki dört satır ise sizden bir faturalandırma işlemi ister. Bu ayrımı akılda tutmak teşhisi yarı yarıya kısaltır.

Kalıcı önlem için kontrol listesi nasıl olmalı?

Sorunu bir kez çözmek yetmez. Aynı hatayı bir ay sonra yeniden yaşamamak için aşağıdaki listeyi uygulamanıza ekleyin. Her madde küçük bir iştir, ama birlikte büyük fark yaratır.

1. Hata kodunu ayrıştırın: hız sınırı için yeniden deneyin, bakiye için yeniden denemeyin ve ekibe haber verin.
2. Geri çekilmeye rastgele bekleme ekleyin ve deneme sayısına üst sınır koyun.
3. Tek merkezde bir hız sınırlayıcı ve kuyruk kullanın.
4. Acil olmayan işleri toplu işleme taşıyın.
5. Her uygulamaya ayrı proje ve ayrı anahtar verin.
6. Harcama uyarıları kurun, böylece bakiye bitmeden haberiniz olur.
7. Yanıt başlıklarını ve hata kodlarını günlüğe yazın.
8. Canlıya çıkmadan önce yük testi yapın ve beklenen trafiği limitlerle kıyaslayın.

Bu liste teknik bir ekip için bile yarım günlük iştir. Karşılığında gece yarısı gelen alarm sayısı belirgin biçimde düşer.

Hangi yollardan uzak durmalısınız?

429 aldığınızda bazı kestirmeler cazip görünür. Ancak hizmet şartlarına aykırı olanlar hesabınızı riske atar. Aynı kullanımı bölüşmek için birden çok hesap açmak, limit aşmak amacıyla hesapları döndürmek ya da başkasının anahtarını kullanmak bu gruba girer.

Bunlar sistemleri atlatma sayılır ve önermiyoruz. Üstelik hesabınızın kapanmasına yol açabilir. Limitiniz yetmiyorsa doğru yol, kullanım katmanınızı yükseltmek, resmi kanaldan limit artırımı istemek ve istemleri verimli hale getirmektir.

Bir diğer kötü fikir, hatayı sessizce yutup kullanıcıya boş cevap göstermektir. Bunun yerine kullanıcıya kısa bir bekleme mesajı verin ve işi kuyrukta tutun. Böylece güveni korursunuz. Ayrıca kullanıcı aynı işlemi tekrar tekrar başlatmaz, bu da gereksiz yükü azaltır. Küçük bir arayüz iyileştirmesi, arka plandaki trafiği belirgin ölçüde sakinleştirir.

• Sahte ya da çalıntı ödeme bilgisiyle kredi eklemek yasaktır.
• Üçüncü kişilerden "limit açma" hizmeti satın almayın.
• Anahtarınızı bilinmeyen paylaşım sitelerine yapıştırmayın.

Ekibimiz bu sorunda nasıl yardımcı olur?

Talha Aslan ve ekibi olarak yapay zeka entegrasyonlarında kuyruk, yeniden deneme ve izleme katmanlarını tasarlıyoruz. Mevcut bir uygulamanın 429 davranışını incelemek ya da baştan sağlam bir mimari kurmak istiyorsanız yapay zeka otomasyon hizmetimiz için teklif isteyebilirsiniz.

Not: Bu yazı genel bilgi içindir. Limit, fiyat ve model bilgileri sık değişir, güncel değerler için OpenAI'nin resmi belgelerine bakın. Burada garanti vermiyoruz.

Resmi kaynaklar: OpenAI hız sınırları rehberi ve OpenAI hata kodları sayfası. İlgili diğer sorunlar için ChatGPT mesaj sınırı uyarısı ve ChatGPT dosya yükleme sorunları yazılarımıza bakın.