Claude 4.7 tokenizer maliyet ölçüm sonuçları

• Claude 4.7, önceki sürüme kıyasla ortalama 1,3~1,45 kat daha fazla token üretiyor ve aynı fiyatlandırma yapısında oturum başına maliyette %20~30 artış yaratıyor
• Token artışı özellikle İngilizce ve kod içeriklerinde belirgin; CJK (Çince·Japonca·Korece) içeriklerde ise neredeyse hiç değişim yok
• Daha ayrıntılı tokenizasyon sayesinde komutlara uyum (Instruction Following) yaklaşık 5 yüzde puan artıyor; özellikle biçim hataları azalıyor
• Cache prefix ve konuşma geçmişindeki token sayısı arttığı için cache maliyeti ve rate limit tüketim hızı da birlikte yükseliyor
• Sonuç olarak Claude 4.7, doğruluk ve ayrıntılı komut uygulamasında iyileşme elde ederken bunun karşılığında ek token maliyetini göze alan bir yapı olarak değerlendiriliyor

---

Claude 4.7 tokenizer ölçüm sonuçları

• Anthropic'in Claude Opus 4.7 modeli için, önceki sürüm 4.6'ya göre 1,0~1,35 kat daha fazla token kullandığı belirtilse de, gerçek ölçümlerde bunun 1,45~1,47 kat seviyesinde olduğu görüldü
• Aynı fiyat ve kota koşullarında token sayısının artması; max window tüketim hızının yükselmesi, cache prefix maliyetinin artması ve rate limit'e daha erken ulaşılması gibi etkiler yaratıyor
• Deney, maliyet ölçümü ve komutlara uyum ölçümü olmak üzere iki bölümden oluşuyor

Maliyet ölçüm yöntemi

• Yalnızca tokenizer farkını karşılaştırmak için Anthropic API'nin POST /v1/messages/count_tokens endpoint'i kullanılarak aynı içerik 4.6 ve 4.7 modellerine ayrı ayrı verildi
• İki örnek seti kullanıldı
  • Gerçek Claude Code kullanıcılarının gönderdiği 7 gerçek kullanım örneği
  • İngilizce, kod, yapılandırılmış veri, CJK, emoji, matematik sembolleri vb. içeren 12 yapay örnek

• Gerçek Claude Code içeriği sonuçları

  • 7 gerçek kullanım örneğinin ağırlıklı ortalama oranı 1,325 kat (8.254 → 10.937 token)
  • Başlıca örnekler
  • CLAUDE.md dosyası: 1,445 kat
  • Kullanıcı prompt'u: 1,373 kat
  • Blog yazısı: 1,368 kat
  • Kod diff'i: 1,212 kat

• İçerik türüne göre sonuçlar (12 yapay örnek)

  • İngilizce ve kod içeriği ortalaması: 1,345 kat
  • CJK (Çince·Japonca·Korece) içeriği ortalaması: 1,01 kat
  • Ayrıntılı örnekler
  • Teknik dokümantasyon: 1,47 kat
  • Shell script: 1,39 kat
  • TypeScript kodu: 1,36 kat
  • İngilizce düz yazı: 1,20 kat
  • JSON: 1,13 kat
  • Japonca·Çince düz yazı: 1,01 kat

Tokenizer'daki değişim örüntüsü

• CJK, emoji ve sembol içerikleri 1,005~1,07 kat seviyesinde; yani neredeyse hiç değişmiyor
  • Latin olmayan sözcük dağarcığında büyük bir değişiklik olmadığı anlaşılıyor
• İngilizce ve kod içerikleri 1,20~1,47 kat artıyor; kod, düz yazıdan daha fazla etkileniyor
  • Koddaki tekrar eden dizgiler (anahtar kelimeler, import'lar, tanımlayıcılar vb.) daha ince parçalara ayrılarak daha fazla token'a bölünüyor
• İngilizcede karakter başına token oranı 4,33→3,60'a, TypeScript'te 3,66→2,69'a düşüyor
  • Aynı metin daha küçük birimlere ayrılarak temsil ediliyor

Neden daha fazla token kullanıyor?

• Anthropic, 4.7 sürümünde “komutları daha kelimesi kelimesine izleme eğilimini” öne çıkarıyor
• Daha küçük token birimleri, kelime düzeyinde dikkat (attention) kapasitesini güçlendirerek doğru komut uygulama, karakter düzeyinde görevler ve tool çağrısı hassasiyeti üzerinde iyileşme sağlayabiliyor
• Notion, Warp, Factory gibi partnerler tool çalıştırma hatalarında azalma bildirdi
• Ancak tokenizasyon dışında model ağırlıkları ve post-training de değiştiği için nedenleri birbirinden ayırmak mümkün değil

Komutlara uyum testi

• IFEval benchmark'ı (2023, Google) kullanıldı: “tam olarak N kelimeyle cevap ver”, “virgül kullanmadan yaz” gibi 541 prompt içinden 20 örnek test edildi
• Sonuçlar
  • Katı modda prompt bazında: 4.6 → %85, 4.7 → %90 (+5yp)
  • Katı modda komut bazında: %86 → %90 (+4yp)
  • Gevşek modda fark yok
• İyileşme çoğunlukla biçimlendirme (formatting) ile ilgili hataların azalmasından kaynaklanıyor
• Belirgin fark yalnızca tek bir prompt'ta (change_case:english_capital) doğrulandı
• Örneklem küçük olduğu için (+5yp istatistiksel olarak belirsiz), bu durum küçük ama tutarlı bir iyileşme olarak değerlendiriliyor

Claude Code oturum başına maliyet hesabı

• 80 gidiş-dönüş konuşmalık bir oturum varsayımı
  • Statik prefix: 6K token (CLAUDE.md 2K + araç tanımları 4K)
  • Konuşma geçmişi: Tur başına 2K artış, 80 turda 160K'ya ulaşıyor
  • Girdi/çıktı: Tur başına 500 / 1.500 token
  • Cache isabet oranı: %95

• 4.6 için oturum maliyeti

  • | Kalem | Hesap | Maliyet |
  • | --- | --- | --- |
  • | İlk cache yazımı | 8K × $6.25/MTok | $0.05 |
  • | Cache okuma (79 kez) | 79 × 86K × $0.50/MTok | $3.40 |
  • | Yeni girdi | 79 × 500 × $5/MTok | $0.20 |
  • | Çıktı | 80 × 1.500 × $25/MTok | $3.00 |
  • | Toplam | | yaklaşık $6.65 |

• 4.7 için oturum maliyeti

  • CLAUDE.md: 1,445 kat → 2K → 2,9K
  • Araç tanımları: 1,12 kat → 4K → 4,5K
  • Konuşma geçmişi: 1,325 kat → 160K → 212K
  • Kullanıcı girdisi: 1,325 kat → 500 → 660
  • Ortalama cache prefix: yaklaşık 115K token
  • | Kalem | Hesap | Maliyet |
  • | --- | --- | --- |
  • | İlk cache yazımı | 10K × $6.25/MTok | $0.06 |
  • | Cache okuma (79 kez) | 79 × 115K × $0.50/MTok | $4.54 |
  • | Yeni girdi | 79 × 660 × $5/MTok | $0.26 |
  • | Çıktı | 80 × 1.500–1.950 × $25/MTok | $3.00–$3.90 |
  • | Toplam | | yaklaşık $7.86–$8.76 |
  • Token birim fiyatı değişmeden, oturum başına maliyet %20~30 artıyor
  • Max planı kullanıcıları için aynı zaman penceresi içinde oturumun bitiş noktası daha erken geliyor

Prompt cache etkisi

1. Model bazında cache ayrımı nedeniyle 4.7'ye geçişte mevcut 4.6 cache'i geçersiz hale geliyor
   • İlk oturum cache uygulanmadan başlıyor ve daha büyük bir prefix maliyeti oluşuyor
2. Cache hacminin kendisi 1,3~1,45 kat artıyor; hem okuma hem yazma maliyeti aynı oranda yükseliyor
3. Aynı konuşma günlüğünde bile token sayısı değişiyor; bu da geçmişe kıyasla faturalama ve izleme metriklerinde kopukluk yaratıyor

Karşı argümanlar ve yorum

• “Girdilerin çoğu cache okumadan oluştuğu için etkisi önemsiz”

  • Cache isabet oranı yüksek olduğunda maliyet etkisi küçük olabilir; ancak TTL süresi dolduğunda, cache geçersiz olduğunda veya model değiştiğinde maliyet tam oranla artıyor

• “1,35 kat bir üst sınır değil, bir aralık”

  • Gerçek ölçümler üst sınıra yakın değerlerde (1,325 kat) yoğunlaştı ve bazı dosyalar bunu aştı
  • Gerçek kullanımda planlamayı üst sınıra göre yapmak daha güvenli

Sonuç

• İngilizce ve kod ağırlıklı işlerde token kullanımı 1,3~1,45 kat artıyor
• Komutlara uyum yaklaşık +5yp iyileşiyor; küçük ama pratikte anlamlı bir gelişme
• Oturum başına maliyet %20~30 yükseliyor, token birim fiyatı aynı kalıyor
• Sonuç olarak daha yüksek doğruluk ve daha ayrıntılı komut uygulaması için ek maliyet ödenen bir yapı ortaya çıkıyor

[kaydash]

Claude 4.7 değil, Opus 4.7

[GN⁺]

Hacker News yorumları

• LLM’lerin performans/maliyet eğrisinin logaritmik bir yapıda olduğu varsayılırsa, Opus 4.5+’ın bu eğri üzerinde yeni bir nokta mı olduğu, yoksa sadece daha yüksek performans için maliyetin keskin biçimde arttığı bir bölgede mi yer aldığı belirsiz
  Anthropic’in fiyatları hızla artırması, işletme maliyetlerindeki sert artışı yansıtan bir işaret olabilir
  Model değerlendirme grafiklerinde x ekseninin maliyet logu olarak gösterilmesi gibi yaygın uygulamaların bu gerçeği gizlediğini düşünüyorum

  • Toby Ord’un AI ajanları için saatlik maliyet analizi yazısına bakılmış. Onun performans/maliyet sınırı kavramı daha fazla ilgi görmeli
  • Artık geliştiricilerin işe uygun model boyutunu ve efor seviyesini doğru boyutlandırması (right-sizing) gereken bir dönemde olduğumuzu düşünüyorum
    Her durumda en iyi modeli kullanma dönemi bitti. Göreve göre farklı noktaları seçebileceğimiz seçeneklere ihtiyaç var
    Karmaşık işler için daha büyük model kullanıp tek seferde 5 saatlik token harcamak bana göre sorun değil
    Ancak bu seçim karmaşıklığından hoşlanmayan çok kişi olacaktır ve gelecekte akıllı yönlendirme denemelerinin artacağını tahmin ediyorum
  • Anthropic IPO’ya hazırlanıyor, bu yüzden kullanıcı başına geliri artırma baskısı yüksek. Sonuçta gerçek model işletme maliyetlerini yansıtan bir fiyat yapısına doğru gidiliyor
  • Model doğrudan silikona uygulanabildiğinde maliyet düşecek ve hız artacak. Taalas gibi girişimlere bakılabilir
  • Eğer müşteriler daha yüksek maliyeti ödemeye razıysa, çok daha güçlü modeller sunulabileceğini düşünüyorum
    Örneğin Apple’da olduğu gibi ultra pahalı seçenek isteyen bir müşteri kitlesi varsa, ultra yüksek performanslı LLM pazarı da mümkün olabilir

• Birçok kişi AI modellerinin maliyetine odaklanıyor ama gerçekte insanların AI kodlama ajanlarını yönlendirmek ve gözden geçirmek için harcadığı zaman çok daha pahalı
  Ayda $200 hobi için pahalı olabilir ama iş açısından bakınca önemsiz bir düzey
  Esas mesele modelin işi ne kadar iyi yaptığı ve mevcut fiyat seviyelerinde asıl belirleyici olan zaman karşılığı verim

  • Ekibimiz bu yıl Claude ile üç ürün çıkardı. Özellikle 9 kişi 6 ay süreceği tahmin edilen bir projeyi 2 kişi 2 ayda bitirdik
    Claude aboneliğinin ekonomik değerinin 10 bin ile 40 bin euro arasında olduğunu düşünüyorum.
    Fiyat 100 kat artsa bile alırdım. Yalnız aylık 20 bin euro olursa alternatifleri değerlendirirdim; şu an için verimlilik artışı ezici düzeyde
  • $200 şirketler için neredeyse hiç yük değil ama bireysel hobi kullanımında haklı çıkarması zor
  • Openclaw instance’ımda Opus kullanımı için günde $200 fatura çıktı. Daha büyük mesele yönlendirme optimizasyonu. Saatte $1 iken güzeldi ama saatte $15 olunca rekabet gücü düşüyor

• Model kalitesindeki artışın sonunda azalan getiri bölgesine ulaşacağını düşünüyorum
  8K ile 16K ekranlar gibi, çoğu kullanıcı farkı hissetmiyor
  Maliyette %20–30 artış varsa buna karşılık gelen görünür bir değer artışı da olmalı

  • Bu yüzden araştırmaların çoğunun kodlama alanına odaklandığını düşünüyorum. Zorluk seviyesi sürekli yükseliyor ve ekonomik değer de korunuyor
    Buna karşılık genel sohbet tabanlı sorgular zaten doygunluğa ulaşmış durumda, bu yüzden modeller arasında farklılaşmak zor
  • %99 doğru görünse bile günde 100 bin karar verildiğinde küçük hatalar birikip büyük sorunlara dönüşebilir
  • Yerelde çalışabilen bir 4K model çıkarsa büyük araştırma laboratuvarları zor durumda kalır. Yine de Google reklam gelirleri sayesinde dayanabilir gibi görünüyor
  • İşin türüne göre değişir. Örneğin ilaç tasarımında %95 tamamlanmışlık ile %100 tamamlanmışlık arasındaki fark, değer açısından onlarca kat olabilir
  • Web araması ya da özetleme için zaten sınıra gelinmiş olabilir ama kodlama karmaşıklığı sonsuza kadar genişleyebilir

• GitHub Copilot’un model çarpanı (multiplier) 3’ten 7.5’e çıktı
  Bu, Microsoft’un zararları azaltma çabası gibi görünüyor
  Ayrıntı için resmî belgeye bakılabilir

  • Bu yüzden organizasyonumuzda “Opus 4.7’yi kesinlikle açmayın” tavsiyesi verdim. 4.6 (3x) ve 4.5 (3x) kabul edilebilir ama 4.7 (7.5x) açısından fiyat/performans tamamen kötü
  • Son dönemde Opus 4.6’da çıkarım kalitesinde düşüş var. Sonuca koşuyor, mantık adımlarını atlıyor. Büyük bir sıçrama olmazsa sert bir kalite düşüşü(en**)** yaşanacak gibi duruyor

• Yazı başlığı yanıltıcı. Token sayısı artmış olabilir ama iş başına maliyet farklı olabilir
  Opus 4.7’nin, Opus 4.6 ile aynı çıkarım yolunu kullanmadığını varsayıyorum
  Artificial Analysis Intelligence Index sonuçlarını beklemek gerekiyor

  • İç benchmark’larda Opus 4.7 %50 daha ucuzdu ve performans puanı %80’di (önceki %60’a karşı)
  • Yazı başlığını “Claude Opus 4.7 costs 20–30% more per session” ifadesinden daha nötr olacak şekilde düzelttim
  • 28 görevlik karşılaştırma deneyi sonucuna göre 4.7, eski 4.6 sürümüyle benzer maliyette ve yeni 4.6’dan yaklaşık %20 daha pahalı
  • Kişisel verilerime göre 4.7’nin maliyeti 4.6’dan daha yüksek, performans artışı ise belirsizdi
  • Resmî duyuru grafiğinde de “strictly better” iddiasının dayanağını görüyorum

• Dün Opus kullanırken inanılmaz iyiydi ama bugün basit işlerde bile sürekli hata yapıyor
  Aynı problemi üçüncü kez belirtmek zorunda kaldım, oturumlar sık sık kopuyor ve compaction aşırı sık yaşanıyor
  Sonunda Sonnet’e dönmeye karar verdim

  • Bu bir bug değil, hesaplama yükünü azaltma politikası. İleride daha da kötüleşecek
  • LLM bir kişilik değil. Olasılık dağılımından örnekleme yapıldığında kötü oturum çıkma olasılığı er ya da geç %100’dür. Bağlamı sıfırlayıp yeniden denemek gerekir
  • Ben de son zamanlarda Opus 4.7 kullanırken sık sık berbat sonuçlar görüyorum. Modelin kendi hatasını kabul edip yeniden denemesi acı bir ironi gibi geldi

• Son zamanlarda sık sık aklıma gelen soru şu: “Gerçekten daha güçlü modellere ihtiyacımız var mı?”
  Sektör performans yarışına fazla kapılmış durumda ve verimlilik ile sürdürülebilirliği gözden kaçırıyor
  Bundan sonra asıl önemli yönün, 0.5B–1B parametreli modelleri belirli görevler için optimize etmek olduğunu düşünüyorum

  • Ben de Sonnet 4.6’yı yerelde çalıştırabilsem fazlasıyla memnun olurdum
    CPUs Aren’t Dead yazısında anlatıldığı gibi, Google’ın Gemma 4 E2B modeli telefonda bile çalışıyor ve GPT-3.5-turbo’yu geçiyor
    Artificial Analysis Intelligence Index verilerine göre en yeni 2B modeller, 3–4 yıl önceki 175B modellerle benzer performans veriyor
    Gemma 4 E4B bazı durumlarda GPT-4o’yu da geçiyor
    Bu gidişle yakında dizüstü bilgisayarda bile en üst seviye modeller çalıştırabileceğiz
  • Birçok kişi Sonnet 4.6’nın Opus 4.5 seviyesinde performans vermesini bekliyordu ama gerçekte durum öyle çıkmadı
  • Verimlilik para kazandırmıyor. Büyük LLM şirketlerinin çıkarı, çıkarım maliyetlerini yüksek tutmak yönünde
    “Yeni model çıldırmış” tarzı tanıtımlar sonuçta FOMO pazarlaması
  • Herkesin gelişmiş bir hesap makinesine ihtiyacı yok. Önemli olan gereken seviyede aracı seçmek
  • Ama “tembel ve hatalı model” ile yetinilemez. Bunu çözen laboratuvar belirleyici üstünlüğü ele geçirecek

• Hindistan’ın Kalküta kentindeki atıştırmalık satıcıları, hammadde fiyatları artsa da fiyat yükseltemeyince boyutu küçülterek karşılık verdi
  İnsanların psikolojik uyumu da böyle işliyor

  • Dünyanın her yerinde benzer durum var. Atıştırmalık paketleri aynı kalıyor ama içeriği azalıyor. Pringles kutuları bile incelip kısalıyor
  • Bu olguya Shrinkflation deniyor

• Anthropic, 4.7 ile birlikte xhigh modunu yeni ekledi
  max modu çok token tüketebiliyor ve aşırı çıkarıma yol açabiliyor; bu yüzden çoğu durumda xhigh öneriliyor
  Ayrıntı için resmî belgelere bakılabilir

  • xhigh seviyesini ekleyip max’i iyice uzağa itmeleri, tam bir “this one goes to 11” hissi veriyor

• Gerçek kod üzerinde Opus 4.7 yaklaşık %30 daha fazla token kullandı
  Esas soru, “4.7, 4.6’ya kıyasla hangi yeni yeteneği getiriyor?”
  Karar vermek için henüz erken; ama değer katıyorsa maliyet artışını kabul edebilirim

  • Tartışmada ilginç olan nokta şu: birçok kişi yeni modelin peşinden gidiyor ama Sonnet 4.6 tek başına bile yeterince verimli olabilir
    İş kapsamı dar tutulursa inceleme ve yönetim kolaylaşır, küçük diff’lerle hızlı düzeltme yapılabilir
    Copilot token tüketimi 7 kat artarsa bu kez iş akışı kopukluğu yaratabilir
  • Son dönemde 4.6’nın performansının düştüğüne dair çok sayıda şikâyet var
  • 4.6’nın ne kadar daha kalacağını bilmiyorum. Kurumsal kullanıcılar için biraz daha sürer ama bireysel abonelerin yakında seçim hakkını kaybedeceği anlaşılıyor