OpenRouter BYOK Ücretleri, Fallback ve Anahtar Rotasyonu (2026)

OpenAI anahtarınız geçerli olabilir, istek başarıyla tamamlanabilir ve buna rağmen OpenRouter bakiyeniz azalabilir. Bunun nedeni BYOK'un tek bir faturalandırma ayarı olmaması: sağlayıcı maliyeti, platform ücreti ve fallback kapasitesi farklı akışlardan ilerler. Üstelik güncel kural, eski bir milyon istek yaklaşımının yerini almış durumda.

Önce hangi ücretin oluştuğunu tespit edin

OpenRouter BYOK, çalışma alanınızda saklanan bir sağlayıcı kimlik bilgisini kullanırken API ve yönlendirme katmanını OpenRouter'da tutar. Bu yapıda para hareketi üç ayrı kanaldan gerçekleşir:

İlk teşhis sorusu “Anahtarımı ekledim mi?” olmamalı. Asıl soru, “Bu isteğe hangi sağlayıcı hizmet verdi?” olmalı. Tanımlı bir anahtar; hız limitleri, yetersiz üst sağlayıcı bakiyesi, yetki sorunları veya geçici sağlayıcı kesintisi yüzünden başarısız olabilir. Fallback açıksa OpenRouter isteği başka bir sağlayıcı üzerinden tamamlayabilir ve bu rota için OpenRouter bakiyenizi ücretlendirebilir. BYOK ücretleriyle ilgili destek açıklaması da bu durumu anlatıyor.

BYOK neyi değiştirir, neyi değiştirmez?

BYOK, uygun trafiği sağlayıcı kimlik bilgileriniz üzerinden yönlendirirken OpenRouter API'sini ve yönlendirme katmanını korur. OpenRouter, BYOK dokümantasyonunda bu kimlik bilgilerinin şifrelendiğini ve yalnızca belirtilen sağlayıcıya yönlendirilen isteklerde kullanıldığını belirtiyor.

BYOK, çıkarımı ücretsiz hale getirmez: model kullanımını sağlayıcı yine kendi tarafında ücretlendirir; geçerli allowance aşıldığında OpenRouter ayrıca platform ücreti uygulayabilir. Kendi anahtarınızı kullanmak; çalışma alanı, hesap veya istek düzeyindeki gizlilik kurallarını da devre dışı bırakmaz. Uygun hiçbir endpoint kalmadığında, kimlik bilgisi geçerli olsa bile istek başarısız olur.

Güncel BYOK ücreti istek sayısına değil, çıkarım değerine bağlı

Güncel OpenRouter fiyatlandırma sayfası, BYOK için ücretsiz allowance'ı istek sayısıyla değil, çıkarımın liste fiyatı değeriyle tanımlıyor:

Allowance, aynı modelin ve sağlayıcının OpenRouter'daki normal maliyetine göre hesaplanır; sağlayıcınızla yaptığınız özel fiyat anlaşmasındaki fatura tutarına göre değil. Allowance sonrasında %5 BYOK ücreti OpenRouter kredilerinden düşülür. Sağlayıcı ücreti ise bundan bağımsızdır.

Üç farklı maliyet kalemini ayrı takip edin

1. Sağlayıcı çıkarım maliyeti: Sağlayıcı, BYOK kimlik bilgisinin bağlı olduğu hesabı ücretlendirir.
2. BYOK platform ücreti: OpenRouter, mevcut plan allowance'ı aşıldıktan sonra OpenRouter kredilerinden %5 keser.
3. Fallback çıkarım maliyeti: Hedeflenen BYOK yolu yerine OpenRouter tarafından finanse edilen sağlayıcı kapasitesinin kullanıldığı rotanın bedeli OpenRouter kredilerinden karşılanır.

Kredi satın alma ücretleri ise ayrı bir konudur: OpenRouter fiyatlandırması, kullandıkça öde planı için %5,5 platform ücreti listeliyor. Bakiye yükleme ücreti, belirli bir isteğin fallback kullandığını tek başına kanıtlamaz.

Aramalarda eski 1 milyon istek bilgisi neden hâlâ çıkıyor?

OpenRouter'ın Ekim 2025 duyurusu, platform ücreti olmadan ayda bir milyon BYOK isteği ve bunun ardından %5 ücret uygulamasını açıklıyordu. Tarihli duyurudaki bu yaklaşım eski politikaydı; sayfa artık BYOK fiyatlandırmasının Ağustos 2026'da değiştiğini not ediyor. Tahmin yaparken güncel fiyatlandırma sayfasındaki liste fiyatı çıkarım allowance'ını kullanın ve kontrol ettiğiniz tarihi kaydedin.

BYOK'un katı bir sınır olup olmadığını fallback belirler

OpenRouter'ın varsayılan yönlendirme hedefi, isteğin başarıyla tamamlanmasıdır. BYOK rehberi, öncelikli anahtarları, paylaşılan OpenRouter endpoint'lerini ve fallback anahtarlarını rotadaki farklı aşamalar olarak açıklar:

• Öncelikli BYOK anahtarları, yapılandırıldıkları sırayla denenir.
• Bu denemeler başarısız olursa OpenRouter'ın paylaşılan kapasitesi kullanılabilir.
• Fallback olarak işaretlenen BYOK anahtarları, paylaşılan endpoint'lerden sonra denenir.
• Aynı sağlayıcı için eşleşen birden fazla anahtar sırayla denenebilir.

Sağlayıcı sıralaması işin içine girdiğinde tablo biraz daha karmaşıklaşır: Eşleşen BYOK endpoint'leri, sağlayıcı istediğiniz order dizisinde daha sonra yer alsa bile paylaşılan endpoint'lerden önce denenir. Bu nedenle bir istek, genel sağlayıcı sıralama kuralınızın düşündürdüğünden daha erken bir aşamada BYOK anahtarı kullanabilir.

Yüksek erişilebilirlik mi, net faturalandırma mı?

Paneldeki Always use for this provider seçeneği, OpenRouter'ın aynı sağlayıcı için kendi paylaşılan kimlik bilgisini kullanmasını engeller. Ancak bu, küresel çapta “OpenRouter kredilerini asla kullanma” anahtarı değildir. OpenRouter'ın destek makalesine göre, sağlayıcılar arası fallback kullanılabilir durumdaysa istek Anthropic BYOK anahtarından Google Vertex gibi başka uyumlu bir sağlayıcıya yine geçebilir.

Faturalandırmada kesinlik istiyorsanız, kısıtlamayı isteğin içinde yapın:

{
  "model": "anthropic/claude-sonnet-4.5",
  "messages": [
    { "role": "user", "content": "Summarize this document." }
  ],
  "provider": {
    "only": ["anthropic"]
  }
}

provider.only kullanıldığında Anthropic tarafındaki bir hata, başka bir sağlayıcıya sessizce yönlendirilmek yerine API hatasına dönüşür. Düzenlemeye tabi iş yükleri, sağlayıcıya özgü veri sözleşmeleri veya her isteğin tek bir üst sağlayıcı hesabıyla eşleşmesi gereken maliyet raporları için doğru tercih budur. Erişilebilirliğin katı sağlayıcı sahipliğinden daha önemli olduğu etkileşimli ürünlerde ise iyi bir varsayılan değildir.

r/openrouter topluluğundaki bir kullanıcı da aynı kontrolü şöyle özetliyor:

“İsteğin içinde order/only sağlayıcılarını belirleyerek yalnızca kendi BYOK anahtarlarınızın kullanılmasını zorlayabilirsiniz.” — u/Randomdotmath, Reddit başlığı

Fallback, dayanıklılık tasarımınızın parçasıysa bütçesini de planlayın; değilse istek sınırında kapatın.

Ücreti suçlamadan önce Activity'de rotayı doğrulayın

OpenRouter'ın SSS'sine göre Activity, kullanım geçmişini gösterebilir ve model, sağlayıcı ile API anahtarına göre filtreleyebilir. Şunları kontrol edin:

1. Hizmet veren sağlayıcı: BYOK kimlik bilginizin bağlı olduğu sağlayıcıyla eşleşiyor mu?
2. Model ve endpoint: Router başka bir uyumlu endpoint mi seçti?
3. Uygulama API anahtarı: İsteği hangi ortam veya çalışma alanı anahtarı gönderdi?
4. Kredi düşümü: Tutar çıkarım harcaması, BYOK ücreti veya bakiye yüklemeyle ilişkili bir değişim mi?

Activity'deki sağlayıcı BYOK sağlayıcısından farklıysa, kimlik bilgisini değiştirmeden önce fallback'i inceleyin. Sağlayıcı eşleşiyorsa ve hacim plan allowance'ına yaklaşıyorsa BYOK platform ücretini araştırın. Böylece yönlendirme politikası sorununu çözmeye çalışırken geçerli bir anahtarı gereksiz yere rotasyona sokmazsınız.

Rotasyona dayanıklı üretim anahtar yapısı

OpenRouter uygulama anahtarını ve üst sağlayıcı BYOK kimlik bilgisini, sahipleri de farklı olan iki ayrı sır olarak ele alın:

BYOK kimlik bilgisi ekleme ve test etme

Üretim trafiğinde hata ayıklamaya başlamadan önce şu kısa süreci izleyin:

1. Sağlayıcı kimlik bilgisini çalışma alanı BYOK ayarlarından ekleyin veya BYOK yönetim API'si üzerinden oluşturun.
2. Sağlayıcıyı, ortamı ve kullanım amacını belirten bir ad verin.
3. Çalışma alanı kimlik bilgisini paylaşmadan önce model, OpenRouter API anahtarı veya üye filtrelerini uygulayın.
4. Anahtarı öncelikli bölüme koyun; fallback anahtarını yalnızca faturalandırma ve kesinti senaryosundaki rolü açıksa ekleyin.
5. Bir test isteği gönderin, Activity'de hizmet veren sağlayıcıyı inceleyin ve ardından paylaşılan fallback'in açık kalıp kalmayacağına karar verin.

Bulut sağlayıcılarında kimlik bilgileri birbirinin yerine geçmez:

Bu kısıtlar OpenRouter'ın sağlayıcıya özel BYOK dokümantasyonundan geliyor. Yanlış kaynak türü, bölge, deployment veya izinle kullanılan geçerli bir sır; BYOK'un desteklenmediğini değil, yapılandırmanın hatalı olduğunu gösterir.

OpenRouter'ın BYOK ayarları; model slug'ları, OpenRouter API anahtarı hash'leri ve çalışma alanı üyeleri için filtreleri destekler. Bir kimlik bilgisinin kullanılabilmesi için etkin olan tüm filtrelerin eşleşmesi gerekir ve dokümantasyon her filtrede en fazla 100 kayda izin verir. Açık allowlist'ler kullanın; giderek genişleyen tek bir kimlik bilgisi yönetmek yerine büyük ekipleri çalışma alanlarına bölün.

Sağlayıcı anahtarlarına dokunmadan OpenRouter uygulama anahtarını döndürün

OpenRouter'ın API anahtarı rotasyonu rehberi, BYOK sağlayıcı kimlik bilgilerinin belirli bir uygulama anahtarıyla değil, OpenRouter hesabıyla ilişkilendirildiğini anlatıyor. Kesintisiz rotasyon sırası şöyledir:

1. Açıklayıcı adına ve uygun limite sahip yeni bir OpenRouter uygulama anahtarı oluşturun.
2. Anahtarı secret manager'ınıza kaydedin; eski anahtarı kullanan tüm servis, iş ve ortamlara dağıtın.
3. Üretim trafiğinin yeni anahtarı kullandığını Activity üzerinden doğrulayın.
4. Eski anahtarı ancak geçiş tamamlandıktan sonra silin.

Management API dokümantasyonu, Management API anahtarlarının yönetimsel kimlik bilgileri olduğunu ve completion endpoint'lerini çağıramadığını belirtiyor. Eski uygulama anahtarı iptal edilmeden önce yenisi kullanılabilir olmalıdır.

Sağlayıcı kimlik bilgisini ayrı rotasyona alın

Sağlayıcı anahtarının rotasyonu farklı bir değişikliktir. Sağlayıcının kendi kimlik bilgisi politikasını izleyin; iş yükünün kullandığı model, bölge, izinler ve kotayı eksiksiz test edin.

1. Üst sağlayıcıda, gereken en dar izinlere sahip yeni kimlik bilgisini oluşturun.
2. Bunu, farklı bir ad ve kontrollü öncelikle OpenRouter BYOK bağlantısına ekleyin.
3. Bir test isteği gönderin ve Activity'yi inceleyin.
4. Yeni kimlik bilgisini birincil konuma alın; hata kayıtlarını ve sağlayıcı kullanımını izleyin.
5. Örtüşme süresi sonrasında eski kimlik bilgisini üst sağlayıcıda iptal edin.

Bu sıra, OpenRouter'ın belgelendirilmiş öncelik davranışına dayanan operasyonel bir öneridir; sağlayıcının kendi iptal kuralları belirleyici olmaya devam eder. OpenRouter'ın BYOK oluşturma API'si ham kimlik bilgisi kabul eder, ancak bunun beklemede şifrelendiğini ve sonraki API yanıtlarında geri döndürülmediğini belirtir. OpenRouter bir kurtarma kopyası olmadığından kaynak kimlik bilgisini kendi secret manager'ınızda saklayın.

OpenRouter BYOK'un varsayılan tercih olmaması gereken durumlar

Tek bir sağlayıcının yerel log'ları, endpoint davranışının birebir korunması veya üretici araçları; birleşik yönlendirmeden daha önemliyse doğrudan sağlayıcı erişimi daha iyi varsayılandır. Çoklu sağlayıcı hesabı, mevcut sağlayıcı kredileri ya da taahhüt edilmiş kapasite ve çalışma alanı düzeyinde kontroller içinse BYOK daha uygundur.

OpenRouter BYOK SSS

Kendi anahtarımı kullandığımda OpenRouter yine ücret alır mı?

Evet. Sağlayıcı, BYOK kimlik bilgisi üzerinden gerçekleşen çıkarımı ücretlendirebilir; OpenRouter, güncel plan allowance'ı sonrasında kredilerden %5 BYOK platform ücreti kesebilir; fallback ise başka bir sağlayıcı rotasının OpenRouter kredileriyle ödenmesine neden olabilir.

“Always use for this provider” tüm fallback işlemlerini durdurur mu?

Hayır. Bu seçenek OpenRouter'ın ilgili sağlayıcı için kendi paylaşılan kimlik bilgisini kullanmasını engeller, ancak isteğin başka bir uyumlu sağlayıcıya geçmesini engellemez. Sağlayıcılar arası bu yolun kesinlikle mümkün olmaması gerekiyorsa provider.only kullanın.

Kurumsal ekipler BYOK güvenliğini ve bütçelerini nasıl yönetmeli?

OpenRouter; kimlik bilgilerinin şifrelendiğini, ham sağlayıcı anahtarlarının yönetim API'siyle döndürülmediğini ve BYOK harcamasının varsayılan olarak guardrail ile çalışma alanı bütçelerine dahil edilmediğini belirtiyor. BYOK dokümantasyonuna göre birleşik bütçe gerektiğinde Include BYOK spend veya include_byok_in_budgets etkinleştirilmelidir. Enterprise ekipleri ayrıca en az yetkili kimlik bilgileri, çalışma alanı ayrımı, filtreler, secret manager saklaması, rotasyon ve Activity incelemesi kullanmalıdır.

Varsayılanınız, tolere edebileceğiniz hata türüne göre belirlenmeli

Yönlendirme ve bütçe kontrollerini; isteklerin tamamlanması, sağlayıcı sahipliği veya maliyet görünürlüğü arasında hangisinden taviz veremeyeceğinize göre seçin.