Hangi model, ne kadar çalışıyor?
Kısa cevap: aşağıdaki tablo, OpenRouter adlı API yönlendiricisinden geçen token ve istek trafiğinin model ve sağlayıcı dağılımını gösterir. Her gün yeniden okunur, formülleri yazılıdır, ham verisi tek bir JSON ucundan indirilebilir.
Bu tablo neyi ölçmez?
Müşterinizin ChatGPT, Gemini ya da Claude uygulamasına ne sorduğunu ölçmez. O uygulamalar bu yönlendiriciden geçmez. Burada gördüğünüz, geliştiricilerin kendi yazılımlarının içinde hangi modeli çalıştırdığıdır. İki ölçümü birbirinin yerine koymak yanlış karar üretir.
Bu ölçüm günlük tura bağlı çalışıyor ve henüz ilk anlık görüntü alınmadı. Tur tamamlandığında tablo burada görünecek. Kaynağı şimdi görmek isterseniz OpenRouter sıralamasına bakabilirsiniz.
Bu veriyi nasıl alıyoruz, neyi hesaplıyoruz?
Kaynak ve pencere
Veri OpenRouter sıralama sayfasından okunur. Sayfanın React Query durumundaki ["rankings","models",{"view":"week"}] ve ["rankings","apps"] sorgularının verisi alınır; tarayıcı çalıştırılmaz. Kaynağın kendi tanımıyla bu görünüm, en son tamamlanmış günlük kovayla biten yedi günlük bir penceredir — yani satırdaki tarih tek bir günün değil, pencerenin bitiş günüdür.
Tazeleme ve hata hâli
Günlük ölçüm turumuzun sonunda otomatik olarak yeniden okunur ve kaydedilir. Bu bir sözleşmeli API değil, sayfa ayrıştırmasıdır: kaynak yapısını değiştirirse okuma sessizce boşa düşmez, hata fırlatır. O durumda önceki kayıt korunur, sayfadaki ölçüm anı eskimeye başlar ve üç günü geçerse künyenin altında uyarı çıkar. Uygulama listesi isteğe bağlıdır: yalnız o bölüm okunamazsa model tablosu etkilenmez.
Formüller
Toplama giren alanlar kaynağın kendi alan adlarıyla yazıldı. Payda her zaman listenin toplamıdır, platformun tamamı değil.
token = total_prompt_tokens + total_completion_tokens
token payı = token ÷ Σ(liste) token × 100
istek = count
istek payı = istek ÷ Σ(liste) istek × 100
token/istek = token ÷ istek
istem : cevap = total_prompt_tokens ÷ total_completion_tokens
akıl yürütme % = total_native_tokens_reasoning ÷ total_completion_tokens × 100
önbellek % = total_native_tokens_cached ÷ total_prompt_tokens × 100
7 günlük değişim = kaynağın change alanı (biz hesaplamıyoruz)- Payda sıfırsa bölme yapılmaz: sonuç “—” olur. Sıfır ile “veri yok” sayfada hiçbir yerde aynı görünmez.
- Araç çağrısı hata oranı HESAPLANMIYOR. Kaynak “araç çağrısı sayısı” ile “hata dönen istek sayısı” veriyor; bu ikisinin oranı anlamlı bir hata oranı değil ve doğru payda (araç çağrısı yapan istek sayısı) kaynakta yok. Ham sayılar JSON ucunda durur, sayfada türetilmiş oran gösterilmez.
- Aynı model birden çok variant ile geldiyse token ve istek toplanır, variant sütununda ikisi birden yazılır; o satırda “7 günlük değişim” gösterilmez çünkü hangi variant’a ait olduğu belirsizdir.
- Kaynağın döndürdüğü liste 7 günlük değişime göre azalan sırada gelir. Bu listeye hangi modellerin girdiğini kaynak seçer; sayfadaki hiçbir sayı o seçime dair bir varsayıma dayanmaz, her oran yalnızca listenin içindeki toplamdan çıkar.
- Sayılar Türkçe biçimlenir (binlik nokta, ondalık virgül). Ham JSON’da ise ondalık nokta ile, işlenmemiş hâlde durur.
Bunun sizin için anlamı ne?
- Model tarafı hızlı değişiyor. Bugün trafiğin başında olan model üç ay sonra listede olmayabilir; tek bir modele göre yazılmış içerik bu yüzden kırılgandır.
- Sizin görünürlüğünüz bu tablodan çıkmaz. Görünürlük, asistanlara gerçek sorular sorularak ölçülür; bu sayfa yalnızca model tarafındaki hareketi gösterir.
- Bot erişimini tek bir sağlayıcıya göre açmayın. Sıralama değiştikçe hangi tarayıcının sitenizi okuduğu da değişir.
- İstek başına token yüksekse orada uzun bağlam vardır: o iş yükü sitenizin tamamını okuyan bir ajan olabilir. Sunucu tarafı hız sınırlarınızı bu ihtimale göre ayarlayın.
Bu veriye dair sorular.
Rapor ücretsiz, Yanıt 14 gün deneme.
Alan adınızı girin, şok raporunuzu görün. Sürekli ölçüm ve yapılacaklar için hesap açın; kart gerekmez.