Entegrasyon rehberleri · 2026-08-29
OpenStory'de LLMTR gateway'ini takım anahtarıyla bağlama
OpenStory'nin LLMTR dalında takım bazlı anahtar çözümü, yönlendirilebilirlik haritası, adapter genişletmesi ve token sayımından yürüyen harcama muhasebesi nasıl kuruluyor, hangi modaliteler kapsam dışında kalıyor.
Dalın kapsamı: hangi çağrılar gateway'e gidiyor
OpenStory görsel ve video üretimi yapan bir platform, ama knowhycodata/openstory deposundaki 1265-llmtr-gateway-provider dalı üretim işlerini değil, metin çağrılarını konu alıyor. Ortam dosyasındaki açıklama sınırı net koyuyor: anahtar ayarlandığında LLMTR'nin taşıdığı modellere giden LLM çağrıları OpenRouter yerine bu gateway üzerinden geçiyor. Senaryo analizi tarafındaki model kaydı bu çağrıların kaynağı.
Entegrasyonun teknik dayanağı, LLMTR'nin kablo biçiminin ve model listesi yükünün mevcut OpenRouter adapter'ının beklediği biçimle uyuşması. Bu yüzden yeni bir adapter yazılmıyor; sunucu adresi değiştirilerek aynı adapter sürülüyor. Taban adres https://llmtr.com/v1 ve sondaki sürüm eki bilinçli, çünkü SDK yolları bu değerin üzerine ekliyor.
Kapsamın dar olması bir eksiklik değil, dalın verdiği karar. Medya işlerinin kimlikleri zaten gönderildikleri sağlayıcıya göre kapsamlandığı için yoklama da o sağlayıcıya sabit kalıyor; metin çağrılarının yolunu değiştirmek bu işleyişe dokunmuyor.
Anahtar nereye giriliyor: takım anahtarı ve platform anahtarı
İki giriş noktası var. Birincisi kendi anahtarını getiren takımlar için arayüzdeki ayarlar bölümü; LLMTR burada diğer sağlayıcılarla aynı sırada duruyor. İkincisi bütün kuruluma yayılan ortam değişkeni. Takım anahtarı olmayan işler platform anahtarına düşüyor.
Ayrım çok takımlı kurulumda önem kazanıyor. Bir takımın anahtar girmesi yalnızca faturalamayı değil, o takımın çağrılarının hangi kapıdan çıkacağını da belirliyor. Test ortamı bu değişkeni hiç ayarlamıyor; böylece mevcut senaryolar eski yolu sınamaya devam ediyor ve gateway eklemek sabit çıktıları değiştirmiyor.
Anahtar biçimi LLMTR tarafında llmtr önekiyle başlıyor ve istekte yetkilendirme başlığında taşınıyor. Aşağıdaki blok platform genelindeki değişkeni gösteriyor; takım anahtarı için aynı değer arayüzdeki alana giriliyor.
Platform genelindeki değişken ve takım anahtarının karşılığı
# Butun kurulum icin gecerli yedek anahtar
LLMTR_API_KEY=llmtr-your_key
# Takim bazli anahtar arayuzden girilir:
# Settings -> API Keys -> LLMTR
# Ayni anahtar istekte su bicimde tasinir:
# Authorization: Bearer llmtr-your_key
Çözüm sırası: takım anahtarı hangi noktada devreye giriyor
Anahtar çözümü tek bir işlevde toplanmış ve sıralı çalışıyor. Grok için satıcının kendi arayüzü ayrıcalıklı kalıyor. Ardından, seçilen modeli LLMTR taşıyorsa takımın LLMTR anahtarı geliyor; bu, takımın OpenRouter anahtarının önünde. Gerekçe dalda açıkça yazılı: LLMTR anahtarı ekleyen bir takım o kapıyı bilerek seçmiştir.
Sıradaki kritik nokta koşulun iki yerde birden tutarlı olması. Anahtar çözümü ile adapter kurulumu aynı soruyu soruyor: bu model kimliği gateway'de taşınıyor mu? İki taraf farklı yanıt verirse anahtar bir kapıya, istek başka kapıya gider. Dal bunu bilinçli bir tuzak olarak işaretliyor.
Model taşınmıyorsa LLMTR anahtarı atlanıyor ve çağrı önceki yolundan devam ediyor. Yani gateway eklemek, kapsamadığı modelleri kırmıyor.
| Sıra | Kullanılan anahtar | Seçilme koşulu |
|---|---|---|
| 1 | Satıcının kendi arayüzü | Model Grok ailesindeyse ve satıcı anahtarı varsa |
| 2 | Takımın LLMTR anahtarı | Model kimliği gateway haritasında karşılık buluyorsa |
| 3 | Takımın OpenRouter anahtarı | Takım LLMTR anahtarı girmemişse veya model taşınmıyorsa |
| 4 | Takımın fal anahtarı | Önceki iki takım anahtarı da yoksa |
| 5 | Platform değişkenleri | Takımın hiçbir anahtarı yoksa, aynı öncelik sırasıyla |
Yönlendirilebilirlik haritası ve isim alanı kayması
Dalın en kritik dosyası, kayıt defterindeki model kimliğini LLMTR kataloğundaki kimliğe çeviren harita. Buna gerek duyulmasının nedeni isim alanı farkı: aynı satıcı iki katalogda farklı önekle yazılabiliyor. Harita bu farkları tek tek yazıyor, kalıp kuralı uydurmuyor.
Haritada olmayan bir kimlik yönlendirilebilir sayılmıyor. Kod bunu hata değil, yönlendirme kararı olarak ele alıyor ve çağrı eski yolundan gidiyor. Yakın komşu bir modele düşmek bilinçli olarak reddedilmiş, çünkü çağıranın istemediği bir modeli sessizce koymak en pahalı hata türü. Dalın bugün taşımadığını söylediği üç kimliğin public katalogda karşılığı bulunmuyor; biri için satıcının kendisi katalogda yok.
Yeniden adlandırılan dört kimlik ayrı bir listede toplanıyor, çünkü OpenRouter adapter'ının ürettiği model birleşimi bu adları tanımıyor ve fabrika bu liste ile genişletiliyor. Bunun bir bedeli var: yeniden adlandırılan bir kimlik, diğer kataloğun model başına meta verisini kaybediyor. Araç ve şema alanlarını tek çağrıda birleştiren hızlı yol da bu meta veriye bağlı olduğu için o kimliklerde devreye girmiyor.
- Satıcı önekleri iki katalogda farklı yazılabiliyor; harita bunları elle eşliyor.
- Haritada olmayan kimlik gateway'e gitmiyor, eski sağlayıcıda kalıyor.
- Yeniden adlandırılan kimlikler adapter'ın model birleşimini genişletiyor.
- Genişletilen kimlikler diğer kataloğun model başına meta verisini taşımıyor.
Haritaya kimlik eklemeden önce yazımı doğrulama
# Katalog anahtarsiz okunabilir
curl -s https://llmtr.com/v1/models | jq -r '.data[].id' > ids.txt
# Eklemek istediginiz kimligin tam yazimini arayin
grep -x 'zai/glm-5.2' ids.txt
grep -x 'mistral/mistral-small-latest' ids.txt
# Onek farki suphesi varsa satici bazinda listeleyin
grep -E '^(xai|zai|mistral)/' ids.txt | head
Harcama muhasebesi ve anahtar doğrulama
Entegrasyonun ikinci teknik konusu maliyet kaydı. LLMTR yanıtlarında token sayıları dönüyor, istek başına hazır bir tutar alanı dönmüyor. Yalnızca yanıttaki tutar alanına bakan bir muhasebe bu çağrıları sıfır olarak kaydeder; bu yüzden dal, çağrının hangi kapıdan geçtiğini bilerek fiyatlandırma yapan bir yol izliyor ve kendi tarife tablosunu tutuyor. Tablo tahmin değil, katalogdan aktarım; dalın kendi notu bu satırların fatura ile karşılaştırılarak doğrulanmadığını da söylüyor.
Buradaki fiyatlandırma mantığı LLMTR tarafında da tutarlı: katalog fiyatlarına model başına marj eklenmiyor, LLMTR'nin yüzde 8 marjı yalnızca kredi yüklemede uygulanıyor. Kendi tarafınızda tutacağınız tablo bu nedenle satıcı liste fiyatlarını izliyor. Katalog değiştiğinde ya da bir satıcı fiyat güncellediğinde tabloyu yeniden okumak gerekiyor.
Anahtar doğrulaması ayrı bir tuzak. Model listesi uç noktası herkese açık olduğu için geçersiz anahtarla da başarı dönüyor ve doğrulama için kullanılamıyor. Dal bunun yerine tek token'lık bir tamamlama isteği gönderiyor ve bunu ücretsiz katalog satırlarından biri üzerinde yapıyor; dalda seçilen satır qwen/qwen3.6-27b-free. Aynı satırın public katalogda canlı olduğunu doğruladık.
Bu dalın yönlendirmediği modaliteler
Yazının başındaki kapsam sınırı burada somutlaşıyor. Dalın haritası yalnızca metin modellerini içeriyor; görsel, video, embedding ve yeniden sıralama işlerinin yolu bu değişiklikle değişmiyor. LLMTR'nin public kataloğunda bu işlemlere bağlı canlı satırlar bulunuyor, ancak onları OpenStory'nin üretim hattına bağlamak bu dalın konusu değil ve bu sürümde doğrulanmadı.
Bu ayrımı korumak, üretim işlerinin yoklama ve fatura kaydının bozulmamasını sağlıyor. Görsel veya video tarafını da gateway üzerinden almak isterseniz metin için yazılan haritanın aynısını o modalite için kurmanız, ilgili uç noktanın istek gövdesini karşılamanız ve maliyet kaydını ayrıca çözmeniz gerekir.
| Modalite | Bu dalda gateway'e gidiyor mu | Dayanak |
|---|---|---|
| Metin çağrıları | Evet, haritadaki kimlikler için | Ortam dosyasındaki açıklama ve model haritası |
| Görsel üretimi | Hayır | Harita yalnızca metin modellerini listeliyor |
| Video üretimi | Hayır | Medya işleri gönderildikleri sağlayıcıda kalıyor |
| Embedding ve yeniden sıralama | Hayır | Bu dalda karşılık gelen bir eşleme yok |
Sık sorulan sorular
Takımın hem OpenRouter hem LLMTR anahtarı varsa hangisi kullanılır?
Seçilen model gateway haritasında karşılık buluyorsa LLMTR anahtarı kullanılır; dal bunu bilinçli bir öncelik olarak tanımlıyor, çünkü anahtarı ekleyen takım o kapıyı seçmiş sayılıyor. Model haritada yoksa çağrı takımın OpenRouter anahtarıyla eski yolundan devam eder.
Haritada olmayan bir model seçilirse çağrı başarısız mı olur?
Hayır. Haritada karşılığı olmayan kimlik yönlendirilebilir sayılmıyor ve anahtar çözümü LLMTR'yi atlıyor; istek önceki sağlayıcısına gidiyor. Kod bilerek yakın bir modele düşmüyor, çünkü çağıranın istemediği bir modeli sessizce koymak yanlış sonucu gizler.
Video ve görsel üretimi de bu anahtarla mı ücretlendirilir?
Bu dalda hayır. Değişiklik metin çağrılarının yolunu değiştiriyor; üretim işleri gönderildikleri sağlayıcıda kalıyor ve kayıtları oradan yürüyor. Katalogda görsel ve video işlemlerine bağlı canlı satırlar bulunsa da bu dal onları yönlendirmiyor.
Anahtar doğrulaması neden model listesiyle yapılmıyor?
Model listesi uç noktası herkese açık ve geçersiz anahtarla da başarı döndüğü için doğrulama yapamaz. Dal bunun yerine ücretsiz bir katalog satırında tek token'lık bir tamamlama isteği gönderiyor ve yanıtın durumuna bakıyor.