# OpenRouter İsteklerini Başka Bir OpenAI Uyumlu API'ye Taşırken Neler Değişir? > OpenRouter'dan ayrılırken base URL ve API anahtarını değiştirmek yalnızca ilk adımdır. Standart sohbet alanları çoğu zaman taşınır; ancak model kimlikleri, OpenRouter başlıkları ve yönlendirme uzantıları, fallback davranışı, akış, kullanım muhasebesi, çok modlu girişler, hatalar ve hız limitleri sağlayıcı adaptörü arkasında test edilmelidir. # OpenRouter İsteklerini Başka Bir OpenAI Uyumlu API'ye Taşırken Neler Değişir? Basit chat completion için geçiş yeni bir base URL, API anahtarı ve model kimliğiyle başlayabilir. Üretim davranışı istek biçiminden daha geniştir. OpenRouter'a özgü yönlendirme, başlıklar, model slug'ları, fallback'ler, meta veriler ve sağlayıcı seçimi bilinçli karşılıklar gerektirir; akış ve araç çağrıları sözleşme testleri ister. OpenAI uyumluluğunu ortak bir taşıma lehçesi olarak görün, katalogların, uzantıların, faturalandırmanın veya operasyonların aynı olduğu sözü olarak değil. ## Gerçekte kullandığınız sözleşmeyi envanterleyin OpenRouter'a gönderilen her alan için kodu, yapılandırmayı ve günlükleri tarayın. Belgelenen OpenAI SDK kurulumu `https://openrouter.ai/api/v1`, bearer kimlik doğrulama ve isteğe bağlı atıf başlıklarını kullanır. Uygulamalar yönlendirme ve fallback uzantıları da kullanabilir. Değişiklikten önce envanter çıkarın: | Yüzey | Genellikle taşınabilir | Genellikle incelenmeli | |---|---|---| | Sohbet isteği | `messages`, sıcaklık, çıktı limiti | Desteklenmeyen parametreler ve varsayılanlar | | Modeller | Uygulama amacı | Sağlayıcıya özgü model slug'ı | | Araçlar | İşlev adı ve JSON şeması | Paralel çağrı, strictness, argüman akışı | | Yönlendirme | Yok | Sağlayıcı tercihleri, fallback'ler, transforms | | Başlıklar | Yetkilendirme kalıbı | OpenRouter atıf ve meta veri başlıkları | | Kullanım | Token sayıları | Maliyet, önbellek, istek lookup alanları | | Operasyon | HTTP durum aileleri | Hız limitleri, retry, timeout, hata gövdeleri | ## Önce bir sağlayıcı adaptörü ekleyin Yeni URL ve model slug'ını kod tabanına dağıtmayın. Sağlayıcı farklarını tek adaptör arkasına koyup uygulama düzeyinde takma adlar sunun. ```python from openai import OpenAI def make_client(base_url: str, api_key: str) -> OpenAI: return OpenAI(base_url=base_url, api_key=api_key) MODEL_MAP = { "coding_default": { "openrouter": "provider/model-slug", "target": "target-model-id", } } ``` Adaptör isteğe bağlı alanları çevirmeli, hataları normalize etmeli ve ortak olay şeması üretmelidir. ## Model ve yönlendirme semantiğini değiştirin Model kimlikleri OpenAI uyumluluğuyla standartlaşmaz. Her uygulama takma adını hedef modele eşleyin ve bağlam uzunluğu, araç desteği, yapılandırılmış çıktı, modaliteler ve fiyatı güncel katalogdan doğrulayın. OpenRouter yönlendirme ve fallback davranışını başka ağ geçidi farklı sunabilir veya hiç sunmayabilir. Politikaları orkestrasyonda yeniden kurmaya, hedef router'ı kullanmaya veya kaldırmaya karar verin. Sessiz değişiklikler maliyet ve kaliteyi etkiler. ## OpenRouter uzantılarını kaldırın veya çevirin OpenRouter'a özgü başlıkları ve body alanlarını inceleyin. İsteğe bağlı atıf başlıkları genellikle kaldırılabilir. Sağlayıcı tercihleri, fallback dizileri, plugins, transforms ve meta veri kontrolleri açık eşleme ister. Geçiş testlerinde bilinmeyen uzantıları reddedin. Alanı sessizce yok saymak davranış değişikliğini gizler. ## Araçları ve akışı sözleşme olarak test edin Araç çağrısı, sözde uyumlu API'lerin sık ayrıştığı yerdir. Şunları test edin: * işlev adı ve JSON şeması kabulü; * tool choice kipleri ve paralel çağrılar; * artımlı araç argümanı olayları; * finish reason ve refusal alanları; * bozuk argümanlar ve yeniden denemeler. Akışta ham parçalar yerine ayrıştırılmış olay dizilerini karşılaştırın. İptal, akış ortası hata, son kullanım, boş delta ve bağlantı retry'larını ekleyin. ## Kullanım ve maliyet muhasebesini yeniden kurun OpenRouter model, sağlayıcı, token kullanımı ve toplam maliyet içeren üretim meta verileri belgeler. Başka ağ geçidi kullanımı completion içinde, ayrı lookup endpoint'inde verebilir veya istemci taraflı fiyatlama isteyebilir. Verileri kendi defterinize normalize edin: ```json { "request_id": "internal_123", "provider_request_id": "external_456", "gateway": "target", "model": "resolved-model-id", "input_tokens": 1200, "output_tokens": 340, "cost_usd": 0.0123 } ``` Tahminleri uzlaştırılmış ücretlerden ayırın. Üretim ajanlarını taşımadan bütçe uygulamasını yeniden kontrol edin. ## Çok modlu istek biçimlerini doğrulayın Görüntü, ses ve video desteği modele ve endpoint'e bağlıdır. İki ağ geçidi aynı modaliteyi desteklerken içerik parçası şeması, yükleme, URL erişimi, asenkron işler veya çıktı nesnelerinde farklılaşabilir. Kullandığınız her modalite için fixture oluşturun. Başarılı metin isteğinden medya uyumluluğu çıkarmayın. ## Operasyon davranışını test edin Hız limiti başlıklarını, yeniden denenebilir durum kodlarını, timeout'ları, kuyruklamayı, bölgesel kontrolleri, idempotency'yi, günlükleri ve destek sürecini ölçün. Hedefin güncel belgelerini kullanın. Pratik yayının dört kapısı vardır: 1. Altın istek setini çevrimdışı yeniden oynatın. 2. Güvenli trafiği kullanıcı etkisi olmadan gölgeleyin. 3. Düşük riskli küçük bir yüzdeyle canary yapın. 4. Yalnızca hata, gecikme, maliyet ve çıktı koşulları eşiklerdeyken genişletin. Yeni yol temsili yükü geçene kadar tek anahtarlı geri alma sağlayın. ## Konsolidasyonun değip değmediğine karar verin Geniş LLM kataloğu ve yönlendirme kontrolleri ürüne uyuyorsa OpenRouter güçlü bir seçenektir. Atlas Cloud gibi tam modal bir ağ geçidi metin, görüntü ve video için tek OpenAI uyumlu ilişkiyle yığını sadeleştirebilir. İki avantaj da model ve özellik testini ortadan kaldırmaz. En küçük kod farkına değil, ölçülmüş iş yükü gereksinimlerine göre seçin. ## Sonuç OpenRouter trafiğini taşırken istemci yapılandırmasını değiştirin ve modeller, yönlendirme, araçlar, akış, kullanım ve operasyonlardaki her standart dışı varsayımı denetleyin. Sağlayıcı adaptörü ve altın testler geçişi geri alınabilir tutar ve anlamsal gerilemeyi görünür kılar. ## FAQ ### OpenRouter'dan yalnızca base_url ve api_key değiştirerek geçebilir miyim? Basit sohbet isteğinde bazen evet; ancak üretim entegrasyonları genellikle model slug'larına, yönlendirme seçeneklerine, başlıklara, akış davranışına, kullanım alanlarına veya fallback semantiğine de bağlıdır. ### Hangi OpenRouter alanlarının taşınamama olasılığı yüksektir? Sağlayıcı yönlendirme tercihleri, model fallback dizileri, OpenRouter atıf başlıkları, transforms, plugins ve OpenRouter'a özgü meta veriler yaygın geçiş noktalarıdır. Bunları çekirdek istek modelinin dışında tutun. ### OpenAI uyumlu API'ler aynı model adlarını mı kullanır? Hayır. Uyumluluk genellikle istek biçimini kapsar, katalog kimliğini değil. Uygulama model takma adlarını her ağ geçidinin güncel model kimliklerine açıkça eşleyin. ### Geçişten sonra akış nasıl test edilmelidir? Metin delta'ları, araç çağrısı argümanları, finish reason'lar, kullanım, iptal ve hatalar için olay dizilerini kaydedin. Çerçeveleme değişebileceğinden ham byte parçaları yerine ayrıştırılmış olayları karşılaştırın. ### En güvenli geçiş yayını nedir? Adaptör kullanın, altın istek setini oynatın, kullanıcı etkisi olmadan küçük bir örneği gölgeleyin ve hata, gecikme, maliyet ve çıktı koşulları için geri alma eşikleriyle düşük riskli canary başlatın. ### Bir ekip ne zaman OpenRouter'da kalmalıdır? Geniş LLM kataloğu, yönlendirme kontrolleri ve mevcut operasyon araçları başka yerde konsolidasyondan daha değerliyse kalın. Kararı uyumluluk iddialarıyla değil, ölçülmüş gereksinimlerle verin.