16 Haziran’da Anthropic’in kendi durum sayfası, üretim mühendislerinin önemsemesi gereken sayıyı kaydetti: tüm Sonnet ve Opus modelleri 37 dakika boyunca yaklaşık %10 hata oranına ulaştı, ardından Claude Opus 4.8 80 dakika daha ortalama %10 hata oranıyla devam etti (Claude Status). Uygulamanız kullanıcıya görünen bir akışın içinde Claude çağırıyorsa bu “sonra tekrar deneyin” türü küçük bir rahatsızlık değildir. Bu, tasarımın yeniden gözden geçirilmesidir.
Olaylar bununla da bitmedi. Claude Status, 16 Haziran’dan 19 Haziran’a kadar tekrarlayan Opus 4.8 ve daha geniş Claude hizmet olayları gösteriyor: 16 Haziran’da Opus’a özel üç olay, 17 Haziran’da dört Opus/Sonnet veya yalnızca Opus olayı daha, 18 Haziran’da Claude hizmetlerinde bir kesinti ve 19 Haziran’da iki API ya da Opus 4.8 olayı (Claude Status). 20 Haziran itibarıyla sayfa bugün bildirilen olay olmadığını söylüyor, ama son dönemdeki desen yeterince açık.
Anthropic, Claude Opus 4.8’i 28 Mayıs’ta Opus 4.7’ye aynı fiyatta bir yükseltme olarak yayımladı; daha iyi benchmark performansı ve geliştirilmiş dürüstlükle daha güçlü bir iş ortağı olarak konumlandırdı (Anthropic). Bunların hepsi doğru olabilir. Operasyonel gerçeği değiştirmiyor: Opus 4.8 kritik yolunuzdaysa uygulamanızın artık gerçek bir arıza modu olmalı.
UTC’ye göre ne oldu
Önemli olay 16 Haziran 17:29 UTC’de başladı; Claude Status birçok modelde artan hatalar için inceleme açtı. Anthropic daha sonra bunu iki aşamada özetledi: 17:23-18:00 UTC arasında tüm Sonnet ve Opus modelleri etkilendi ve yaklaşık %10 hata oranına ulaştı; 18:00-19:20 UTC arasında ise yalnızca Opus 4.8 ortalama %10 hata oranı gördü (Claude Status).
Ardından daha küçük ama yine de can yakan Opus 4.8 sıçramaları geldi. 16 Haziran’da Claude Status ayrıca 19:41-19:53 UTC civarında Opus 4.8 hataları ve 20:45-20:58 UTC arasında başka bir Opus 4.8 olayı kaydetti (Claude Status). 17 Haziran’da birden fazla Opus 4.8 olayı vardı; bunların arasında isteklerin 04:59-05:41 UTC arasında artan hatalar aldığı bir olay ve Sonnet’in önce toparlandığı, Opus 4.8’in ise hâlâ çalışmaya ihtiyaç duyduğu bir Sonnet 4.6 artı Opus 4.8 olayı bulunuyordu (Claude Status).
18 Haziran daha genişti: Claude Status, 06:55-07:40 UTC arasında Claude hizmetlerini etkileyen bir hizmet kesintisi olduğunu söylüyor (Claude Status). 19 Haziran’da ise 06:07-07:17 UTC arasında bir Opus 4.8 olayı ve 08:17-08:45 UTC arasında ayrı bir “Claude API üzerinde artan hata oranları” olayı yaşandı (Claude Status).
Bu zaman çizelgesi önemli, çünkü bu tek ve temiz bir kesinti değildi. Bir kümeydi. Tek bir retry 30 saniyelik bir aksaklığı gizleyebilir. Ama bir ürünü birkaç güne yayılan tekrarlı model düzeyi istikrarsızlıktan kurtarmaz.
Geliştiriciler neden öfkeli
Artan Claude hataları hakkındaki Hacker News başlığı, AI’ı oyuncak prompt’lardan günlük üretim işlerine taşımış insanlardan bekleyeceğiniz şeyin ta kendisi: hayal kırıklığı, şakalar ve bağımlılık riski üzerine ciddi bir tartışma (Hacker News).
Bir grup bunu frontier-model dünyasının normal büyüme sancısı olarak görüyor. GPU kapasitesi zor, talep dalgalı ve bu modelleri sunmak pahalı. Diğer grup daha az hoşgörülü: ekipler Claude Code, Claude API ve Opus sınıfı modeller etrafında ücretli ürünler ve iç iş akışları kuruyorsa “artan hatalar” zararsız bir örtmece değildir. Daha kibar ifadeyle yazılmış downtime’dır.
En keskin yorumlar sadece “Claude çöktü” demiyor. Mesele bağımlılığın tersine dönmesi. Geliştiriciler artık bir özelliği zenginleştirmek için sadece bir API kullanmıyor. Modelin kod yazdığı, kod incelediği, ticket triage yaptığı, veri çıkardığı ve müşterilere yanıt verdiği iş akışları kuruyorlar. Bir HN yorumcusu, uptime’ı LLM sağlayıcısının uptime’ıyla sınırlanan müşteri-facing otomasyon sistemlerini anlattı, ardından pratik çözümleri sıraladı: çok sağlayıcılı fallback, async kuyruklar ve graceful degradation (Hacker News).
Topluluk tartışmasının faydalı kısmı bu. Soru artık Opus 4.8’in iyi olup olmadığı değil. Soru, sisteminizin onu bir veritabanı, bir cache, sorunlu bir SaaS bağımlılığı ya da bazen müsait olmayan bir insan uzman gibi görüp görmediği.
Doğru cevap: sorunlu bir uzman.
Retry bütçelerinin sert bir tavanı olmalı
Anthropic’in hata dokümanları sıradan hatalı istekleri, hesap rate limit’lerini, dahili API hatalarını, timeout’ları ve overload durumlarını birbirinden ayırıyor. Buradaki kilit kodlar 500 api_error, 504 timeout_error, 529 overloaded_error ve bazen kendi trafik artışınız limitleri tetiklerse 429 rate_limit_error. Anthropic, 529 kodunun API’ın geçici olarak aşırı yüklendiği anlamına geldiğini ve API’lar tüm kullanıcılar genelinde yüksek trafik yaşadığında ortaya çıkabileceğini söylüyor (Claude Docs).
Bunların hepsini körlemesine aynı şekilde retry etmeyin. Desteklenmeyen bir parametreden gelen 400 sizin hatanızdır. Hatta Opus 4.8, Opus 4.7 kısıtlarını devralır: varsayılan dışı temperature, top_p veya top_k ayarlamak Messages API üzerinde 400 döndürür (Claude Docs). Bunu retry etmek sadece latency yakar.
Overload ve dahili arızalarda retry ancak bir bütçenin içinde faydalıdır. 6 saniyelik SLA’sı olan kullanıcıya dönük bir istek, Opus 4.8’i nazikçe 45 saniye boyunca dövmemeli. Her isteğe bir retry bütçesi verin, sonra degrade edin.
Makul bir varsayılan:
const retryable = new Set([500, 504, 529]);
async function callWithBudget(request, budgetMs = 6000) {
const started = Date.now();
for (let attempt = 0; ; attempt++) {
try {
return await callClaude(request);
} catch (error) {
if (!retryable.has(error.status) || Date.now() - started > budgetMs) {
throw error;
}
const delay = Math.min(250 * 2 ** attempt, 2000) * (0.5 + Math.random());
await sleep(delay);
}
}
}Kesin sayılar ürününüze uymalı. Bir coding agent, checkout asistanından daha uzun bekleyebilir. Arka plandaki bir belge pipeline’ı dakikalarca bekleyebilir. Bir sesli agent bekleyemez.
Daha büyük nokta şu: retry güvenilirlik değildir. Retry, ya toparlanmaya ya da fallback’e uzanan bir köprüdür.
Fallback yönlendirmesi sıkıcı olmalı
16 Haziran olayı, “Sonnet’e düş” demenin her zaman yeterli olmadığını iyi hatırlatıyor. İlk aşamada tüm Sonnet ve Opus modelleri etkilendi. İkinci aşamada Opus 4.8 sağlıksız kalırken Sonnet toparlandı. 17 Haziran’da Claude Status ayrıca Sonnet başarı oranlarının toparlandığı, Opus 4.8’in ise hâlâ artan hatalara sahip olduğu bir Sonnet 4.6 ve Opus 4.8 olayı kaydetti (Claude Status).
Bu yüzden model fallback’i hislerle değil katmanlarla çalışmalı.
| Katman | Ne zaman kullanılır | Örnek aksiyon |
|---|---|---|
| Opus sınıfı birincil | Yüksek akıl yürütme gerektiren işler en iyi kaliteye ihtiyaç duyduğunda | Opus 4.8’i sıkı bir bütçe içinde dene |
| Sonnet sınıfı fallback | Opus’a özel hatalar veya latency olduğunda | Kalite kabul edilebilirse aynı prompt’u Sonnet’e yönlendir |
| Claude dışı fallback | Claude API veya çok modelli olay olduğunda | Başka bir sağlayıcıya, daha küçük bir modele ya da yerel/açık modele yönlendir |
| Ürün fallback’i | AI yolu kullanılamadığında | İşi kuyruğa al, cached sonuç döndür, insana devret ya da degrade UI göster |
Fiyat da bu yönlendirme kararına dahil olmalı. Anthropic’in 27 Mayıs fiyat listesi, global standart fiyatlandırmada Claude Opus 4.8’i milyon input token başına 5 dolar ve milyon output token başına 25 dolar olarak listeliyor; Sonnet 4.6 için 3 ve 15 dolar, Google Vertex AI listelerinde Haiku 4.5 için 1 ve 5 dolar görünüyor (Anthropic price sheet). Bu, fallback’in sadece bir uptime aracı olmadığı anlamına gelir. Aynı zamanda maliyet kontrol aracıdır.
Her işi aynı şekilde degrade etmeyin. Bir hukuki analiz taslağı Opus geri gelene kadar kuyrukta beklemeli olabilir. Bir destek chatbot’u daha ucuz bir modele geçip tek bir netleştirici soru sorabilir. Bir kod asistanı workspace’i koruyup düzenleme yapmadan önce kullanıcıya model değiştirdiğini söyleyebilir. Model davranışı anlamlı ölçüde değiştiğinde sessiz fallback tehlikelidir.
Durum sayfasını bir girdi sinyali gibi izleyin
Claude Status, durum sayfasında email, Slack, Microsoft Teams, webhook, Atom ve RSS abonelik seçenekleri sunuyor (Claude Status). Kullanın. Ama uyarıların ölüp gittiği bir Slack kanalında durmayın.
Durum değişikliklerini LLM gateway’inize besleyin. Bir Opus 4.8 olayı açılırsa Opus için circuit-breaker eşiğini düşürün. Claude API genelinde bir olay açılırsa ilk hızlı hatadan sonra interactive trafiği göndermeyi bırakın ve uygun işleri kuyruğa taşıyın. Olay çözülürse sağlayıcıya hücum etmek yerine trafiği kademeli olarak geri yükseltin.
Circuit breaker kendi telemetrinizi de izlemeli:
- Sağlayıcı, model, bölge ve endpoint bazında hata oranı.
- Streaming ve non-streaming çağrılar için P50, P95 ve timeout oranı.
- Başarılı yanıt başına retry denemesi.
- Fallback oranı ve fallback kalite skoru.
- Yalnızca API hata oranı değil, kullanıcıya görünen hata oranı.
Yöneticilerin anladığı metrik sonuncusu. Opus 4.8 %10 hata döndürse ama ürününüz kullanıcı aksiyonlarının %99,5’i için işe yarar degrade yanıtlar döndürse, bir olayınız vardır ama müşteri yangınınız yoktur. Ürününüz her isteği Opus üzerinde blokladığı için kilitleniyorsa yangını siz çıkarmışsınız demektir.
Bu hafta ne değişmeli
İlk olarak, Opus 4.8’i herhangi bir single point of failure olmaktan çıkarın. Hâlâ en iyi modeliniz olabilir. Tek yolunuz olmamalı.
İkinci olarak, prompt’ları degradation toleransına göre sınıflandırın. “Mutlaka Opus kullanmalı” nadir ve açık olmalı. “Sonnet kullanabilir” yaygın olmalı. “Kuyruğa alınabilir” ise belge işleme, rapor üretimi, toplu kod inceleme ve interactive olmayan analiz için varsayılan olmalı.
Üçüncü olarak, retry’ları görünür kılın. request_id, model, durum kodu, retry sayısı, nihai sonuç ve fallback hedefini log’layın. Anthropic’in dokümanları API hatalarının request ID içerdiğini ve destek taleplerinde bunların yer alması gerektiğini söylüyor (Claude Docs). Bir olay sırasında “hangi model hata verdi ve sonra nereye yönlendirdik?” sorusunu cevaplayamıyorsanız observability’niz hazır değildir.
Dördüncü olarak, fallback yolunuzu bilerek test edin. Staging’de Opus arızalarını zorlayan bir feature flag ekleyin. Her Opus çağrısının 529 döndürdüğü bir saatlik game day çalıştırın. Neyin bozulduğunu izleyin: prompt varsayımları, output parser’ları, eval eşikleri, UI metni, müşteri vaatleri. Bunları bir sonraki gerçek olaydan önce düzeltin.
Son olarak, kullanıcılara karşı dürüst olun. “AI başarısız oldu” kötü UX’tir. “Gelişmiş model geçici olarak degrade olduğu için bunu standart modda çalıştırıyoruz” çok daha iyidir. Bazı ürünlerde bu cümle güven inşa eder.
16-19 Haziran olayları Claude Opus 4.8’in kötü bir model olduğunu kanıtlamıyor. Frontier modellerin artık kararsız erişilebilirlik özelliklerine sahip üretim bağımlılıkları olduğunu kanıtlıyor. Onlara ödeme işlemcileri, arama indeksleri ve cloud bölgeleri gibi davranın: faydalı, pahalı ve fallback olmadan bağlarsanız gününüzü mahvetmeye kesinlikle muktedir.
Claude Fable 5’i kendileri denemek isteyen okuyucular, onu OneHop üzerinden drop-in endpoint olarak, liste fiyatının yaklaşık %30 altında kullanabilir. Yeni hesaplar kart gerektirmeden $10 ücretsiz alır: Claude Fable 5 on OneHop veya $10 ücretsizle başlayın.
Ek okuma: Claude Fable 5 ile başlangıç.
