PennyWyze, testlerinizden geçen en ucuz Claude tier'ını bulan açık kaynaklı bir CLI

PennyWyze ne yapıyor

OSLabs'tan üç mühendis, dar ama maliyetli bir soruya cevap veren açık kaynaklı bir komut satırı aracı olan PennyWyze'ı yayınladı: Belirli bir üretim görevi için hangi Anthropic model tier'ı — Opus, Sonnet veya Haiku — doğruluk gereksinimlerinizi hâlâ karşılayan en ucuz seçenek?

Ekibin dev.to yazısına göre araç iki girdi alıyor: Üretimde zaten Claude'a gönderdiğiniz prompt ve her satırında bir JSON object olacak şekilde, doğruluğundan emin olduğunuz cevaplarla eşleştirilmiş gerçek girdilerden oluşan bir golden dataset. Bir geçme oranını (pass rate) belirtiyorsunuz ve PennyWyze her örneği gerçek Anthropic API üzerinden her tier ile değerlendiriyor, yanıtları notlandırıyor ve her çağrının maliyetini tahmin yerine API'nin geri bildirdiği token sayılarına göre hesaplıyor.

Bir denetim nasıl çalışır

Komut şöyle: pennywyze audit --prompt prompt.md --dataset dataset.l --pass-rate 90. Çıktı, her modelin doğruluğunu ve gerçek hacminizdeki tahmini aylık maliyetini listeliyor, ardından eşiğinizi geçen en ucuz tier'ı belirtiyor.

Ekibin paylaştığı bir çalıştırma sonucu kazancı gözler önüne seriyor: Opus, 50 üzerinden 49 puanla ayda tahmini 205,94 dolar; Sonnet, 50 üzerinden 48 puanla 77,30 dolar; Haiku ise 50 üzerinden 49 puanla 26,26 dolar tutuyordu. Karar, Haiku'ya geçip ayda yaklaşık 179,68 dolar tasarruf etmekti — ve denetimin kendisi çalıştırmak için yalnızca 0,15 dolar maliyetlidı. Dikkat çekici olan, Sonnet'in iki alternatifinden de düşük puan alması ve Haiku'nun neredeyse üç katı maliyete sahip olmasıydı; yani o görevde en ucuz tier'ın üzerinde bir seçeneği haklı çıkaracak bir doğruluk kazanımı yoktu.

Araç ayrıca, bir modelin istenen geçme oranına matematiksel olarak ulaşamayacağı anlaşılınca onu çağırmayı erken durduruyor ve kesinleşmiş bir sonucu doğrulamak için API bütçesini harcamıyor. Kurulum npm install -g pennywyze, ayrıca bir .env dosyasında Anthropic API anahtarı gerekiyor.

Kasıtlı olarak katı notlandırma

Notlandırma, normalizasyon sonrası tam eşleşmeye dayanıyor. Modelin cevabından ve beklenen cevaptan çevredeki tırnak işaretleri, code fence'ler, büyük/küçük harf farklılıkları ve sondaki noktalama işaretleri ayıklanıyor, ardından tam eşitlik için karşılaştırılıyor. billing beklenirken Billing yanıtı geçiyor; I think the answer is billing ise kalıyor. Ekip bunun bilinçli olduğunu söylüyor — uygulamanızın yalın bir kategoriye ihtiyaç duyduğu bir durumda cevabı bir cümlenin içine gömen bir model, bulanık eşleştirmeyle gizlenmesi gereken bir notlandırma ayrıntısı değil, gerçek bir üretim hatasıdır.

Bu katılık aynı zamanda mevcut kapsamı da tanımlıyor. dev.to yazısına göre PennyWyze, tek bir doğru cevabı olan görevlere — ticket sınıflandırma, alan çıkarma (field extraction), yönlendirme, intent detection — uygun ve henüz e-posta tasarlama veya belge özetleme gibi uçsuz bucaksız üretim görevlerini karşılamıyor. LLM-as-judge notlandırması yol haritasında yer alıyor.

Kaputun altında, denetim döngüsü iki küçük ve değiştirilebilir sözleşme üzerine kurulu: bir prompt ve bir soru alıp bir cevap ile token maliyetini döndüren bir ModelProvider ve cevapları beklentilere göre notlandıran bir Scorer. Ekip, yeni bir provider eklemenin — örneğin Anthropic dışı bir tier'ın — döngüye dokunmak yerine tek bir yeni dosya yazmak anlamına geldiğini belirtiyor.

Neredeyse yapmayacakları bir fikir

dev.to yazıları dolambaçlı bir başlangıç hikâyesi anlatıyor. Ekip başlangıçta, sohbet uygulamalarının her mesajla tüm geçmişlerini yeniden göndermesini engelleyecek bir konuşma belleği katmanı önerdi. Ancak Mem0, Zep ve Letta zaten bu sorun üzerinde çalışıyordu ve Anthropic otomatik context compaction özelliğini yayınlamaya başlamıştı. Fikri terk ettikten sonra bir ekip üyesi ertesi gün token verimliliği ana temasına farklı bir açıdan yaklaşıp döndü: önce hangi modeli kullandığınızı denetleyin.

Aracı geliştirmek, Claude ile entegrasyon yapan herkesin bilmesinde fayda olan bazı tuhaflıkları gün yüzüne çıkardı. Opus'un adaptive thinking özelliği, API yanıtında text bloğundan önce bir thinking bloğu yerleştirebiliyor; bu, notlandırıcının kısa bir süre cevap yerine iç bir akıl yürütme parçasını puanlamasına neden oldu. Çözüm, sıfırıncı konumu varsaymak yerine type === "text" olan bloğu aramak oldu.

Neden önemli

Üretimdeki yapay zekâ çalışmalarının çoğu uçsuz bucaksız akıl yürütme değil, sınıflandırma ve yönlendirmedir; ancak ekipler bir özellik yayınlarken rutin biçimde en pahalı modele yöneliyor ve bu kararı bir daha gözden geçirmiyor. Seçimi doğrulamak normalde eksiksiz bir değerlendirme altyapısı kurmayı gerektirir — bir dataset, bir notlandırma sistemi ve aynı görevi birden çok modelde çalıştırmanın bir yolu — ve çoğu ekip yalnızca tek bir maliyet sorusunu yanıtlamak için bundan vazgeçer. PennyWyze bu altyapıyı paketler ve kontrolü sentiler seviyesinde fiyatlar. Ekibin kendi denetiminin gösterdiği gibi, cevap tek bir prompt'ta ayda yüzlerce dolar tasarruf olabilir.