Opus 5.5'in daha ucuz cache okumaları bir geliştiricinin text-to-SQL maliyet hesabını alt üst ediyor

Ne oldu

dev.to'da yazan bir geliştirici, Claude Opus 5.5'in ardından bir text-to-SQL asistanının maliyet hesaplarını yeniden yaptı ve tek bir fiyatlandırma kaleminin — daha ucuz prompt cache okumalarının — mimari bir kararı tersine çevirmeye yettiği sonucuna vardı. Gönderiye göre yeni modelde cache okumaları milyonda token başına 0,20 dolar; Opus 5'teki 0,50 dolardan %60 düşüş. Input 5 dolardan 4 dolara, output 25 dolardan 20 dolara, beş dakikalık cache yazımı ise 6,25 dolardan 5 dolara iniyor.

Yazarın Aria adını verdiği asistan, CRM agent'larının düz İngilizce sorular sorup canlı SQL'den yanıt almasını sağlıyor. Prompt'ları küçük tutmak için veri üzerinden değil, şemanın dokümantasyonu üzerinden retrieval çalıştırıyor: tabloların, kolonların ve enum değerlerinin yaklaşık 90 düz İngilizce açıklaması embedding'leniyor ve pgvector ile aranıyor; her soruda modele yalnızca en alakalı beş doküman, yaklaşık 1.100 token gidiyor. Tam semantik katman ise yaklaşık 20.000 token.

Yeniden yapılan hesap

Gönderi, prompt'un şema kısmı için iki tasarımı karşılaştırıyor. A seçeneği yalnızca retrieval ile seçilen en iyi beş dokümanı gönderiyor; bunlar her soruyla değiştiği için cache'lenemiyor. B seçeneği her istekte tüm semantik katmanı cached prefix olarak gönderiyor.

Yazarın varsayımlarıyla — 40 agent'tan günde 800 soru ve beş dakikalık cache iş günü boyunca sıcak kaldığı için günde yaklaşık 10 cache yazımı — sonuçlar model nesilleri arasında ciddi biçimde değişiyor. Opus 5'te tam şema yaklaşımı günde 9,25 dolara karşı retrieval için 4,40 dolar tutuyordu; 2,1 katlık bir fark. Opus 5.5'te bu 4,20 dolara karşı 3,52 dolara, yani 1,2 kata iniyor. Yazar soru başına 0,0044 ile 0,0053 dolar hesaplıyor; bu da 22 günlük bir ayda kabaca 77 dolara karşı 92 dolar demek.

Yazara göre bu marjda artık maliyet sorunu çözmüyor; çözen şey doğruluk — ve o hiç ölçülmemişti. Gönderi retrieval'ın gerçek dezavantajlarına dikkat çekiyor: her sorudan önce fazladan bir ağ hop'u ve embedding aramasının sorgunun bağlı olduğu tek dokümanı kaçırma riski. Yazarın örneği, "stale leads" hakkında bir sorunun last_activity_at kolonunu açıklayan dokümanı yüzeye çıkaramaması; bu da SQL'i üretim daha başlamadan yanlış kılıyor. Muhtemel son durum hibrit bir model: statik cached bir şema artı kullanıcı geri bildirimlerinden yükseltilmiş, retrieval ile gelen örnek soru-SQL çiftleri.

Migration kılavuzundaki iki breaking change

Gönderi ayrıca Opus 5.5 migration kılavuzundaki, text-to-SQL kurulumlarına doğrudan denk gelen iki değişikliğe işaret ediyor.

Birincisi, tool_choice değerlerinden tool veya any artık 400 hatası döndürüyor. Bu tür sistemlerin çoğu modelin hafızasından yanıt verememesi için onu bir run_sql aracını çağırmaya zorluyor; önerilen çözüm tool_choice: auto ile aracı strict olarak işaretlemek ve prompt'ta ne zaman kullanılması gerektiğini belirtmek. Yazar mevcut güvenlik önlemlerini — yalnızca-SELECT doğrulaması, JWT'den enjekte edilen agent kimliği ve salt-okunur Postgres rolü — değiştirmeden bırakıyor; gerekçesi, modeli yükseltmenin güvenin nereye yerleştirildiğini kaydırmaması gerektiği.

İkincisi, konuşmaların append-only olması bekleniyor. Opus 5.5'te Thinking her zaman etkin ve kılavuza göre, sistem prompt'u, araçlar veya önceki mesajlarda bir düzenlemeden sonra bir thinking bloğunu yeniden oynatmak daha yeni hesaplar için varsayılan olarak 400 döndürüyor. Bu, Aria'nın mevcut tasarımıyla çelişiyor; çünkü asistan her turda sistem prompt'unu taze bir retrieval şema dokümanı kümesiyle yeniden kuruyor. Gönderi uyumlu iki yol öneriyor: retrieval ile gelen dokümanları her yeni kullanıcı turuna taşımak ya da sistem prompt'unu statik yapmak — ki bu yine tam şema seçeneği oluyor.

Neden önemli

Bu bir geliştiricinin zarf arkası analizi, bir benchmark değil; yazar da bunu açıkça belirtiyor. Ama yakaladığı yön daha geniş: fiyatlandırma ve API kısıtlamaları aynı mimariye doğru itiyor — büyük ve nadiren değişen bağlam statik cached bir prefix'te duruyor, yeni bağlam ise yalnızca eklenerek geliyor. Cache okumaları input fiyatlarına göre düşmeye devam ederse, salt token tasarrufu için kurulan retrieval katmanları ana gerekçelerini yitiriyor; geriye ise ampirik bir soru kalıyor — modele beş alakalı tablo mı yoksa on beşinin tamamı mı gösterildiğinde daha iyi SQL yazıyor. Yazar bunu, iki tasarım arasında satır seviyesinde sonuçları, latency'yi ve bildirilen cache-hit kullanımını karşılaştıran 30 örneklik bir değerlendirmeyle yanıtlamayı planlıyor ve sayıları yayınlamayı vaat ediyor.