Claude Opus 4.8: AgentSpace Sprintinde İlk Test
Model değişince ne değişiyor, elde rakam yoksa bilinmez
AgentSpace’te lider ajan bir sprinti worker’lara bölüyor, worker’lar Claude üzerinde koşuyor. Alttaki model sürümü değiştiğinde iki ihtimal var: kalite gözle görülür biçimde düzelir ya da fark aslında token faturasında sessizce büyür. Çok-ajanlı bir geliştirme ortamını gerçek sprintlerle çalıştıranlar bilir — bu ikisini birbirinden ayırmanın tek yolu ölçüm, izlenim değil.
Anthropic’ten Claude Opus 4.8
Anthropic, Claude Opus 4.8 modelini yayınladı; fiyat Opus 4.7 ile aynı kalıyor ($5/milyon giriş, $25/milyon çıkış token), fast mode ise öncekine göre üç kat ucuzladı. Şirket, modelin kendi yazdığı koddaki kusurları eskisine göre “around four times less likely than its predecessor to allow flaws in code it has written to pass unremarked” bıraktığını, yani dört kat daha az gözden kaçırdığını aktarıyor. Ayrıca claude.ai ve Claude Code’a bir effort kontrolü ve “dynamic workflows” adında yüzlerce paralel subagent çalıştırabilen bir araştırma-önizleme özelliği geldi.
Bizim notumuz
Planım şu: Opus 4.8’i AgentSpace’in lider ve worker ajan rollerine gerçek bir sprintte takıp mevcut sürüme karşı kalite ve token-maliyeti farkını izlemek. Sprint başına token takibini zaten tutuyoruz, o yüzden karşılaştırma için ek bir alt yapı kurmam gerekmiyor — sadece modeli değiştirip aynı sprint tipini bir kez daha koşturmam lazım. Effort kontrolü ayrı bir deney konusu: lider ajanı yüksek, tekrarlayan worker görevlerini düşük effort’ta çalıştırıp faturayı nereden kısabileceğime bakacağım.
“Dynamic workflows” özelliğine bilerek mesafeli yaklaşıyorum. Yüzlerce paralel subagent fikri kulağa AgentSpace’in mimarisine yakın geliyor ama bu, Claude Code’a özgü bir araştırma önizlemesi — bizim lider-worker orkestrasyonumuzun yerini alacak diye bir şey yok, sadece izleyeceğim bir gelişme. Şu an elimde ne kalite delta’sı ne de token-maliyeti farkı var; sprint koşup gerçek rakamı görmeden “daha iyi” demeyeceğim.
Bugün ne yapsın:
- Mevcut multi-agent sprintinin token maliyetini modele göre logla (giriş/çıkış ayrı).
- Aynı görev tipini eski ve yeni model sürümüyle bir kez çalıştır, sonucu diffle.
- Effort/hız ayarı varsa önce tekrarlayan/basit görevlerde dene, kritik görevde değil.
- Fiyat aynı kaldıysa bile fast mode veya effort seçeneklerinin faturayı değiştirip değiştirmediğini ayrıca kontrol et.
Sonuç olarak: model sürümü değişikliğini “iyileşme” diye yazmadan önce aynı sprinti iki sürümle de koşturup faturayı yan yana koymak, tahminden çok daha ucuza mal oluyor.