17 Ağustos 2026'da OpenRouter, kendi önizleme modellerinden birinin sessiz sedasız ayda yaklaşık 6,2 bin dolara mal olduğunu açıkladı. Bu rakam, kuruluşun harmanlanmış ortalama maliyetinin yaklaşık 25 katıydı ve harcamanın %98'i tek bir batch-pipeline API anahtarından kaynaklanıyordu. Aynı gün kullanıma açılan Activity dashboard, tam da bu tür hataları aylar sonra değil, birkaç dakika içinde görünür kılmayı amaçlıyor. Arayüz tarafı oldukça başarılı: harcama, token kullanımı, önbellek isabet oranı ve istek bazında ayrıntılar tek yerde toplanıyor. Arkasındaki beta Analytics API ise daha ham bir deneyim sunuyor; kritik noktaları aşağıda tek tek ele aldık.
6,2 Bin Dolarlık Ders: OpenRouter Activity Dashboard Neleri Yakalar?
Lansman yazısındaki kurum içi örnek, bu araçların hangi sorunu çözmek için geliştirildiğini net biçimde gösteriyor. Bir önizleme modeli, bir ay içinde 250 milyon token için 6.185 dolar harcadı. Bu, milyon token başına yaklaşık 24,7 dolara ve %7,6 önbellek isabet oranına denk geliyordu. API anahtarına göre yapılan incelemede ise faturanın 6.067 dolarlık kısmının 127 milyon token ve 37 bin istekle batch-pipeline anahtarında toplandığı görüldü. Yani yüksek hacimli, düşük karmaşıklıktaki toplu işler için yaklaşık 48 dolar/Mtok ödeniyordu. Çözüm, modeli tek satırda değiştirmek oldu (maliyet kontrolü rehberindeki ayrıntılı açıklama).
Dashboard ile birlikte gelen diğer araçlar şöyle: özel sorgular için Explore, değişimleri izlemek için Trends, prompt enjeksiyonu ve hassas veri olayları için Guardrails, istek seviyesinde günlükler, beta Analytics API ve kodlama ajanlarında kullanılabilen, kurulabilir openrouter-analytics GitHub becerisi.
Activity Sekmeleri Hangi Sorulara Yanıt Veriyor?
OpenRouter Activity dashboard menülerden çok sorular etrafında tasarlanmış. Maliyet takibinin büyük bölümünü üç sekme üstleniyor ve her biri farklı bir soruya yanıt veriyor.
Overview: Ne kadar harcadık?
Overview ekranı beş temel metrikle açılıyor: toplam harcama, istek sayısı, token hacmi, önbellek isabet oranı ve milyon token başına harmanlanmış maliyet. Her metriğin yanında mini grafik ve önceki dönemle karşılaştırma bulunuyor. Alt bölümde en fazla kullanılan kullanıcılar ve uygulamalar, modele göre harcama, OpenRouter kredileri ile tahmini BYOK harcamasının dağılımı ve prompt-tamamlama token sayıları yer alıyor. Sorunuz doğrudan “rakam ne?” ise açık bırakacağınız sekme burası.
Trends: Önceki döneme göre ne değişti?
Trends, mutlak büyüklükleri değil değişimleri sıralıyor; modeller, kullanıcılar, API anahtarları ve uygulamalar bazında çalışıyor. Kontrolden çıkan bir ajanı, yeni gözde hâline gelen bir modeli veya deneysel bir aracın bir anda varsayılan seçeneğe dönüşmesini yakalamak için tasarlanmış. Overview size bir şeyin pahalı olduğunu söyler; Trends ise pahalı hâle yeni geldiğini gösterir.
Explore: Verileri kendim nasıl kırılımlarım?
Explore, sorgu oluşturucusu olarak çalışıyor. Metrikler arasında harcama, istek sayısı, çeşitli token kategorileri, önbellek isabet oranı, milyon token başına harmanlanmış maliyet, BYOK ve kredi harcaması ile P50/P90/P99 gecikme ve aktarım hızı bulunuyor.
Gruplama aynı anda en fazla iki boyuta izin veriyor. Kullanabileceğiniz boyutlar model, sağlayıcı, API anahtarı, uygulama, kullanıcı, çalışma alanı, ülke, bölge, bağlam uzunluğu, oturum, üretim, özel kimlikler ve sınıflandırıcılardan oluşuyor. Zaman toplulaştırması dakikadan aya kadar ayarlanabiliyor; grafikler çubuk, çizgi veya nokta grafiği olarak gösterilebiliyor. Her grafik özel olarak ya da kuruluş genelinde kaydedilebiliyor. İki önemli not var: üçüncü bir gruplama boyutu eklerseniz sorgu doğrudan reddediliyor; günlüklerde prompt ve tamamlama içeriğini görebilmek için özel girdi/çıktı günlüklemenin istek gönderilmeden önce etkinleştirilmiş olması gerekiyor.
API'ye Dokunmadan CSV veya PDF Dışa Aktarma
Muhasebe ekibinin ya da elektronik tabloların API'ye ihtiyacı yok. Activity sayfası, aynı toplulaştırılmış verileri kod yazmadan iki formatta özet veya ayrıntılı rapor olarak dışa aktarabiliyor. Resmî dışa aktarma akışı beş adımdan oluşuyor:
- Activity sayfasını açın.
- Bir zaman aralığı ve gruplama seçin (model, API anahtarı veya oluşturan kişi).
- Sağ üst köşedeki seçenekler menüsünü açın.
- Export to… seçeneğine tıklayın.
- CSV veya PDF formatını seçin.
Varsayılan dışa aktarma; harcama, token ve istek sayılarını birlikte gösteren bir özet rapor. Ayrıntılı rapor almak için önce belirli bir metrik kartını açıp ardından dışa aktarın. Ayrıntılı sürüm, seçtiğiniz gruplamaya göre yalnızca o metriği kırılımlara ayırıyor. Dönem seçimi, alt zaman aralığını otomatik olarak belirliyor:
| Zaman filtresi | Alt zaman aralığı |
|---|---|
| 1 Saat | dakika başına |
| 1 Gün | saat başına |
| 1 Ay | gün başına |
| 1 Yıl | ay başına |
Belgelerdeki iki ince ayrıntıyı da gözden kaçırmamak gerek: Bu raporlardaki BYOK harcaması, sağlayıcıların piyasa fiyatlarına göre hesaplanan bir tahmin. Sağlayıcıya özel indirimler hesaba katılmadığı için gerçek dış faturanıza uymayabilir. Akıl yürütme tokenları, tamamlama tokenları içinde faturalandırılıyor ancak ayrı raporlanıyor. Böylece faturanın “düşünme” kısmını çift sayım yapmadan görebiliyorsunuz.
İlk Analytics API Sorgunuzu Beş Dakikada Çalıştırın
Analytics API, Explore'un hesapladığı verilerin aynısını iki endpoint üzerinden sunuyor. Ancak API açıkça beta olduğu için işe doğrudan sorguyla değil, önce keşifle başlamak gerekiyor.
Yönetim anahtarı zorunluluğu
Analytics endpoint'leri yönetim anahtarı istiyor; normal bir inference anahtarı kullanırsanız HTTP 403 alırsınız. Maliyet kontrolü rehberine göre tersi de geçerli: yönetim anahtarları model isteği gönderemiyor. Bu durum anahtar sızarsa etki alanını sınırlıyor, ancak kuruluşunuzun tüm harcama dökümünü yine de erişilebilir kılıyor. Rehberin tavsiyesi net: Bu anahtarı diğer tüm kimlik bilgileri kadar dikkatli koruyun.
Önce meta, sonra sorgu
GET /api/v1/analytics/meta, o anda desteklenen metrikleri, boyutları, filtre operatörlerini ve ayrıntı seviyelerini döndürüyor. Beta desteği değişebileceği için her otomasyon çalışmasından önce bu endpoint'i sorgulayın. Gerçek sorgu endpoint'i ise POST /api/v1/analytics/query. Belgelerdeki cURL örneği şöyle:
curl -X POST https://openrouter.ai/api/v1/analytics/query \
-H "Authorization: Bearer <management-key>" \
-H "Content-Type: application/json" \
-d '{
"metrics": ["request_count"],
"dimensions": ["model"],
"granularity": "day",
"limit": 100,
"time_range": {
"start": "2026-08-01T00:00:00Z",
"end": "2026-08-08T00:00:00Z"
}
}'
Yanıtlar satırları data.data altında, metadata bloğuyla birlikte döndürüyor. Bu blokta query_time_ms, row_count ve truncated alanları bulunuyor. Rehberde tek satırlık örnek sorguların 17 ms'de tamamlandığı belirtiliyor; yani bu çağrılar ucuz. İş akışı da mevcut kullanım maliyetlerinizin dışında ek ücret gerektirmeyen, salt okunur bir işlem olarak tanımlanıyor. Belgelenen hata durumları 400 (hatalı sorgu), 401 (kimlik doğrulama yok), 403 (yanlış anahtar türü), 408 ve 500.
Fazla Harcamayı Bulan Dört Sorgu
Resmî rehber beş tarif sunuyor. Bunları bir sıraya koyduğunuzda düzenli bir maliyet avı akışı ortaya çıkıyor.
1. En çok harcatan model hangisi? Rehberdeki ilk sorgu, total_usage, request_count, tokens_total ve cache_hit_rate metriklerini model boyutuna göre gruplayıp harcamaya göre sıralıyor:
{
"metrics": ["total_usage", "request_count", "tokens_total", "cache_hit_rate"],
"dimensions": ["model"],
"order_by": { "metric": "total_usage", "direction": "desc" },
"limit": 10,
"time_range": { "start": "2026-07-01T00:00:00Z", "end": "2026-08-01T00:00:00Z" }
}
Burada hesaplanacak temel değer, milyon token başına gerçek maliyet: total_usage / tokens_total × 1e6. Bunu harmanlanmış oranınızla karşılaştırın; boyut kullanılmadan aynı formülle hesaplanan bu oran, hangi modelin ortalamayı ne kadar yukarı çektiğini gösterir. Rehberdeki sezgisel kural da burada devreye giriyor: harmanlanmış oranın katbekat üzerinde fiyatlanan model, öncelikle incelenmesi gereken en güçlü sinyaldir. 25 katlık önizleme modeli anomalisi de bu şekilde ortaya çıktı.
2. Sorumlu API anahtarı hangisi? Tam model slug'ı üzerinde filtre uygulayıp api_key_id ile gruplama yapın. Sonuçlarda anahtar adları okunabilir etiketlere dönüştürülüyor; batch-pipeline anahtarının 6.185 dolarlık sorunun 6.067 dolarını taşıdığı da bu sayede görüldü. Çözülmüş anahtar adlarına göre filtrelemek yerine api_key_id ile gruplama yapın ve harcamayı kurum içi kayıtlarla eşleştirmek için dönen user_email alanını kullanın.
3. Bu para tam olarak neye gitti? Günlük harcamayı şu bileşenlere ayırın:
| Metrik | Anlamı |
|---|---|
usage_upstream | ham çıkarım maliyeti |
usage_cache | önbellek tasarrufu (veya önbellek yazma maliyeti) |
usage_data | genellikle negatif olan indirimler |
usage_web | web araması ek ücreti |
usage_file | dosya işleme ek ücreti |
Prompt-tamamlama oranının yaklaşık 20:1 olması, gereğinden büyük bir bağlama işaret eder. Akıl yürütme tokenlarının payı yüksekse ihtiyacınız olmayan bir “düşünme” süreci için ödeme yapıyor olabilirsiniz. Önbellek isabet oranı düşük, prompt ağırlıklı trafik en iyi önbellekleme hedefidir; oran zaten yüksekse model karmasına bakın. Prompt ağırlıklı kullanım bir istisna değil, genel eğilim: OpenRouter'ın kamuya açık programlama kategorisi verileri üzerine yapılan bir analiz, bu tokenların %93,4'ünün girdi olduğunu ölçtü.
4. Uyguladığım düzeltme işe yaradı mı? İlk sorguyu api_key_id ile gruplanmış haftalık bir zaman serisi olarak yeniden çalıştırın. Resmî örnekte batch-pipeline anahtarının harcaması 31 Mayıs haftasında 1.402,50 dolardan, 7 Haziran haftasında 11,20 dolara düşüyor. Model değişikliğinin başarılı sonucu eğimli bir çizgiden çok keskin bir düşüş olarak görünür.
İlk sorgudan sonra daha ucuz bir modele geçmeye karar verirseniz, bu kararın uygulanacağı yer OpenRouter'ın kendi yönlendirme katmanı. Otomatik ve sabitlenmiş yönlendirme arasındaki farkları OpenRouter auto router rehberimizde ele aldık.
Referansta Açıkça Yazmayan Altı Beta Sınırı
Sorgunuz doğru olduğunda API belgelerde anlatıldığı gibi çalışıyor. Aşağıdaki sorunlar da belgelenmiş durumda; ancak farklı rehberlerin dipnotlarına dağılmış hâlde bulunuyor.
- Üç boyut kullanmak 400 hatası döndürüyor. Üst sınır iki boyut;
model × key × daysorgusu için birden fazla sorgu çalıştırmanız veya zaman ayrıntı seviyesini değiştirmeniz gerekiyor. group_limitzaman kovalarını sessizce kırpabiliyor. Alanı boş bırakırsanız OpenRouter güvenli bir değeri otomatik hesaplıyor. Çok düşük bir değer verirseniz zaman serilerindeki haftalar kaybolabiliyor. Boyut belirtilmeyen sorgularda ise bu alan tamamen yok sayılıyor.- Sayı metrikleri bazen metin olarak geliyor. Referans dokümanında sayılar gösteriliyor; API ise string döndürebiliyor. Kodunuz her iki türü de ayrıştırmalı.
- Zaman serisi sütun adları belirsiz. Sorgunun yapısına göre aynı zaman kovası
date__dayveyacreated_at__dayadıyla gelebiliyor. - Kullanılmayan maliyet bileşenleri sıfır değil,
nulldöndürüyor. Her toplulaştırma betiğinde null kontrolü bulunmalı. metadata.truncated: true, toplamların eksik olduğu anlamına geliyor.limitdeğerini yükseltin (varsayılan 1.000) veya zaman aralığını daraltıp sorguyu yeniden çalıştırın.
Dashboard mı, API mi, Kendi Veri Hattınız mı?
Yerleşik araçlar hesap seviyesindeki sorular için yeterli. Kendi sisteminizi kurmak ancak aşağıdaki sınırın ötesinde anlamlı hâle geliyor:
| İhtiyacınız | Kullanılacak araç |
|---|---|
| Harcamayı, tokenları ve önbellek oranını hızlıca görmek | Activity Overview |
| Nelerin değiştiğini ve nerede artış olduğunu görmek | Trends |
| Tek seferlik kırılımlar ve paylaşım | Explore + CSV/PDF dışa aktarma |
| Zamanlanmış raporlar, uyarılar ve kurum içi dashboard'lar | Analytics API |
| Birden fazla sağlayıcıyı birleştirme, kullanıcı başına bütçeler ve özel anomali tespiti | Kullanım günlükleri ve webhook'lar üzerine özel bir veri hattı |
Kendi sistemini kurma yaklaşımı oldukça yaygın. r/FinOps'ta bir kullanıcı şöyle yazmış:
"Bir modelin fiyatı bir gecede sentlerden 3 €'ya çıktığı için Obsidian'da kendi yapay zekâ maliyet takip aracımı geliştirdim."
Bu başlık ile r/openrouter'daki “Uzun bağlam fiyatlandırması daha şeffaf olmalı” tartışmasının ortak bir nedeni var: yönlendirme, önbellekleme, akıl yürütme tokenları ve uzun bağlam fiyatlandırması nedeniyle yerel tahminler faturalandırılan tutarlardan sapabiliyor. Activity dashboard'da kaydedilen kullanım, esas alınması gereken rakam. Kendi sisteminizi kurarsanız kendi fiyat tablonuzla değil, bu verilerle mutabakat sağlayın.
Platformu altı aydır kullanan bir geliştiricinin önerdiği daha basit bir ilişkilendirme yöntemi de var: İstekleri X-Title başlıklarıyla etiketleyin; böylece her uygulama veya deney Activity içinde kendi adıyla görünür. Harcamanız tek bir router yerine birden fazla sağlayıcıya dağılmışsa, AIReiter gibi birleşik API çözümleri, toplulaştırma sorununu daha en başta ortadan kaldırabilir.
Sık Sorulan Sorular
Activity dashboard için yönetim anahtarına ihtiyacım var mı?
Hayır. Dashboard, normal hesap girişinizle kullanılan bir arayüz. Yönetim anahtarı yalnızca Analytics API endpoint'leri (/api/v1/analytics/meta ve /api/v1/analytics/query) için gerekli.
OpenRouter Analytics API çağrıları ücretsiz mi?
Rehber, Analytics iş akışını salt okunur ve ücretsiz olarak tanımlıyor: çağrı başına ücret ödemiyor, kendi kullanım kayıtlarınızı sorguluyorsunuz. Ancak bu kayıtların temsil ettiği çıkarım kullanımı için ödeme yapmaya devam ediyorsunuz.
OpenRouter etkinlik verileri ne kadar geriye gidiyor?
Eski /api/v1/activity endpoint'i, tamamlanmış önceki 30 UTC gününü kapsıyor. Yeni Analytics API belgelerinde saklama süresi belirtilmemiş; örnek sorgular bir aylık dönemi kapsıyor. Bu nedenle daha uzun dönemli geçmişi doğrulanmamış kabul edin ve saklamak istediğiniz verileri CSV olarak dışa aktarın.
Activity günlüklerinde prompt ve yanıtları neden göremiyorum?
Prompt ve tamamlama ayrıntıları yalnızca özel girdi/çıktı günlüklemenin istek anında etkin olduğu isteklerde tutuluyor. Duyuruda açıkça belirtildiği üzere, bu özellik etkin değilse geçmişe dönük prompt içeriğine erişilemiyor. Toplamlar kaydedilen kullanım verilerinden oluşuyor; içerik ise isteğe bağlı.
Bu Tercihin Maliyete Yansıması
Yukarıdaki iş akışının tamamı bugün kurulabilir ve yalnızca ilk sorgu bile beş dakikalık kurulumu haklı çıkarıyor. Asıl risk ise beta sürümün zamanla değişmesi: desteklenen metrikler ve boyutlar güncellenebilir. OpenRouter da şemaya güvenmeden önce /meta endpoint'inin yeniden okunmasını öneriyor. Cron işlerinizde alan adlarını sabit kodlamak yerine bir meta kontrolü kullanın; böylece API henüz olgunlaşma sürecindeyken dashboard'ın sağladığı görünürlük korunur.
İlgili okumalar: OpenRouter auto router rehberi · Programlama için en iyi ücretsiz OpenRouter modelleri · OpenRouter fiyatlandırma rehberi