Spotify Claude Code Token'ını %90 Kesti. Ben Ölçtüm

Spotify'ın Claude Code kurulumu, Spotify'da ürün yöneticisi olan Dimitri Mazmanov'un yazdığı bir blog yazısı; kodu GitHub'da. Mazmanov, ekibinin kullandığı yapılandırmanın Claude Code token kullanımını %90 azalttığını söylüyor. İlk cümlesi argümanın tamamını taşıyor: bir yapay zeka kodlama ajanının yaptığı işin büyük kısmı düşünmek değil, G/Ç. Tek bir metotla ilgili bir soruyu yanıtlamak için beş dosya okumak ya da yanındaki yirmi dosyayı kopyalayan yirmi birinci test dosyasını yazmak, neredeyse hiç akıl yürütmeden binlerce token harcıyor.

Tek bir tweet, yazıyı tek bir cümleyle bir buçuk milyon görüntülemeye taşıdı: yazılı kurallar bir öneridir, bir engel değildir. Hacker News onu ana sayfaya koydu, 271 puan ve 173 yorum; yorumların yarısı aynı soruyu sordu: neyin %90'ı? Spotify'ın kendi nitelemesi "toplu okuma". Bu yazı kurulumu saf Claude Code içinde yeniden kuruyor, sonra ölçüyor; böylece o nitelemenin size tam olarak ne kazandırdığını biliyorsunuz.

Portal bir router değil. Spotify'ın, kendi açık kaynak yaptığı geliştirici platformu Backstage üstüne kurulmuş dahili geliştirici portalı. İçindeki ilgili özellik Modes adını taşıyor: Spotify'ın tanımıyla bir mode, geçici bir runtime üzerinde çalışan bildirimsel bir agent; kabaca agent'lar için AWS Lambda. Talimatları yazıyorsunuz, bir model seçiyorsunuz, bir sıcaklık belirliyorsunuz, araçlar ekliyorsunuz. Mazmanov bunlardan ikisini kurmuş, bir toplu okuyucu ve bir kod yazıcı; ikisi de 0,2 sıcaklıkta Gemini Flash üstünde, yani ikisi de bilerek ucuz ve sıkıcı.

Yönlendirme, Shunt adlı bir Claude Code plugin'inde yaşıyor. GitHub'da herkese açık ve iki komutla kuruluyor. Ancak ikinci adım Portal komut satırını sizin Portal örneğinize karşı doğruluyor ve sizde öyle bir örnek yok. Plugin herkese açık; devrettiği şey değil.

Dolayısıyla işe yarayan hamle plugin'i unutup deseni tutmak. Desenin, onun kendi sözleriyle, üç katmanı var: hook'lar, script'ler, skill'ler. Her birinin saf Claude Code'da bir karşılığı var; bu yazının geri kalanı tam olarak bunu kuruyor ve ölçüyor.

Kurulumun birinci sürümü, projenin talimat dosyasındaki bir yönlendirme kuralları bloğuydu. Mazmanov'un sözleriyle "bir nevi çalışıyordu": kurallar tavsiye niteliğindeydi, zorlanmıyordu, Claude onları görmezden gelebiliyordu ve her projenin kendi kopyasına ihtiyacı vardı. İkinci sürüm kararı prompt'tan çıkarıp araç katmanına taşıyor; ikisi de bir araç çağrısından önce tetiklenen iki hook ile. Biri her dosya okumasını izliyor, öteki shell'i.

Okuma hook'u 33 satırlık bir bash. Ortamdan bir eşik okuyor, varsayılan olarak 350 satır, sonra üç şeyi geçiriyor:

• Offset veya limit içeren bir okuma, çünkü Claude neye ihtiyacı olduğunu zaten biliyor.
• Var olmayan bir dosya.
• Eşikte ya da altında bir dosya, çünkü küçük bir şeyi devretmek onu okumaktan daha pahalı.

Geri kalan her şey engelleniyor ve Claude dosya yerine şu mesajı okuyor: bu dosya şu kadar satır, toplu okuyucu skill'ini kullan, bir düzenleme için birebir içeriğe ihtiyacın varsa yalnızca o bölümü yeniden oku. Shell hook'u büyük bir dosya üstünde cat, head, tail, less ve more komutlarını yakalıyor. Pipe'lı bir komut geçiyor, çünkü grep'e pipe'lamak hedefli bir okuma.

Mazmanov'un katmanlamayla ilgili noktası önemli olanı: Claude skill açıklamasını hiç okumasa bile hook pahalı okumayı yine de engelliyor. Skill yönlendirmeyi daha pürüzsüz yapıyor; engel onu gerçek kılıyor. Bir ayrıntı daha sonra önem kazanacak: script, "block" adlı üst düzey bir kararla yanıt veriyor. Bu kelimeyi aklınızda tutun.

Worker'lar iki prompt'tan ibaret. Okuyucu: "sen hassas bir kod analistisin, yalnızca yapılandırılmış madde işaretleri üret, selamlama yok, düzyazı yok, her maddeye tam ad, tür ya da satır numarasıyla başla." Yazıcı: "mevcut desenlere, adlandırmaya ve stile birebir uy; yalnızca kodu üret, kod bloğu yok, açıklama yok." Bu son satır olmadan model her şeyi Markdown içine sarıyor ve Claude'un onu ayrıştırması gerekiyor.

Bunları iki script sarıyor. Bulk-read bir soru ve dosya yolları alıp gönderiyor. Code-write bir spesifikasyon ve bir referans dosyası alıp sonucu doğrudan diske yazıyor; böylece Claude üretilen kodu hiç görmüyor. Her devretme tek seferlik: bir devam sorusu dosyaları yeniden gönderiyor. Bu, önemli olduğu yerde bedava, çünkü korpus worker'a gidiyor ve Claude'un context'ine hiç girmiyor.

Üçüncü katman, Claude'a ne zaman devredeceğini söyleyen bir skill dosyası: 350 satırın üstündeki dosyalar, üç ya da daha fazla dosyaya yayılan sorular, büyük diff'ler. Son satırı "düzenlemeden önce satır numaralarını doğrula".

Spotify'ın tablosu bir Java monorepo'sunu ve üç okuma senaryosunu kapsıyor. Tek dosya durumu yaklaşık 34.000 token'dan 6.000'in altına düşüyor ve üç satırın ortalama tasarrufu %90.

Spotify'ın benchmark'ı	Değer
Depolar	1 Java monorepo
Senaryolar	3, hepsi toplu okuma
Tek dosya durumu, önce	~34,000 tokens
Tek dosya durumu, sonra	< 6,000 tokens
Ortalama tasarruf	90%
Token tahmini	token başına 4 karakter
Yazıcı zorlaması	yok (yalnızca okuyucuda hook var)

İki uyarıyı Spotify'ın kendisi yazmış: token'lar dörder karakter olarak tahmin ediliyor ve yazıcının hiçbir zorlaması yok. Yani %90, tahmini girdi token'ı cinsinden üç toplu okuma satırının ortalaması; hiçbir yerde kalite puanı ya da dolar rakamı yok. Test edilecek rakam bu.

Claude Code yerleşik bir Explore subagent'ıyla geliyor ve yakın tarihli bir sürümden beri ana modelinizi devralıyor, Opus ile sınırlı; yani "ucuz okuyucu" artık ucuz değil. Belgeler çözümü tek cümlede veriyor: Explore adlı bir proje subagent'ı yerleşik olanı geçersiz kılıyor ve kendi model alanını koruyor. Tek bir markdown dosyası, bir front matter ve model satırında Haiku yazıyor. Toplu okuyucu bu. Yazıcı ikinci bir dosya: model Sonnet, araçlar yalnızca Read ve Write, gövdesi ise Spotify'ın kendi talimatlarının yapıştırılmış hali.

Çalışmasının nedeni, her subagent'ın taze ve yalıtılmış bir context window ile başlaması. Okuduğu şey oraya iniyor, ana konuşmaya değil. Bu, Spotify'ın tek seferlik devretmesinin ağ gidiş dönüşü çıkarılmış hali.

Sonra kimsenin planlamadığı kısım geliyor. Bu hafta Reddit'te Fable'a Opus ajanları başlatması söylendi, o ise bunun yerine beş Fable ajanı başlattı: haftalık limitin %73'ü otuz dakikada gitti. En çok oy alan yanıt, model bir subagent gönderdiğinde çalışan, onu modeli açıkça seçmeye zorlayan ve görevi yapabilecek en ucuz olanı seçmesini söyleyen bir hook'tu. Üçüncü hook bu: Agent aracını izliyor ve modeli olmayan bir çağrı tek bir cümleyle reddediliyor, "modeli açıkça seç".

Spotify'ın skill'i projenin talimat dosyasında üç satıra dönüşüyor: 350 satırın üstündeki dosyalar explorer'a gider, boilerplate yazıcıya gider, her agent çağrısı bir model belirler. Kaba seçenek de var: her subagent'a tek bir modeli dayatan iki ortam değişkeni. Dürüst sınır şu: okuyucu daha ucuz bir model, dolayısıyla döndürdüğü şey ana modelin bildiğinin tamamı. Ölçüm bölümü bunu ele alıyor.

"block" kelimesini hatırlayın. Spotify'ın script'i üst düzey bir karar döndürüyor, ama güncel Claude Code belgeleri farklı bir şey söylüyor: bir PreToolUse hook'u kararını hook'a özgü bir çıktı nesnesinin içinde döndürüyor ve alanın adı permissionDecision. Dört sonucu var, allow, deny, ask ve defer; burada istenen deny. Hook'un neden olarak yazdığı her şey Claude'a gösteriliyor ve birden fazla hook yanıt verirse deny kazanıyor.

Yeniden kurulan okuma hook'u aynı 350 eşiğini ve aynı üç istisnayı koruyor; "block" yerine, Explore subagent'ını ve kullanılacak modeli adlandıran bir nedenle deny döndürüyor. Belgelerin açıkça belirttiği bir tuzak: ayarlarınızdaki hook'lar subagent'ların içinde de çalışıyor. Bir kaçış olmadan Haiku okuyucu kendi okumalarında reddediliyor ve işini asla yapamıyor; bu yüzden script kimin çağırdığını kontrol edip iki worker'ı geçiriyor.

Kablolama, üç eşleştiriciye sahip tek bir ayar dosyası, Read, Bash ve Agent, her biri kendi script'ine işaret ediyor, eşik ise bir ortam değişkeni olarak ayarlı. Pratikte 1.090 satırlık bir dosya üstündeki bir okuma, yazdığımız cümleyle bir hata olarak dönüyor: bu okumayı explorer'a devret, model Haiku. Sonra devretme geliyor: ana model önce satırları sayıyor, model Haiku olarak ayarlanmış explorer'ı çağırıyor ve madde işaretleri her biri bir satır numarasıyla geri geliyor. Üç tur, 44 saniye.

Spotify'ın cümlesi geçerliliğini koruyor: katmanlama sistemin zarifçe bozulmasını sağlıyor. Yönlendirmeyi talimat yapıyor, hook ise ağ. Ne var ki ağda bir delik var. Dosyanın tamamını isteyen bir model onu offset ve limit ile parçalara bölebiliyor, bu geçiyor; ya da bir sed aralığıyla shell üzerinden dökebiliyor, bu hook onu yakalamıyor. Ölçüm ikisini de sayıyor.

Test deposu Fastify, Node web framework'ü: 294 dosya, 63'ü eşiğin üstünde. İki özdeş klon, tek fark .claude klasörü ve kural dosyası. Ana model Opus, CLI varsayılanı; okuyucu Haiku; yazıcı Sonnet. Tek prompt'luk oturumlar, devam sorusu yok, her senaryo yapılandırma başına iki kez koşuldu, toplam on altı koşu. Dört senaryo Spotify'ınkilerle aynı: büyük bir dosyanın export'ları, üç dosya ve birbirlerini nasıl çağırdıkları, bir kaynak dosyasının testiyle karşılaştırılması ve mevcut bir dosyadan diske yazılan yeni bir test dosyası.

Senaryo	Ana context, kurulumsuz	Ana context, kurulumla	Değişim	Toplam maliyet, kurulumsuz	Toplam maliyet, kurulumla	Değişim	Süre, kurulumsuz	Süre, kurulumla	Değişim
Tek büyük dosya	88,693	51,552	-41.9%	$0.139	$0.087	-37.8%	22 s	44 s	+100.8%
Üç dosya	357,166	73,440	-79.4%	$0.581	$0.218	-62.4%	52 s	129 s	+149.9%
Kaynak vs test	303,808	114,136	-62.4%	$0.451	$0.374	-17.1%	93 s	125 s	+33.6%
Yeni test dosyası	143,432	121,818	-15.1%	$0.295	$0.302	+2.6%	66 s	87 s	+32.2%
Dördü birden	223,274	90,236	-59.6%	$0.366	$0.245	-33.1%	58 s	96 s	+65.3%

Önem taşıyan ilk sütun ana context, yani pahalı modelin gerçekten gördüğü token'lar. Üç dosyalı soruda %79 düşüyor, dört senaryonun tamamında %59,6. Fatura daha az düşüyor, toplamda üçte bir, çünkü okuyucunun kendi token'ları bedava değil; küçük test yazma görevinde fatura %2,6 arttı. Süre ters yönde gidiyor: kurulumsuz ortalama 58 saniye, kurulumla 96. Devretme her seferinde daha yavaş.

İki yapılandırmanın en çok ayrıştığı yer kalite. Kurulumsuz, ana model dosyaları satır numarası olmadan shell üzerinden döktü ve elle saydı; baştan sona yanlış satır numaraları üretti: 149. satırda bildirilen bir fonksiyon aslında 156. satırdaydı. Kurulumla, dört koşudan biri okuyucunun özetini olduğu gibi kabul etti ve üç yanlış iddia taşıdı; bunlardan biri, okuyucuya göre route dosyasının hiç çağırmadığı bir fonksiyondu, oysa 553. satırda çağırıyor. Üretilen dört test dosyası da geçiyor ve deny hook'ları on altı koşuda sıfır kez tetiklendi: kural dosyası mevcutken ana model satır sayısını kontrol etti ve her seferinde kendi kendine devretti.

İzlerden bir şey daha: kural olmadan ana model Read aracını hiç kullanmadı. Her şeyi shell üzerinden okudu ve bir shell aralık okuması aynı token'lara mal oluyor ve hook'tan geçiyor. Yani Spotify'ın tablosu 90 diyor; bu tablo context'te 60, faturada üçte bir diyor.

Tutulmaya değer üç şey var: Haiku üstünde bir proje Explore subagent'ı, talimat dosyasında üç satırlık bir kural ve güvenlik ağı olarak okuma hook'u. Ölçülen sonuç %60 daha az ana context, faturada üçte bir indirim ve üçte iki daha fazla duvar saati süresi.

Hook'a güvenmeden önce iki şeyi düzeltin. Hook'lar subagent'ların içinde çalışıyor, bu yüzden worker'larınızı muaf tutun. Ve shell deliği: bash hook'u cat, head ve tail'i yakalıyor, ama bir aralık okuması geçiyor ve ana model kuralı olmadığında tam olarak bunu kullandı.

Spotify'ın kendi sınırları geçerli. Düzenlemeyi devredemezsiniz ve akıl yürütmeyi devredemezsiniz; worker, Claude'un saniyeler içinde yakaladığı bir thread güvenliği hatasını kaçırdı ve her devretme bir gidiş dönüş. Hacker News'teki şüpheciler de bir konuda haklıydı: girdi token'ları fatura değil. Çıktı token'ları daha pahalı ve bu kurulum onlar için hiçbir şey yapmıyor.

Kimin tasarruf edeceği nasıl ödediğinize bağlı. API'de üçte bir indirim. Pro veya Max planda aynı kurulum dolarları değil, beş saatlik ve haftalık pencerelerinizi hareket ettiriyor. Eşiğe de dikkat edin: altında devretme tasarruf ettiğinden fazlasına mal oluyor ve 45 satırlık test durumu artı %2,6 ile bunun kanıtı. Son olarak, sekiz koşudan ikisinde okuyucunun özeti hatalar taşıdı ve ana modelin doğrulama turu onları yakaladı. O turu atlarsanız o hatalar düzenlemelerinize ulaşır.