Frontier Model Token Cost: Gerçek Fiyat Neden Farklı
AgentSpace’te bir sprint kapandığında ilk baktığım yer görev panosu değil, o sprint’in token faturası oluyor. Çok-ajanlı bir sistemi işletiyorsan tokens×price çarpımını kafanda hızlı yapmak alışkanlık haline gelir: fiyat sabit, tek değişken üretilen token sayısıdır sanırsın. Ama bu mimaride kaçınılmaz bir kör nokta var — worker’ın ürettiği aynı TypeScript dosyası, hangi tokenizer’dan geçtiğine göre baştan farklı bir sayıya dönüşüyor; fiyat sticker’ı hiç kıpırdamadan.
Playcode’un blog yazısı tam bunu ölçmüş: aynı TypeScript dosyası GPT-5.x’te 681 token, Claude’un yeni tokenizer’ında 1.178 token — fiyat farkına gelmeden %73 daha fazla. Frontier model token cost, yani gerçek fiyat sorusunun cevabı sticker’daki $/Mtok değil, tokenizer’ın içeriği kaç parçaya böldüğü.
Bizim notumuz: iki katman üst üste biniyor
AgentSpace worker’ları Claude ile koşuyor, ürettikleri kodun büyük kısmı da TypeScript/JavaScript. Playcode’un bulduğu en geniş fark tam olarak bu iş yüküyle örtüşüyor. Bu bize şunu gösterdi: sprint sonu tokens×price hesabımız tek katmanlı değil, iki katmanlı yanılıyor olabilir. Birinci katman bu yazının konusu — aynı fiyata, tokenizer daha fazla token üretebiliyor. İkinci katman ise daha önce ayrı yazılarda ölçmeye çalıştığımız tool-call/retry overhead’i; ajan bir görevi tamamlarken tool şeması, ara JSON sonuçları ve yeniden denemeler faturaya ayrıca biniyor.
Bugüne kadar sprint başına toplam token faturasını izliyorduk ama bunun ne kadarının tokenizer kaynaklı “aynı kodun daha fazla parçaya bölünmesinden”, ne kadarının fan-out/retry trafiğinden geldiğini ayrıştırmamıştık. Playcode’un yöntemi — sağlayıcının count_tokens endpoint’i ile gerçek faturalanan usage.input_tokens’ı karşılaştırmak — bu ayrımın mümkün olduğunu gösteriyor; biz bu ayrımı kendi sprint loglarımıza henüz uygulamadık.
Değişmeyecek olan şey şu: worker modelini Claude’dan başka bir şeye kaydırmayacağız. Tek bir dış ölçüm, model seçimini değiştirecek bir kanıt değil — sadece maliyet formülümüzdeki eksik bir çarpanı gösteriyor.
Bugün ne yapacağız / yapmayacağız
- Yapacağız: sprint log’una tokenizer versiyonunu da not düşmek, bir model güncellemesi geldiğinde “aynı fiyat, yeni tokenizer” ihtimalini kontrol listesine eklemek.
- Yapmayacağız: tek bir dış ölçümden yola çıkıp worker modelini değiştirmek — kendi TypeScript ağırlıklı kod tabanımızda bu farkı henüz doğrulamadık.
Okuyucu bugün ne yapsın
1. Kod tabanının dilini not et (TS/JS ise tokenizer farkı en geniş bant).
2. Sağlayıcının count_tokens / usage endpoint'inden gerçek input token sayısını çek.
3. tokens × price yerine ölçülen_tokens × price formülünü kullan.
4. Model versiyon güncellemesinde "aynı fiyat, farklı tokenizer" olup olmadığını kontrol et.$/Mtok sticker’ı okuman gereken ilk satır, son satır değil — gerçek fatura tokenizer’dan sonra başlıyor.