OpenRouter Sağlayıcı Yönlendirmesi Açıklaması: Ekim 2026 Güncellemesi

OpenRouter, varsayılan yönlendirme sistemini 28 Ekim 2026'da yeniledi: ilk token'a kadar geçen süre %16,9 azalırken toplam 429 olayı %67 düştü. Bunun karşılığında isteklerin maliyeti yaklaşık %6 arttı. Otomatik yönlendirme sizi fark ettirmeden daha pahalı bir sağlayıcıya taşıyabildiği için asıl önemli nokta bu denge.

OpenRouter'ın yeni yönlendiricisi artık en ucuz giriş token'ı fiyatını seçmiyor. İyi bir yanıtın gerçek maliyetini; fiyatı, bekleme süresini ve yeniden denemeleri birlikte hesaba katarak tahmin ediyor ve her isteği Routing Cost değeri en düşük sağlayıcıya gönderiyor.

30 saniyelik sonuç: Rakamlar ne söylüyor?

OpenRouter sağlayıcı yönlendirmesi artık istem token'ı fiyatı yerine Routing Cost değerini optimize ediyor. İstekte açıkça provider.sort, provider.order, provider.only veya provider.ignore belirtilmediğinde değişiklik otomatik olarak devreye giriyor. OpenRouter'ın duyurusuna göre bu durum, birden fazla sağlayıcı tarafından sunulan modellere giden trafiğin yaklaşık %77'sini kapsıyor.

Sonuçlar, eski ve yeni yönlendiricinin eşit paylaştırıldığı; 24 milyon istek ve 103 milyar giriş token'ı üzerinden gerçekleştirilen bir haftalık switchback testinden geliyor.

\*İstek payı verileri ile olay sayısındaki azalmalar duyuruda birlikte raporlanıyor. Buradaki %67 ve %47 oranları isteklerdeki isabet oranını değil, toplam 429 olaylarını ve toplam yeniden denemeleri ifade ediyor; çünkü tek bir istek birden fazla hatayla karşılaşabilir.

Duyuruya göre, istemci tarafından ölçülen TTFT p95 değeri 6.032 ms'den 4.504 ms'ye, isteğin tamamlanma süresi p50 değeri 4,00 saniyeden 3,24 saniyeye indi. Başarısız denemelerde boşa giden süre de istek başına 349 ms'den 242 ms'ye geriledi.

Özetle: Yaklaşık %6 daha yüksek maliyeti kabul edebiliyorsanız etkileşimli sohbet ve ajanlarda yeni varsayılanı kullanmaya devam edin. Her kuruşun önemli olduğu büyük toplu işlerde ise yalnızca fiyata göre yönlendirmeye dönün.

Routing Cost basitçe nasıl çalışıyor?

Routing Cost, her sağlayıcı için iki soruya yanıt arıyor: Bir denemenin maliyeti ne kadar ve bu deneme ne sıklıkla başarılı oluyor? OpenRouter'ın örneğinde, $0,40'lık deneme maliyetine $0,60'lık bekleme maliyeti ekleniyor. Elde edilen $1,00, %80'lik başarı olasılığına bölündüğünde başarılı yanıt başına maliyet $1,25 oluyor. En düşük maliyete sahip sağlayıcı daha fazla trafik alıyor.

Bu hesaplamayı üç unsur besliyor:

1. Liste fiyatı değil, gerçek fiyat. OpenRouter, yakın dönemdeki trafiği kullanarak giriş ve çıkış token'larını tahmin ediyor; ardından her sağlayıcının gerçek önbellek isabet oranını ve token fiyatlarını hesaba katıyor. Duyurudaki örnekte 40 bin önbelleksiz giriş token'ı $2,00/M üzerinden $0,080, 60 bin önbellekli giriş token'ı $0,50/M üzerinden $0,030 ve yaklaşık 4 bin çıkış token'ı $8,00/M üzerinden $0,032 tutuyor. Toplam maliyet $0,142 oluyor. Giriş token'ı ucuz olsa bile önbellekli veya çıkış token'ları pahalı olan sağlayıcı bu hesaplamada avantajını kaybediyor.
2. Bekleme süresinin parasal karşılığı. Verim, ilk token'a kadar geçen süreyi de içeren uçtan uca çıkış token'ı/saniye değeridir. Örneğin ilk token 5 saniyede geliyor ve 500 token sonraki 5 saniyede üretiliyorsa hız 50 tok/s oluyor. Yönlendirici, tipik sağlayıcı ücretleri ve hızlarına göre belirlenen model bazlı bir oranla bekleme süresini maliyete dönüştürüyor. Ajanların her adımda ilk token'ı beklemesi gerektiğinden ilk token'a kadar geçen süreye daha fazla ağırlık veriliyor.
3. Hata maliyeti. 429, sağlayıcının isteği kabul etmediği anlamına geliyor. Bu durumda ret yanıtını bekleyip isteği başka bir yerde yeniden göndermeniz gerekiyor. Örneğin 2,50 saniyelik beklemeye %0,4'lük oranla uygulanan ceza eklendiğinde maliyet 0,01 artıyor. Güvenilirlik hataları yaklaşık 8 kat daha ağır cezalandırılıyor; hata oranındaki %1'lik artış maliyeti yaklaşık %8 yükseltiyor. Eşlerinden belirgin şekilde kötü performans gösteren sağlayıcılar toparlanana kadar trafik alamıyor. Duyuruya göre kalite kontrolünde şu an düzgün biçimlenmiş araç çağrıları da dikkate alınıyor; bu oran %95 olduğunda maliyet yaklaşık %5 artıyor ve işaretlenen sağlayıcılar test trafiğine düşürülüyor.

Duyuruya göre iki koruma mekanizması tüm trafiğin tek bir sağlayıcıya yığılmasını önlüyor: Her sağlayıcı, toparlanma durumunun görülebilmesi için az da olsa trafik almaya devam ediyor. Ayrıca yönlendirici, hata veren sağlayıcıların trafik payını azaltırken sağlayıcı bazında kapasite sınırlarını öğreniyor ve taşan trafiği başka yerlere aktarıyor.

Varsayılan yönlendirme üretim uygulamalarında neden hâlâ sorun çıkarıyor?

Kullanıcı raporları, token başına fiyatın tek başına yakalayamadığı dört tekrarlayan hata senaryosunu gösteriyor.

Araç çağrılarında sağlayıcı değişimi şemayı bozabiliyor

Benim için araç çağrısını gerçekten bozan şey, sağlayıcılardan birinin fiyatı değil, istek sırasında yaşanan sağlayıcı değişimiydi.

— u/Michael_Jeffords, kaçınılması gereken sağlayıcılar hakkındaki r/openrouter başlığı

Kalite puanlaması bugün ağırlıklı olarak düzgün biçimlenmiş araç çağrılarına ve benchmark doğruluğu işaretlerine dayanıyor, duyuruya göre. Konuşmanın ortasında sağlayıcı değişmesi yine de kuantizasyonu veya reddetme davranışını değiştirebilir; çünkü sağlayıcı kalitesi farklılık gösteriyor ve bazıları daha yoğun kuantize edilmiş sürümler sunuyor.

Önbelleğin bozulması faturayı şişiriyor

Bir başlıkta, yaklaşık 700 bin token'lık bağlamlarda beklenen $0,20'lik önbellekli isteklerin, sağlayıcı değişikliğinden sonra yaklaşık $2,00 olarak ücretlendirildiği aktarılıyor. Bu, "bozuk önbellekleme yüzünden 10-32 kat fazla ödeme" şikâyetinin temelindeki senaryo. Yeni yönlendirici, önbellek sıcak olduğu sürece bir konuşmayı ilk sağlayıcısına sabitliyor ve algoritmik seçimi yalnızca ilk istekte yapıyor; bu yaklaşım OpenRouter'ın önbellek farkındalıklı yönlendirmesine dayanıyor. Ancak başka bir sağlayıcıya geçişte bu sabitleme bozuluyor. Sorunu çözen kullanıcılar, yapışkan oturumlarla tek bir sağlayıcıyı sabitledi.

Bence OR'daki oldukça temel bir sorun, bunu önceden elle yapılandırmak zorunda olmanız.

— u/welcome_to_milliways, bozuk önbellekleme hakkındaki r/openrouter başlığı

Fark ettirmeyen pahalı yedek geçiş

Bir üretim raporunda, trafiğin bir bölümünün sessizce Sonnet'ten liste fiyatı yaklaşık 5 kat daha yüksek olan Opus'a taşındığı, çalışma süresi göstergesinin yeşil kalmasına rağmen toplam harcamanın saatlik $184'ten $412'ye çıktığı belirtiliyor; bilgi @CarbonOnX tarafından paylaşıldı. Yeni yönlendirici bu tercihi açık hâle getiriyor: Daha hızlı ve daha güvenilir bir sağlayıcının en ucuz seçeneği geride bırakması mümkün.

Ücretli hesaplarda bile 429 hataları

Ücretli bir OpenRouter bakiyesi, üst sağlayıcının kapasitesini artırmıyor; bu 429 başlığındaki kullanıcıların belirttiği gibi. 429 hatası, ilgili sağlayıcının o model için paylaşılan kapasite havuzunu yansıtıyor. Yeniden yapılanma testlerde 429 olaylarını %67 azalttı; ancak üretimde hız sınırına takılan sağlayıcıyı sabitlemek veya yok saymak hâlâ çözüm olarak öne çıkıyor. Önce OpenRouter 429 hatalarını düzeltme rehberine göz atın. Daha eski, fiyat ağırlıklı varsayılan sistemi öğrenmek için OpenRouter Auto Router rehberine bakabilirsiniz.

İşe yarayan üç yönlendirme yapılandırması

Seçiminiz, zahmetsiz hız, kesin maliyet sınırları veya deterministik davranış önceliğinize bağlı. Tüm seçenekler aynı provider nesnesini kullanıyor: provider.order yeni mantığı devre dışı bırakıp sağlayıcıları tam belirtilen sırayla deniyor; provider.only ve provider.ignore adayları filtreliyor, ardından yeni algoritma kalanlar arasından seçim yapıyor. Açıkça belirtilen provider.sort değerleri (price, throughput, latency) ise yeni mantığın yerine geçiyor.

1. Yeni varsayılanı kullanmaya devam edin (etkileşimli sohbet ve ajanlar)

Kod değişikliği gerekmiyor. Bu seçenek, her araç çağrısında ilk token'ı bekleyen kullanıcı odaklı sohbetler ve çok adımlı ajanlar için uygun. Gecikme ve yeniden deneme avantajı karşılığında yaklaşık %6 daha yüksek maliyeti kabul etmiş oluyorsunuz. Bir hafta boyunca API yanıtında ve etkinlik sayfasında dönen sağlayıcıyı, TTFT p50 ve 429 oranıyla birlikte kaydedin: 429 payınız yeni yaklaşık %4'lük tabana yakın kalıyor ve önbellek isabet oranı korunuyorsa devam edin. Bir sağlayıcı hataların çoğuna neden oluyorsa veya önbellek isabetleri düşüyorsa 3. seçeneğe geçin.

2. En ucuz yolu sabitleyin (toplu işler ve maliyet sınırı olan çalışmalar)

Maliyet hızdan önemliyse fiyat bazlı yönlendirmeyi tercih etmenin üç yolu var:

{ "provider": { "sort": "price" } }

Alternatif olarak model adının sonuna :floor ekleyin (meta-llama/llama-4-maverick:floor) veya hesap ayarlarında varsayılan sıralamayı fiyat olarak belirleyin; duyurunun SSS bölümünde bu seçenekler açıklanıyor. :floor seçeneğinin, yalın sort seçeneğinin aksine flex-tier uç noktalarını da kabul ettiğini unutmayın; bu bilgi OpenRouter'ın yönlendirme rehberinde yer alıyor.

Bir üst sınırla birlikte kullanabilirsiniz:

{ "provider": { "sort": "price", "max_price": { "prompt": 1.0, "completion": 2.0 } } }

Bu yapılandırma büyük istemler, kısa çıktılar ve ucuz yeniden denemeler için uygundur.

3. Kararlı bir sağlayıcıyı sabitleyin (önbellek veya araç çağrısı kullanan üretim sistemleri)

Doğruluk, önbellek isabetleri veya uyumluluk istek bazında optimizasyondan daha önemliyse sağlayıcıyı sabitleyin:

{
  "provider": {
    "order": ["deepinfra", "together"],
    "allow_fallbacks": true,
    "require_parameters": true
  }
}

require_parameters yalnızca gerekli istek parametrelerini desteklemeyen uç noktaları eler; sağlayıcılar arasındaki araç çağrısı veya şema davranışlarının aynı olacağını garanti etmez. Uyum veya BYOK senaryolarında, onaylanmamış bir sağlayıcıya geçmektense hizmet kesintisini tercih ettiğiniz durumlar için allow_fallbacks: false ile order kullanın. Çoğu uygulamada yedek geçişlere izin verin, adayları only/ignore ile daraltın ve sıcak önbelleği yeniden kullanmak için sabit bir session_id gönderin (yapışkan yönlendirme). Bir sağlayıcı istikrarsızsa onu koruma kurallarında engelleyin ve doğrudan sağlayıcı API'larını karşılaştırın. Birçok kullanıcı, model kesinleştikten sonra doğrudan API'ya geçmenin yavaşlık ve önbellek sorunlarını ortadan kaldırdığını bildiriyor (örnek başlık).

Otomatik yönlendirme eskisinden daha iyi. Ancak tek bir hatalı sağlayıcı geçişinin, token başına biraz daha yüksek fiyatla geçen bir haftadan daha pahalıya mal olduğu durumlarda sabitlemenin yerini hâlâ tutamıyor.

Sık sorulan sorular

Yeni yönlendirmeyi kullanmak için kodumu değiştirmem gerekiyor mu?

Hayır. Açıkça sağlayıcı sıralaması, sırası, yalnızca kullanılacak sağlayıcılar veya yok sayılacak sağlayıcılar belirtilmeyen istekler yeni yönlendiriciyi otomatik olarak kullanıyor.

Yalnızca fiyata göre yönlendirmeyi nasıl koruyabilirim?

provider.sort değerini "price" olarak ayarlayın, :floor ekleyin veya hesap ayarlarındaki varsayılan sıralamayı fiyat olarak belirleyin.

Yeni yönlendirme sağlayıcı sıramı geçersiz kılıyor mu?

Hayır. order yeni yönlendirmeyi devre dışı bırakır; only/ignore önce filtreleme yapar, ardından yeni algoritma seçimde bulunur.

Yeni yönlendirme daha pahalı mı?

Sonuç tablosuna bakabilirsiniz: Testlerde 1.000 istek başına maliyet %6,0, 1 milyon token başına maliyet %7,3 arttı.

İsteğime gerçekte hangi sağlayıcının yanıt verdiğini nasıl görebilirim?

OpenRouter belgelerine göre API yanıtındaki provider alanını ve etkinlik sayfasını kontrol edin.

Ücretli bir hesapta neden hâlâ 429 alıyorum?

Sorun bakiyeniz değil, üst sağlayıcının paylaşılan kapasite sınırlarıdır. Hız sınırına takılan sağlayıcıyı sabitleyin veya yok sayın.