Claude Opus 5 Çıktı: AgentSpace Worker Havuzuna Giriyor
Çok-ajanlı bir sprint sistemini lider+worker mimarisiyle koşturuyorsan tanıdık bir refleks vardır: worker katmanında yeni bir model duyulduğunda önce fiyat tablosuna değil, sprint çıktısının kalitesine bakarsın.
AgentSpace’te worker havuzu şu an Claude’un mevcut nesil modelleri üzerinde koşuyor; lider ajan sprinti planlıyor, worker’lar task panosundan görevi alıp kalıcı hafızaya yazarak yürütüyor. Bu mimaride her yeni model sürümü aynı soruyu getiriyor: token başına ne kazanıyoruz, ajan kendi hatasını ne kadar iyi yakalıyor. Bu hafta sorulacak model Claude Opus 5 oldu.
Haber: Opus 5 Ne Getiriyor
TechCrunch’a göre, Anthropic Cuma günü Claude Opus 5’i duyurdu — Opus 4.8’den yalnızca iki ay sonra, Fable 5’ten daha ucuz ve daha az kısıtlayıcı bir model olarak.
Anthropic, modelin “much stronger at verifying its work and iterating carefully until it succeeds” olduğunu söylüyor; güvenlik sınıflandırıcılarının da Fable 5’e göre yüzde 85 daha az devreye gireceğini belirtiyor. Ayrıca sınıflandırıcı devreye girdiğinde isteği hataya değil daha zayıf bir modele yönlendiren beta bir Automatic Fallbacks özelliği geliyor.
AgentSpace İçin Ne Anlama Geliyor
AgentSpace’in worker katmanı headless Claude CLI üzerinde koşuyor. Worker’da hangi model çalıştığı iki şeyi doğrudan etkiliyor: sprint başına gerçek token faturası ve ajanın kendi çıktısını ne kadar iyi doğrulayıp düzelttiği.
Anthropic’in Opus 5 için öne çıkardığı yer tam burası: işini doğrulama ve iteratif düzeltme. Worker ajanların en sık kırıldığı nokta da zaten bu — bir hata üretiyor, fark etmiyor, üstüne ikinci bir hata ekliyor. Doğrulama gerçekten daha güçlüyse worker havuzunda doğrudan karşılığı olmalı.
Ama bunu iddia değil, plan olarak yazıyorum. Opus 5’i şu ana kadar AgentSpace worker havuzuna almadım, token-maliyet/sprint-kalite farkını henüz ölçmedim.
Yapacağım şey Haiku 4.5 ve Opus 4.8 testlerinde izlediğim yöntemin aynısı: aynı sprint tipini (örneğin tek bir refactor görevi) mevcut worker modeliyle ve Opus 5 ile art arda koşturup gerçek token faturasını ve teslim edilen kodun kalitesini karşılaştırmak.
Fable 5’in tabi olduğu 30 günlük veri saklama politikası bizde zaten gündem maddesi değildi, çünkü Opus hattı buna hiç tabi olmamıştı. Asıl merak ettiğim, sınıflandırıcıların daha az devreye girmesinin worker ajanların sıradan kod görevlerinde (exploit değil, refactor ve entegrasyon) engellenme sıklığını fiilen düşürüp düşürmeyeceği — bunu da henüz test etmedim.
Lider ajan tarafında şimdilik değişiklik yok: Opus 4.8 orada kalmaya devam ediyor. Tek seferde iki değişkeni (lider modeli ve worker modeli) aynı anda değiştirmek, hangi farkın neyden geldiğini karşılaştırılamaz hale getirir.
Okuyucu Bugün Ne Yapsın
Worker/ajan modelini değiştirmeden önce şu kontrol listesini uygula:
- Aynı sprint tipini (örneğin tek bir refactor görevi) mevcut modelle bir kez çalıştır, token faturasını ve teslim süresini not al
- Aynı görevi yeni modelle (burada Opus 5) çalıştır, aynı iki metriği kaydet
- Lider ajan modelini sabit tut — aynı sprintte iki değişkeni birden değiştirme
- Kod kalitesini otomatik testten geçir, “çalıştı” ile “doğru çalıştı” ayrımını yap
- Sonucu yayınlamadan önce en az bir gerçek sprintte tekrar et, tek koşuya güvenme
Okuyucu için sonuç: Opus 5 duyurusu başlı başına bir aksiyon nedeni değil — worker modelinizi değiştirmeden önce gerçek sprint verisiyle karşılaştırma yapın, duyuruya değil ölçüme güvenin.