Claude API, tükenmiş kredi bakiyesini 400 invalid_request_error olarak bildiriyor

Ne oldu

dev.to'da, öncelikle NeuraGrowth sitesinde yayımlanan bir yazı, bir Anthropic hesabının kredisi tükendiğinde üretim ortamındaki bir pipeline'ın nasıl çöktüğünü anlatıyor. Tek kişilik dijital ürün stüdyosu NeuraGrowth için yazan yazar, orqestra.kids_episode adlı bir görevin, kredi bakiyesinin API kullanımı için çok düşük olduğunu belirten ve okuyucuyu yükseltme ya da kredi satın alma方面的 Plans & Billing sayfasına yönlendiren bir AnthropicError ile sonlandığını aktarıyor.

Olayı kayda değer kılan, yanıtın sınıflandırılması. Yazıya göre API, 400 durum kodu ve invalid_request_error hata türüyle yanıt vermiş — istemcinin normalde "isteğin kendisi hatalı" olarak okuyacağı kategori — oysa asıl sorun hesap bakiyesiydi, payload'daki herhangi bir şey değil.

Tek arıza, üç uyarı

Durum kodu, arıza yerel olmadığı için önemliydi. Yazı, aynı anda tetiklenen üç uyarıyı anlatıyor. İlki orqestra.kids_episode için görev arızası uyarısıydı. İkincisi, S harfini kapsayan alfabet-007 bölümünün üretilmediğini bildiriyordu. Kritik olarak işaretlenen üçüncüsü ise hesap yenilenene kadar bu sağlayıcıya bağımlı her işin aynı şekilde başarısız olmaya devam edeceği için pipeline'ın tümüyle durduğunu söylüyordu. Yazarın belirttiğine göre bu işler oluşturma, keşif, metin yazımı ve eleştiri aşamalarını kapsıyor.

Kaçırılan bölüm uyarısı ayrıca konunun planda kaldığını ve bir sonraki çalıştırmanın bunu yeniden deneyeceğini kaydediyor; yani ödeme sağlandığında pipeline kendi kendini onaracak şekilde tasarlanmış.

Log'un göstermediği şeyler

Yazı hesabın sınırları hakkında açık. Bakiyenin nasıl sıfıra ulaştığını ya da ne kadar süredir düşük olduğunu söylemiyor ve önceki çalıştırmaların etkilenip etkilenmediğini de belirtmiyor. Görev uyarısı, takip için kullanılabilecek mevcut tanımlayıcı olan Anthropic tarafındaki bir request id taşıyor. Ayrıca bu kanıtın ne olduğunu da tartmak lazım: Anthropic'in hata davranışının geniş bir incelemesi değil, küçük bir stüdyonun operasyon log'undan gelen tek bir birinci ağızdan rapor.

Neden önemli

HTTP 400, çoğu hata yönetiminin kalıcı ve isteğe özgü saydığı koddur: payload'ı düzelt ya da işi bırak ve her şeyden önce retry yapma. Ödeme durması bunun tam tersi türden bir olay. Hesap geneline yayılır, o anahtarla yapılan her çağrıyı etkiler ve çözümü istekte bir değişiklik değil, ödemedir. İkinci durumu birincinin zarfına kodlamak tam olarak yanlış tepkiye davetiye çıkarır: başarılı olamayacak bir retry döngüsü, geçerli işlerin hatalı biçimlendirilmiş olarak dead-letter kuyruğuna atılması ya da hiçbir mühendisin kodla düzeltemeyeceği bir "bad request" için on-call sayfası.

Yazarın sonucu net: Claude'u API üzerinden çağırıyorsanız, mesajında kredi bakiyesinden bahseden bir 400'ü retry edilecek hatalı bir istek değil, o anahtarı kullanan her şey için bir ödeme durması olarak ele alın. Daha genel olarak bu vaka, yalnızca durum koduna güvenmek yerine hata mesajı içeriğini ayrıştırmanın ve krediler sıfırlanmadan önce uyarı veren bakiye izlemenin savunusu — stüdyonun kendi log'ları hesabın ne kadar süredir eridiğini bile söyleyemiyordu.

Tek bir sağlayıcı hesabına karşı çok aşamalı pipeline'lar çalıştıran ekipler için bu hikâye, tek bir upstream hata sınıfının tüm downstream işlere nasıl yayılabileceğinin de bir hatırlatıcısı. Çözüm yapılsaldır: arıza hesap genelindeyse bağımlı işleri circuit-break ile kesin, bu pipeline'ın yaptığı gibi tamamlanmamış öğleri retry için kuyrukta tutun ve tetiklenen uyarının API'nin seçtiği yanıltıcı etiketi değil gerçek nedeni — billing — adlandırdiğinden emin olun.