· kaynak dev.to (home feed)
Geliştirici denetimi: üçüncü taraf Claude API proxy'leri prompt caching'i sessizce bozabiliyor ya da sahtesini yapabiliyor
Anthropic API'si için on üçten fazla üçüncü taraf aktarıcısını denetleyen bir geliştirici, birçoğunun prompt caching'i bozduğunu ya da sahte olarak sunduğunu söylüyor ve herhangi bir sağlayıcıyı test etmek için iki isteklik bir yöntem paylaşıyor.

Anthropic'ın API'si için on üçten fazla üçüncü taraf aktarıcıyı denetlediğinde birçoğunun, yoğun Claude Code ve Cline kullanıcıları için maliyetleri düşüren prompt caching'i sessizce bozduğunu ya da tamamen sahtelediğini söyleyen bir geliştirici. Dev.to'daki bir yazıda Denny Ho, dört yaygın hata modunu, caching'in ne zaman kârlı olmaktan çıktığını gösteren başabaş hesabını ve herhangi bir sağlayıcıyı denetlemek için iki isteklik bir testi ele alıyor.
Prompt caching'in çalışması gereken şekilde çalışması
Yazıya göre Anthropic, bir cache kontrol noktası yazmak için taban giriş fiyatının 1,25 katını, geri okumak için ise 0,1 katını alıyor; bu da büyük bağlamlarda %90'a varan indirimler anlamına gelebilir. Burada iki kısıt önemli. Cache'ler, upstream hesabı başına tutulur ve beş dakikalık bir time-to-live süresi vardır; ayrıca bir cache isabeti için prompt önekentinin bayt bayt eşleşmesi gerekir. Ho'nun tanımladığı her hata modu bu kısıtlardan birini sömürüyor.
Proxy'lerin caching'i bozduğu dört yol
Ho, sorunları dört tuzağa grupluyor:
- Oturum afiniteşi olmadan anahtar havuzlama. Bütçe dostu aktarıcılar istekleri genellikle bir upstream API anahtarı havuzu arasında döndürür. Her anahtar kendi cache'ini tuttuğundan, soğuk bir anahtara düşen istek yeni bir yazma tetikler: her tur, 0,1x okuma yerine 1,25x yazma ücreti öder; bu da tur başına cache'siz fiyatın %125'i anlamına gelir.
- cache_control bloğunun kaldırılması. Bazı satıcılar tam uyumluluk iddia ederken derin indirimler reklam eder, ancak proxy'leri, yönlendirmeden önce caching yönergesini, caching'i hiç desteklemeyen daha ucuz kanallara iletilmeden önce çıkarır; sonra standart cache'siz oranlarla faturalandırır ve haksız bir kâr cebe atar.
- Sahte kullanım telemetrisi. Proxy, dönen JSON'u kontrol ettiği için bazıları prompt öneklerini bellek hash'leriyle inceler ve tekrar tespit edildiğinde usage nesnesinin cache_read_input_tokens alanına şişirilmiş sayılar enjekte eder. İstemci cache isabeti raporlarken arka uç tam giriş oranlarıyla faturalandırır.
- System prompt değişikliği. System prompt içine dahili izleme etiketleri, güvenlik prompt'ları ya da dinamik zaman damgaları enjekte eden aracı geçitler, birebir önekt gereksinimini bozar. Değişen tek bir bayt cache kırılma noktasını geçersiz kılar ve bağlamın baştan okunmasını zorunlu kılar.
Caching'in kendini ödemesi ne zaman durur
Yazıdaki aritmetik basit: yazma 1,25, okuma 0,10 ve cache'siz giriş 1,0 iken, H isabet oranında tur başına ortalama maliyet 1,25 x (1 - H) + 0,10 x H olur. Bunu 1,0'a eşitlemek başabaş noktasını yaklaşık %21,7 isabet oranına koyar. Sezgilere aykırı sonuç şu: bir proxy'nin kararsız yönlendirmesi isabet oranını yaklaşık %22'nin altına düşürürse, prompt caching tasarruf ettiğinden fazla maliyete neden olur ve kullanıcılar onu devre dışı bırakarak daha iyi eder.
Bir sağlayıcı nasıl denetlenir
Test, yaklaşık iki saniye arayla gönderilen, ephemeral caching için işaretlenmiş 1024 tokendan büyük statik bir önekle iki ardışık istek gerektirir. İlk yanıt 1024'ün üzerinde cache_creation_input_tokens raporlamalı; ikincisi 1024'ün üzerinde cache_read_input_tokens raporlamalı ve belirgin şekilde daha düşük gecikmeyle dönmelidir. Belirleyici adım faturalandırma panelinde gerçekleşir: ikinci istek, standart giriş fiyatlandırması yerine 0,1x okuma oranıyla ölçülmelidir. Proxy döndürdüğü usage nesnesini kontrol ettiğinden, sahte telemetriyi yakalayan şey faturadır.
Yazıda ayrıca iki sonda isteğini herhangi bir sağlayıcı uç noktasına gönderen ve her tur için gecikmeyi usage alanlarının yanında yazdıran kısa bir Python betiği yer alıyor. Testin kendisinin ötesinde Ho, istek kimlikleri, görünür rota değişimleri ve ayrıntılı cache okuma/yazma sayaçları dahil olmak üzere istek başına şeffaflık talep etmeyi ve kullanım kayıtlarını doğrularken 1 ila 5 dolarlık bir depozitle başlamayı öneriyor.
Dikkat edilmesi gereken bir uyarı
Yazar ticari bir çıkar bildiriyor: denetimler, oturum yapışkanlığına sahip, OpenAI ve Anthropic uyumlu bir yönlendirme geçidi olan API Route'u geliştirirken yapılmış. Belirli sağlayıcılar adlandırılmadığından bulgular, doğrulanmış bir araştırma değil tek bir satıcının anlatısı gibi okunuyor. Yine de, hata modları yukarıda açıklanan caching kısıtlarından mekanik olarak kaynaklanıyor ve denetim yöntemi, onu kim yayımladığından bağımsız olarak kendi başına ayakta duruyor.
Neden önemli
İndirimli bir üçüncü taraf aktarıcı üzerinden Claude Code ya da Cline çalıştıran herkes için prompt caching genellikle yönetilebilir bir fatura ile pahalı bir fatura arasındaki farkı belirliyor ve bu hata modlarının her biri istemciden görünmez: CLI her iki durumda da cache isabeti gösteriyor ve açığı ortaya çıkaran tek şey faturayla çapraz kontrol. Daha geniş ders Anthropic'ın ötesine uzanıyor: bir proxy'nin döndürdüğü kullanım telemetrisi bir iddiadır, kanıt değil. İstek kimlikleri, istek başına sayaçlar ve faturalanan tutarlar tek gerçek veridir ve birkaç sent maliyetindeki iki isteklik test, gerçek harcama yapmadan önce ucuz bir sigortadır.
- #anthropic
- #api
- #llm
- #prompt-caching
- #cost-optimization
İlgili yazılar
- Anthropic, LLM yanıtlarını doğrulamaya yönelik zkSNARK sistemi FlashProve'u açık kaynak yaptı
- Ücretsiz Qwen modeli bir laptop üzerinde ham AI ağırlıklarını yorumladı, Simon Willison'a göre
- Tencent'in Hy4'ü, açık ağırlıklı sürüm öncesinde amiral gemisi modeline görü ve bilgisayar kullanımı yetenekleri ekliyor