Uber'in AI bütçesini coding agent'lerde tükettiği iddia ediliyor; nedeni input token'ları

Uber'de bildirilen bir bütçe aşımı

AI agent'lar için bir memory katmanı geliştiren Sentra adlı girişimin dev.to'daki bir yazısı, Uber'in CTO'sunun şirketin 2026'nın ilk birkaç ayında AI bütçesini tükettiğini, ana sürücünün de coding agent kullanımı olduğunu söylediğini aktarıyor. İddia ikinci elden — yazar, sözün kendilerine doğrudan değil, başkası tarafından aktarıldığını belirtiyor — ve birincil bir kaynak verilmemiş; bu yüzden doğrulanmış bir rakam değil, doğrulanmamış bir anlatı olarak okunmalı. Yazıda Uber, token maliyeti sınırlarına aleni şekilde çarpan ilk büyük mühendislik organizasyonu olarak çerçeveleniyor ve anekdotu doğrulama olmasa bile yararlı kılan da bu çerçeve: anlattığı maliyet örüntüsü, agent filosu çalıştıran her ekibin kendi faturalarıyla karşılaştırabileceği bir örüntü.

Para aslında nereye gidiyor

Yazının büyük kısmı aritmetikten oluşuyor. Ağustos 2026 itibarıyla Anthropic'in yayımladığı milyon token başına ücretleri kullanarak — gönderide Claude Fable 5 için input 10 dolar, output 50 dolar; Opus 5 için 5 ve 25 dolar; Sonnet 5 için 2 ve 10 dolar; Haiku 4.5 için 1 ve 5 dolar listeleniyor — küçük bir filo modelleniyor: beş agent, agent başına günde 200 model çağrısı, çağrı başına 20.000 input ve 1.500 output token, 30 gün boyunca. Bu, 45 milyon output token'a karşı toplam 600 milyon input token, yani Opus fiyatlandırmasıyla ayda 4.125 dolar demek; faturanın yaklaşık %73'ü input'tan geliyor.

Yazarın vardığı sonuç şu: agent harcamasına hâkim olan, modellerin ürettiği şey değil, her çağrıda yeniden gönderilen context; maliyet kontrolü çabalarının çoğu ise bu orandaki daha küçük output tarafını hedefliyor.

Etkiye göre sıralanmış dört kaldıraç

Gönderi dört azaltma kaldıracını sıralıyor:

• Prompt caching fiyatı düşürür, hacmi değil. Gönderideki rakamlara göre cache okumaları temel input ücretinin 0,1 katına faturalanıyor; yazmalar ise beş dakikalık pencere için 1,25 kat, bir saatlik için 2 kat. İşlenmiş örnekte bu, kabaca %9 tasarruf sağlıyor. Yazar bir uyarıya dikkat çekiyor: caching, cache'lenen içeriğin hâlâ doğru olup olmadığına kayıtsız; dolayısıyla bu bir fiyat kaldıracı, asla bir doğruluk kaldıracı değil.
• Model routing en büyük kalem olarak sunuluyor. Aynı filo Opus 5 yerine Haiku 4.5 ile çalıştığında ayda 4.125 dolardan 825 dolara düşüyor. Yazar, ekiplerin buna en dirençli olduğunu ve görev zorluğuna göre, alışkanlığa göre değil, yönlendirme yapılması gerektiğini söylüyor.
• Batch API'ler asenkron her şeyin fiyatını yarıya indiriyor. Gönderiye göre iki büyük sağlayıcı da batch input ve output'a %50 indirim uyguluyor; bu da gecikmeye dayanabilen trafikte tam olarak faturanın yarısı değerinde bir yapılandırma değişikliği demek.
• Daha az context göndermek, bileşik etkisi olan tek kaldıraç olarak niteleniyor; çünkü ilk üçü token'ların fiyatını düşürürken, bu biri kaç token'a ihtiyaç duyulduğunu azaltıyor. Gönderi, toplam kabaca 7.000 token olan, ikisi çelişen dört belgelik bir retrieval paketini, geçerlilik ve kaynak bilgisi taşıyan yaklaşık 200 token'lık çözümlenmiş gerçeklerle karşılaştırıyor.

Uyarıyı hak eden bir benchmark

Dördüncü kaldıracı desteklemek için yazar, Sentra'nın Terminal-Bench 2.1 üzerindeki kendi değerlendirmesine atıfta bulunuyor: görev kapsamlı bir memory katmanı verilen agent'lar 445 denemede %41,2 daha az token kullanırken model maliyeti %72,6 düştü; doğruluk ise ortalama ödülde %83,37'den %88,31'e yükseldi. Gönderinin kendisi bunun kendi ölçümü olduğunu belirtiyor ve okurlardan rakama güvenmek yerine metodolojiyi incelemesini istiyor. Ayrıca Sentra'nın tam da bu kaldıracın ima ettiği türde bir memory ürünü sattığınot edilmeli; yani benchmark, yazıdaki en az doğrulanabilir iddia için satıcı tarafından sağlanan kanıt olarak okunmalı. Maliyetin token kullanımından daha hızlı düşmesine dair yazarın açıklaması — daha az yeniden deneme ve daha kısa çalışma sürelerinin daha küçük yüklerle bileşik etki yaratması — makul ama beyana dayalı.

Pratik bir kontrol listesi

Gönderinin ekiplere sıralı önerileri şunlar: hangisinin baskın olduğunu bulmak için faturayı dört kovaya bölün (system prompt, retrieved context, conversation history, output); her istekte faturalanan system prompt'taki ölü ağırlığı silin; stabil önekler için caching'i etkinleştirin ve değişken token'ları prompt'un sonuna taşıyın; conversation history'yi sınırlayın, çünkü her turda tam transkripti yeniden göndermek oturum boyunca maliyeti kuadratik biçimde büyütür; kolay işleri daha küçük modellere yönlendirin; sonra da agent'lerin her oturumda aynı context'i yeniden türetip türetmediğini kontrol edin — hiçbir caching miktarı bunu düzeltmez.

Neden önemli

Uber anlatısı kabaca doğruysa bile, bu, mühendislik organizasyonlarının henüz modellemeye başladığı bir bütçe kaymasının erken bir kamusal önizlemesi: harcamanın, coding agent'lerin sürüklediği ölçümlü token tüketimine, baskın maliyet olarak input context ile kayması. Gönderi, token kullanımını en üst düzeye çıkarıp değerin ardından geleceğine güvenen strateji için 'tokenmaxxing' terimini türetiyor ve bunun aptalca olmadığını — gerçekten yararlı araçlara karşı rasyonel bir ilk tepki olduğunu — ancak harcamanın hacimden çok alaka'ya yönelmesi gerektiğini savunuyor. Bir memory satıcısının ürün tanıtımını maliyet krizi gibi gösterdiği yönündeki sinik okuma, temeldeki aritmetiği yanlış yapmıyor: input ağırlıklı maliyet oranı ile routing ve batching kaldıraçları, faturası olan herkes tarafından yayımlanmış fiyatlandırmayla doğrulanabilir.