Anthropic, Claude Sonnet 5.5'i Opus 5.5'ten altı gün sonra, 28 Eylül'de yayımladı. Milyon girdi token'ı başına 2 dolar ve milyon çıktı token'ı başına 10 dolarlık maliyetiyle; Opus 5.5'in 4 ve 20 dolarlık fiyatının yarısına denk geliyor. Üstelik lansman sayfasında çoğu satırda Opus 5.5 ile arasında yalnızca birkaç puan fark bulunuyor ve Anthropic'in bizzat gerçekleştirdiği Terminal-Bench 4.0 testinde onun da önüne geçiyor. Birden fazla kodlama aracısı çalıştıran bir ekip için cazip hamle, her Agent'ı Sonnet'e geçirip aradaki farkı kâr hanesine yazmaktır.
Aynı sayfadaki efor bazlı grafikler ise bunun aksini söylüyor. Terminal-Bench manşet skoru, Sonnet'in en yüksek efor seviyesinde deneme başına 12,54 dolar maliyetle elde edildi. Gün boyu çalıştıracağınız ayarlarda ise sıralama tersine dönüyor: medium efordaki Opus 5.5, 2,94 dolara %57,6 skor alırken; high efordaki Sonnet 5.5, 1,94 dolara %43,0 skor elde ediyor ve Sonnet, medium seviyesindeki Opus'u ancak xhigh eforda 5,30 dolara %61,5 alarak geçebiliyor.
Özetle (TL;DR)
Kapsamı net belirlenmiş işlerde varsayılan olarak medium eforda Sonnet 5.5'i tercih edin. Sonnet'in eforunu xhigh seviyesine çıkarmaktansa; uzun, belirsiz veya sistem genelini etkileyen işleri Opus 5.5'e yönlendirin: Anthropic'in yayımladığı üç efor bazlı kodlama grafiğinin tümünde, high efordaki Opus, xhigh efordaki Sonnet'ten yaklaşık aynı veya daha düşük maliyetle daha yüksek puan alıyor. Bunu birinin aklındaki kişisel bir tercih olarak bırakmayın, Agent üzerinde somut bir kural olarak tanımlayın: her model ve efor kademesi için bir Agent, belirlenmiş eskalasyon koşulları ve net bir tamamlanma tanımı (definition of done). Sharkly modeli ya da eforu seçmez; Task üzerinde hangi Agent'ın ne yaptığının kaydını tutar.
Lansman verileri ne söylüyor?
Her bir hücrenin ardındaki efor seviyesini ve testi kimin yürüttüğünü gösteren lansman tablosu:
| Benchmark | Raporlayan | Sonnet 5.5 | Opus 5.5 |
|---|---|---|---|
| Terminal-Bench 4.0 | Anthropic | %70,6 (max) | %66,4 (xhigh) |
| FrontierCode 1.1 | Cognition | %52,1 (xhigh), %46,2 (max) | %54,4 (max) |
| CursorBench 4.0 | Cursor | %55,5 (max) | %57,8 (max) |
| SWE-Bench Pro | Anthropic sistem kartı, maksimum efor | 81,3 | 89,9 |
| HLE, araç kullanımıyla | Anthropic | %64,5 | %67,7 |
| OSWorld 2.1 | Anthropic | %80,1 | %81,8 |
Terminal-Bench satırıyla ilgili iki önemli çekince bulunuyor. Sistem kartına göre, işaretlenen (flagged) istekler Sonnet denemelerinin %1,5'ini etkilerken Opus 5.5 denemelerinin %10'unu etkiledi. Ayrıca Artificial Analysis'in kendi bağımsız testinde Sonnet 5.5 skoru %70,6 değil, %63,6 olarak ölçüldü. Bu arada SWE-Bench Pro testinde Opus lehine 8,6 puanlık bir fark göze çarpıyor. Anthropic'in konumlandırması da bu tabloyu doğruluyor: Kapsamı belirli günlük görevler ve hata düzeltmeleri (bug fix) için Sonnet 5.5 önerilirken, Opus 5.5 "karmaşık ve ucu açık işlerde açık ara daha güçlü kalmaya devam ediyor."
Manşetteki bu veriler, etkili bir yönlendirme (routing) kuralı oluşturmak için gereken asıl bilgiyi de gizliyor: Gerçekte kullanacağınız efor seviyelerinde görev başına düşen puan ve maliyet olarak üç temel kodlama kıyaslaması.
| Benchmark | Sonnet 5.5 medium | Sonnet 5.5 high | Sonnet 5.5 xhigh | Opus 5.5 medium | Opus 5.5 high |
|---|---|---|---|---|---|
| Terminal-Bench 4.0 | %28,8, $0,83 | %43,0, $1,94 | %61,5, $5,30 | %57,6, $2,94 | %64,2, $3,88 |
| CursorBench 4.0 | %39,2, $0,70 | %47,8, $1,67 | %53,1, $3,88 | %52,5, $2,91 | %56,0, $3,97 |
| FrontierCode 1.1 | %36,5, $0,24 | %49,4, $0,42 | %52,1, $1,59 | %54,6, $0,80 | %54,0, $1,09 |
Sonnet 5.5, medium ve high efor seviyelerinde en ucuz deneme maliyetini sunuyor; ancak skorları da bu seviyelerde en düşük durumda. High seviyesinin ötesine geçildiğinde ise dengeler değişiyor: Üç satırın tamamında xhigh efordaki Sonnet, medium efordaki Opus'tan daha pahalıya geliyor ve yaklaşık aynı ya da daha düşük bir bütçeyle çalışan high efordaki Opus'un gerisinde kalıyor. Ucuz model, tam da pahalı model gibi davranmasını istediğiniz anda ucuz olmaktan çıkıyor. Sonnet'in CursorBench maliyetleri Anthropic'in tahminlerine dayanıyor ve buradaki görevlerin hiçbiri doğrudan sizin kod deponuz (repository) değil; bu nedenle bu kesişim noktasını doğrulanması gereken bir hipotez olarak ele alın.
Yönlendirme kuralını yazıya dökmek
Önceki yazılarda modelleri Agent rollerine göre eşleştirmeyi, işin niteliğine göre görevi hangi aracının alacağına karar vermeyi ve kademeleri kural olarak belirlemeyi tartışmıştık. Sonnet 5.5 denkleme yeni bir sütun ekliyor. Terminal-Bench'te aynı modelin medium ve max efor seviyeleri arasında deneme başına yaklaşık 15 kat maliyet farkı var (12,54 dolara karşı 0,83 dolar). Dolayısıyla bir efor seviyesi belirtilmediği sürece "bunu Sonnet'e yönlendir" demek tam bir kural sayılmaz.
| Görev tipi | Agent (çalışma zamanı modeli) | Efor | Neden? |
|---|---|---|---|
| Yeniden üretilebilen ve belirli bir testi olan hata düzeltmeleri (bug fix) | Sonnet 5.5 | medium | Anthropic'in prompt kılavuzu, kapsamı iyi tanımlanmış görevlerde aracı tabanlı kodlama için medium seviyesini öneriyor |
| Test altyapısı (scaffolding), dokümantasyon, changelog, bağımlılık güncellemeleri | Sonnet 5.5 | medium | Kapsamı dar, doğrulaması ucuz; her üç grafikte de görev başına 1 doların altında |
| Tek modül içinde sınırlandırılmış, kabul kriterleri net özellikler | Sonnet 5.5 | high | Her grafikte hâlâ medium efordaki Opus'tan daha ucuz; Sonnet'in fayda sağladığı üst sınır |
| Gece çalıştırılan yüksek hacimli ön eleme (triage) işleri | Sonnet 5.5 | low, artı bir doğrulama adımı | Çalıştırma başına en ucuz seçenek; ancak low seviyesinde testleri çalıştırmadan görevi tamamlandı olarak bildirebilir |
| Uzun veya belirsiz yeniden yapılandırma (refactor), geçiş (migration), mimariyi kesen değişiklikler | Opus 5.5 | medium veya high | High seviyesinde, benzer veya daha düşük maliyetle her üç grafikte de xhigh efordaki Sonnet'i geçiyor |
| Planlama: Belirsiz bir talebi Task'lara dönüştürme | Opus 5.5 | high | Anthropic'e göre Opus'un üstünlüğünü koruduğu alan tam olarak karmaşık ve ucu açık işler |
| Başka bir Agent'ın çıktısının incelenmesi | Opus 5.5, ardından bir insan | high | İkinci bir model kanıtları doğrular; sonucu bir insan onaylar |
Kuralın asıl değer kazandığı yer eskalasyon sınırıdır. Bir Sonnet Agent'ı zorlandığında ilk refleks eforu artırmak olur. Oysa grafikler modeli değiştirmeniz gerektiğini söylüyor: Eldeki verilere göre Sonnet'in xhigh seviyesine ihtiyaç duyan bir Task, aslında high seviyesindeki Opus'a verilmesi gereken bir Task'tır. Kendi koşullarınızı belirleyebilirsiniz; aşağıdaki örnekler genel çerçeveyi göstermektedir:
- Aynı doğrulama kontrolü iki kez başarısız oldu. Bir insan, log kaydını ekleyerek Task'ı Opus Agent'ına aktarır; arka planda sessizce daha üst bir kademede yeniden deneme yapılmaz.
- Değişiklik, bir çalışana (worker) izin verilenden daha fazla dosya gerektiriyor (örneğin sekiz dosya) veya Task'ta belirtilmeyen bir dosya yoluna müdahale ediyor.
- Agent, Task'ın ifadeleriyle ilgili bir soru sormak yerine tasarıma yönelik bir soru soruyor.
- Belirli bir Task türü yalnızca Sonnet'in high seviyesinin üzerindeki eforlarda başarılı olabiliyor. Bu türü bir sonraki Sprint'te Opus Agent'ına taşıyın.
Bu durum tersi için de geçerlidir: Sürekli olarak tek denemede ve küçük farklarla (diff) tamamlanan Opus Task'ları bir alt kademeye aittir.
Her modelin inceleme kuyruğuna etkisi
Yalnızca model ve efor seviyesini belirten bir kural, eksik bir kuraldır. Kuralın diğer yarısı, işin "tamamlanmış" (done) halinin neye benzediğidir; çünkü her kademe incelemeyi yapacak kişiye farklı bir çıktı sunar ve her iki lansmandan önce de inceleme süreci zaten darboğaz oluşturuyordu. Daha ucuz çalıştırma maliyetleri diff hacmini artırır, inceleme yapacak kişilerin mesai saatlerini değil.
Anthropic'in Sonnet 5.5 prompt kılavuzu, inceleme yapacak kişinin neyle karşılaşacağı konusunda son derece açık:
- Low ve medium seviyelerinde, uzun aracı görevlerinde erkenden geri bildirim ister: Panoda gece saat 02.00'de bir insanın yanıtını bekleyen bir Task düşünün. Bir Hacker News yorumcusu, özel bir kıyaslama testinde alınan %7,4'lük skoru (Sonnet 5 %17,8 almıştı) tam olarak bu duruma bağladı.
- Low seviyesinde, doğrulamayı atlayabilir ve testleri çalıştırmadan kodu tamamlandı olarak bildirebilir. Bir ön eleme (triage) Agent'ının "tamamlandı" demesi, doğrulama çıktısı olmadan hiçbir anlam ifade etmez.
- Her efor seviyesinde, kimsenin istemediği testler, dokümanlar ve küçük dosyalar ekler. Bunların bir kısmı memnuniyetle karşılansa da tamamı okunması gereken daha fazla diff satırı demektir.
- xhigh ve max seviyelerinde, inceleme turları veya incelemeci alt aracılar ekler. Lansman sayfasında Sonnet 5.5'in FrontierCode testinde max seviyesinde neden xhigh'a kıyasla daha düşük puan aldığı böyle açıklanıyor: Claude Code'un çok sayıda alt aracıya dağılan kod inceleme yeteneğini daha sık çalıştırdı ve Cognition'ın incelediği iki vakada bu durum zaman aşımına veya kapsam dışı düzenlemelere yol açtı. İnceleme yapacak birine teslim edilebilecek en maliyetli şey de budur; çünkü birinin bunları satır satır ayıklaması gerekir.
Opus 5.5'in inceleme kuyruğuna getirdiği maliyet ise farklıdır. Anthropic, modelin 128k token'a varan çıktıyla 18 saat veya daha uzun süre görev üzerinde çalışabildiğini belirtiyor; bu nedenle getirdiği yük gürültü değil, doğrudan boyutudur. İnceleyicinin ihtiyaç duyduğu devir teslim paketi onun için de geçerlidir.
Dolayısıyla tamamlanma tanımı, Sharkly'nin her çalıştırmada dahil ettiği çalışan (worker) Agent talimatlarında yer almalıdır:
Agent: sonnet-worker (Claude Code, claude-sonnet-5-5, effort medium)
Done means:
- The checks named in the Task ran. Paste each command and its exit
code. "Tests pass" without output is not done.
- Changes stay inside the paths the Task names. List every file you
created that the Task did not ask for, and why.
- New tests are welcome. New docs files only if the Task asks.
Keep working on long Tasks. Ask only when two readings of the Task
would produce different code; otherwise proceed and record the
assumption in your report.
Stop and return to the Task, without retrying, when a check has failed
twice, the change needs more than 8 files, or the question is about
design rather than the Task's wording.
Her iki kademeyi Sharkly'de çalıştırmak
Sharkly modeli seçmez ve efor seviyesini belirlemez. Agents dokümantasyonunda bu durum açıkça ifade edilir: “Agent, Runtime'ın varsayılan modelini izler. Belirli bir model adı taahhüt etmez veya görüntülemez. Modelleri Agent üzerinden değil, Runtime veya Computer araç yapılandırması üzerinden değiştirin.” Agent üzerinde bir düşünme derinliği (thinking-depth) denetimi de bulunmaz. Bir kademe, Computer üzerindeki bir Claude Code yapılandırmasıdır; Agent ise ekibin ona nasıl iş atadığını temsil eder.
Özetle: Her kademe için bir Agent. sonnet-worker, Claude Code yapılandırması claude-sonnet-5-5 olarak ayarlanmış bir Computer üzerinde çalışır; opus-lead ise claude-opus-5-5 olarak ayarlanmış bir sistemde çalışır. Bir Computer bir konteyner olabileceğinden, ikinci bir kademe ikinci bir dizüstü bilgisayar anlamına gelmez. Claude Code'un model yapılandırma dokümanlarındaki üç ayrıntı, bir kademenin adının hakkını verip vermediğini belirler:
- Tam kimliği (full id) sabitleyin.
sonnetrumuzu, yalnızca Anthropic API üzerinde Sonnet 5.5 anlamına gelir (Bedrock ve Google Cloud bunu hâlâ Sonnet 4.5 olarak çözer) ve Sonnet 5.5, Claude Code v2.1.284 veya üzerini gerektirir. - Claude Code'un
defaultmodeli Pro, Max, Team, Enterprise ve API'de Opus 5.5'tir; dolayısıyla kimsenin özel olarak yapılandırmadığı bir Computer zaten bir Opus kademesidir. - Sonnet 5.5'in Claude Code'daki varsayılan eforu medium'dur, yani yukarıdaki worker kademesidir. Bunu değiştirmek Agent üzerinden değil, Computer üzerinden yapılır.
Sharkly, bir Runtime'ın hangi modeli kullandığını her zaman güvenilir bir şekilde okuyamaz; bu nedenle kademeyi Agent'ın adına ekleyin ve ad ile yapılandırmayı birlikte değiştirin. Adımlar Sonnet 5.5 kurulum kılavuzunda yer almaktadır.
Tek bir Task üzerinde her iki kademeye de ihtiyaç duyan işler için bir Crew kullanın. Crew; tek bir lider Agent tarafından koordine edilen, İnsanlar ve Agent'lardan oluşan yeniden kullanılabilir bir gruptur. Lider olarak opus-lead ve üye olarak Sonnet çalışanları atandığında; lider Task'ı okur, bizzat çözer veya belirli bir parça için bir üyeyi etiketler ve üyeler sonuçlarını aynı Task'a ekler. Bu yapı, Hacker News yorumcularının önerdiği ve devir teslimlerin bir insanın rahatça okuyabileceği şekilde gerçekleştiği Opus-orkestratör modelidir. Küçük ve iyi tanımlanmış işlerde Crew adımını atlayıp doğrudan sonnet-worker atayabilirsiniz.
Claude Code'un opusplan rumuzu bunun tek bir oturumdaki benzerini yapar: Plan modunda Opus, yürütme için Sonnet. Ancak bunun Sonnet kısmı yalnızca Anthropic API'de Sonnet 5.5 anlamına gelir; Bedrock, Google Cloud veya Foundry'de ise daha eski bir Sonnet sürümüne yönlendirilir. Oturumu tek bir kişi çalıştırıp inceleyecekse bunu kullanın; kimin planlayıp kimin uyguladığını başka birinin de görmesi gerekiyorsa iki ayrı Agent kullanın.
Kademeler arasında asla aktarılmayan tek bir şey vardır: akıl yürütme (reasoning). Sonnet 5.5'in düşünme blokları (thinking blocks) modele ve mevcut sohbete bağlıdır. Başka hiçbir model bunları okuyamaz ve Sonnet 5.5 de Opus 5.5'in bloklarını okuyamaz. Crew dizin paylaşımı, önceki Agent'ın oturumunu değil, yalnızca dosyaları paylaşır. Liderin neye karar verdiği, çalışana ancak Task üzerine açıkça yazılmışsa ulaşır; bu da ayrı bir yazının konusudur.
Bunların hiçbiri işi kimin onaylayacağını değiştirmez. Agent'lar araştırır, yürütür, test eder ve raporlar. İnsanlar ise yönü belirler, yetki verir ve sonucu onaylar. Yukarıdaki maliyetler sağlayıcı faturanıza yansır, zira model kullanımı bu araçlarda tanımlı abonelikler veya API anahtarları üzerinden devam eder. Önümüzdeki çeyrekte hangi model lider olursa olsun görevlendirme, çalıştırma günlüğü, sorular, sonuç ve insan incelemesi Task'a kaydedilir ve bu mantık, Sonnet 5.5 ve GPT-6 Sol karşılaştırmasının da gösterdiği gibi sağlayıcılar arasında geçerliliğini korur. Tek bir ekosisteme bağlı kalmak yerine birden fazla kodlama aracısını bir arada kullanmaya devam etmek istiyorsanız, Sharkly tam olarak bu ihtiyaca çözüm üretmek için tasarlanmıştır.
