Claude Code Token Overhead: Headless Sprint Faturam
AgentSpace’te bir sprint başladığında lider ajan işi parçalara böler, sonra worker’lar teker teker devreye girer. Çok-ajanlı bir sistemi headless CLI üzerinden koşturanlar bu sahneyi tanır: her worker ilk hamlesini yapmadan önce, ekranda hiçbir şey görünmeden geçen bir an vardır — sistem promptu, araç şemaları, ajan kataloğu yükleniyor, iş daha başlamadan. Bu an ücretsiz değil.
Sorun şu ki bu maliyet konsolda görünmüyor, sadece ay sonunda faturada kendini belli ediyor. Ben bu maliyeti bugüne kadar hiç ayrıştırmadım; Claude ile koşan headless ajanlarımın her sprint’te ne kadar “boş” token yaktığını hissediyordum ama ölçmüyordum. Systima’nın yeni “Claude Code token usage overhead” ölçümü tam bu boşluğa parmak bastı.
Haber: Claude Code, prompt gelmeden 33 bin token yakıyor
Systima (systima.ai), Claude Code ve OpenCode’u aynı modelde, aynı görevlerde, aradaki trafiği kaydeden bir proxy üzerinden karşılaştırdı. Tek satırlık bir yanıt istendiğinde Claude Code, kullanıcı promptu daha gelmeden yaklaşık 33.000 token’lık sistem promptu, araç şeması ve enjekte edilmiş scaffolding gönderdi; OpenCode aynı iş için yaklaşık 7.000 token harcadı. Sonnet 4.5’te ölçülen bu fark, Claude Fable 5’te yaklaşık 3,3 kata indi, çünkü Claude Code yeni modellere daha küçük bir sistem promptu yolluyor.
Kaynağın vurguladığı gibi: “A 33k-token baseline means every turn starts a sixth of the way into a 200k window before any code enters the conversation.” Aynı ölçümde, tek görevin iki alt-ajana bölünmesi toplam maliyeti 121.000’den 513.000 token’a çıkardı — 4,2 kat. Tek istisna: çok adımlı bir görevde Claude Code, tool çağrılarını tek istekte toplayarak toplamda OpenCode’u geçti.
Bu bizim için ne anlama geliyor
Floor ödeniyor ama amortisman yok
Systima’nın 33k/7k farkı esasen uzun, çok turlu bir konuşma senaryosunda ölçülmüş: sistem promptu bir kere yazılıyor, sonraki turlarda önbellekten ucuza okunuyor. AgentSpace’in worker’ları böyle çalışmıyor. Sprint başına yeni bir headless çağrı açılıyor, görev yapılıyor, ajan kapanıyor. Yani bu 33k’lık zemin maliyeti, on turluk bir konuşmaya yayılıp ucuzlamıyor — her worker’ın üstlendiği her görev parçası, bu zemini baştan, tam fiyatına ödüyor.
Bu benim için haberin en can alıcı tarafı: bizim mimarimizde overhead amortize olmuyor, kümülatif oluyor. Bir sprint’te kaç worker açılıyorsa, 33k’lık zemin o kadar kez tekrarlanıyor demek — kaynağın “floor” dediği rakam bizde neredeyse birebir maliyete dönüşüyor, cache’in yumuşatma payı olmadan.
Leader-worker modelimiz tam da en pahalı senaryo
Systima’nın en sert bulgusu benim için en alakalı olanı: aynı görev tek ajanla 121.000 token’a mal olurken, iki alt-ajana bölündüğünde 513.000 token’a çıkmış — çünkü her alt-ajan kendi bootstrap maliyetini ödüyor, sonra lider onun transkriptini de okuyor. AgentSpace zaten bu şekli seçmiş bir mimari: lider görevi parçalıyor, worker’lar paralel ilerliyor, lider ilerlemeyi görev panosundan takip ediyor. Kaynağın “en büyük çarpan bu” dediği yapı, bizim varsayılan çalışma biçimimiz.
Bu, fan-out’u yanlış bulduğum anlamına gelmiyor — paralel worker’lar bir sprint’i gerçekten hızlandırıyor. Ama şunu net görüyorum: kaç worker açtığımız artık sadece bir hız kararı değil, doğrudan bir maliyet kararı. Görevi tek ajana mı bırakmalıyım yoksa üçe mi bölmeliyim sorusunun cevabı, hıza ek olarak token faturasını da içermeli.
Tek istisna: çok adımlı görevde tablo tersine dönüyor
Systima’nın bulduğu tek Claude Code lehine sonuç da bizim için önemli: çok adımlı bir görevde (yaz, çalıştır, test et, düzelt) Claude Code, tool çağrılarını tek istekte toparlayıp toplamda OpenCode’u geçmiş — OpenCode her adımda ayrı bir istek açtığı için küçük zeminini defalarca ödemiş. Bunu AgentSpace’e çevirince şu soru çıkıyor: bir worker’a “şu dört adımı sırayla yap” diye tek, geniş bir görev vermek mi, yoksa aynı işi dört ayrı ince görev/worker’a bölmek mi daha ucuza geliyor? Kaynağın verisine göre cevap görev şekline bağlı — seri, çok turlu bir iş tek büyük ajanda daha az zemin ödüyor; gerçekten paralelleşebilen iş fan-out’ta kazanıyor. Bunu sprint planlama kararına şimdiden dahil etmem gerekiyor; şu ana kadar bu ayrımı hiç yapmadan bölüyordum.
Hafıza dosyalarımızın boyutu doğrudan faturaya yansıyor
Systima’nın ölçtüğü bir diğer katman, üretim ortamındaki bir talimat dosyasının (AGENTS.md/CLAUDE.md) her isteğe ortalama 20.000 token eklemesiydi — üstelik bir sürümde bu dosya yanlış adla yazıldığında harness onu sessizce yok saymış. Biz de worker’lara bağlamı ve kalıcı ajan hafızasını dosya üzerinden veriyoruz. Bu bulgu bana iki şeyi hatırlattı: birincisi, hafıza dosyasının boyutu büyüdükçe bunun her worker çağrısında tekrar tekrar faturaya yansıdığı; ikincisi, dosya adının veya yolunun harness tarafından gerçekten okunup okunmadığını doğrulamadan varsaymanın riskli olduğu. Sessizce yok sayılan bir dosya hem hafıza hem para kaybı demek.
Cache istikrarsızlığı bizde daha az önemli, ama sıfır değil
Kaynağın en çarpıcı ayrıntılarından biri, Claude Code’un aynı görevde önbellek prefiksini oturum içinde yeniden yazması ve bunun OpenCode’a göre önbellek yazımını 54 kata kadar şişirmesi. Bu bulgu çoğunlukla uzun, tek oturumluk interaktif kullanım için geçerli — bizim kısa ömürlü headless worker’larımızda tekrar yazılacak uzun bir oturum zaten yok, tek seferlik. Yani bu spesifik risk bizi daha az vuruyor. Ama lider ajan sprint boyunca açık kalan, uzunca bir konuşma yürütüyorsa (görev panosunu takip ederken), aynı yeniden-yazma davranışı orada da devreye girebilir. Bunu ayrı ayrı izlemem gerekiyor: worker’lar için zemin maliyeti, lider için önbellek istikrarı.
Ne henüz ölçmedim, ne değişmiyor
Dürüst olmak gerekirse: AgentSpace’in sprint başına gerçek token maliyetini bugüne kadar sistematik loglamadım — Anthropic’in kullanım paneline bakıp genel eğilimi izliyordum, Systima’nın yaptığı gibi istek gövdesi seviyesinde bir ölçüm yapmıyordum. Bu yazı için tek başına yeni bir rakam iddia etmiyorum; iddia edebileceğim şey, hangi mekanizmanın bizde de geçerli olduğu.
Değişmeyen şey şu: worker’ların iş kalitesi bu ölçümle ilgisiz. Systima da bunu net söylüyor — her iki harness aynı görevleri doğru tamamlamış, fark sadece aynı sonuç için ödenen bedelde. Bizim tarafımızda da mesele “Claude daha mı iyi çalışıyor” değil, “aynı sprint çıktısı için ne kadar fazla ödüyoruz” sorusu.
Bugün ne yapmalısın
Kendi headless Claude Code kurulumun için kopyala-yapıştır bir ölçüm listesi:
1. Fresh config dizini + boş workspace ile tek satırlık görev çalıştır (--print modu).
→ API/usage panelinden input token sayısını oku. Bu senin "floor" rakamın.
2. Hafıza/talimat dosyanı (CLAUDE.md veya AGENTS.md) ekle, aynı görevi tekrar çalıştır.
→ Farkı not et; hangi dosya adının gerçekten okunduğunu doğrula.
3. Bağladığın her MCP sunucusunu tek tek ekleyip aynı görevi tekrar ölç.
4. Aynı görevi (a) tek ajanla, (b) 2 worker'a bölerek çalıştır.
→ Toplam token farkını kıyasla; bu senin fan-out çarpanın.
5. Sprint bittiğinde worker sayısı × floor rakamını gerçek faturayla karşılaştır.Bu beş adım, benim AgentSpace için önümüzdeki sprint’te yapacağım şey. Sonucu paylaşırım.
Systima’nın ölçtüğü zemin maliyeti bende teorik bir sayı değil, leader-worker mimarimizin doğal bir sonucu — ölçmeden önce sadece görmezden gelmesi daha kolaydı. AgentSpace’in worker mimarisini ve token disiplinini nasıl kurduğumuzu görmek istersen AgentSpace sayfasına bak.