Open WebUI’yi LLMTR’ye bağlama: sohbet listesini temiz tutan filtre

Katalog geldiği gibi sohbet listesine düşüyor

Open WebUI kendi sunucunuzda çalışan çok kullanıcılı bir sohbet arayüzüdür. Model seçici, tanımlı her bağlantının model listesini alır ve tek bir listede birleştirir. Bağlantı doğrudan bir model sunucusuna gidiyorsa bu liste zaten sohbet modellerinden oluşur ve sorun çıkmaz.

Bağlantı bir gateway’e gidiyorsa durum değişir. Gateway önüne aldığı bütün sağlayıcıların katalogunu tek listede yayımlar; o katalogda gömme, yeniden sıralama, görsel üretimi, video üretimi ve ses modelleri de bulunur. Open WebUI bu kayıtların hepsini sohbet modeli olarak listeler. Kullanıcı bunlardan birini seçtiğinde istek sohbet ucuna gider, model o ucu sunmadığı için tur daha ilk mesajda hata ile biter.

Yani sorun bağlantı kurulumunda değil, listenin nasıl kurulduğundadır. Yüzlerce satırlık bir katalogda bu, seçicinin kullanılabilirliğini doğrudan etkiler: sohbet edilebilen modeller, edilemeyenlerin arasına karışır.

Bağlantıyı kurun, katalogu önce anahtarsız inceleyin

LLMTR tarafında bağlantı için iki değer yeterlidir: taban URL ve API anahtarı. Anahtarlar llmtr- öneki ile başlar ve Open WebUI’nin yönetici bağlantı ekranına olduğu gibi girilir. Model kimlikleri saglayici/model biçimindedir, yani listede gördüğünüz adı kısaltmadan kullanırsınız.

Katalogu bağlantıyı kurmadan önce de görebilirsiniz, çünkü model listesi ucu anahtarsız okunur. Her kayıt hangi operasyonları sunduğunu supported_operations alanında, o operasyonların karşılık geldiği gateway rotalarını supported_endpoints alanında taşır. Aşağıdaki komut listeyi bu alanlarla birlikte döker; kaç kaydın sohbet dışı olduğunu bağlantıyı hiç kurmadan görürsünüz.

Model listesi anahtarsız okunur; operasyon alanı her kaydın yanında gelir

# Open WebUI baglanti ekranina girilen iki deger
# Taban URL: https://llmtr.com/v1
# Anahtar:   llmtr-your_key

curl -s https://llmtr.com/v1/models \
  | jq -r '.data[] | [.id, (.supported_operations | join("+"))] | @tsv' \
  | sort -k2

# Yalnızca sohbet dışı kayıtları saymak için:
curl -s https://llmtr.com/v1/models \
  | jq '[.data[] | select((.supported_operations | index("CHAT_COMPLETIONS")) | not)] | length'

Düzeltme model listesini nasıl daraltıyor

Düzeltme knowhycodata/open-webui deposunda fix/gateway-non-chat-model-filter dalında duruyor ve backend/open_webui/routers/openai.py dosyasına supports_text_generation adında tek bir yardımcı ekliyor. Bu yardımcı, katalogun model listesine çevrildiği iki yerde uygulanıyor: bütün bağlantıların yanıtlarını toplayan yol ve tek bağlantının model kimliklerini döndüren yol.

Karar tek bir soruya iniyor: bu kayıt, bu bağlantının kullandığı metin üretimi ucunu sunuyor mu? Bağlantının api_type değeri responses ise aranan operasyon RESPONSES, değilse CHAT_COMPLETIONS oluyor. Kayıt supported_operations gönderiyorsa doğrudan o listeye bakılıyor; göndermiyorsa supported_endpoints alanındaki uç adlarının sonuna bakılıyor.

Yamanın en önemli tarafı ne yapmadığı. Hiçbir alan göndermeyen sağlayıcı sohbet yapabilir kabul ediliyor, yani düz OpenAI, Ollama ve vLLM bağlantılarının davranışı hiç değişmiyor. Ayrıca elle model kimliği listesi tanımlanmış bağlantılara dokunulmuyor.

• Alan gönderen bağlantılarda liste, istenen operasyonu ilan eden kayıtlarla sınırlanır.
• supported_operations yoksa veya boşsa karar supported_endpoints alanındaki uç adına göre verilir.
• Hiçbir alan göndermeyen sağlayıcı sohbet yapabilir sayılır; mevcut kurulumlar bozulmaz.
• Model kimlikleri elle yazılmış bağlantılar filtrenin dışında bırakılır.

Responses bağlantıları ve köprünün tek yönlü kısmı

LLMTR’de bir modelin sohbet ucundan çağrılabilmesi için CHAT_COMPLETIONS binding’i şart değildir: RESPONSES binding’i olan modeller de sohbet ucundan çalışır. Ters yön böyle değildir; yalnız sohbet binding’i olan bir modeli Responses ucundan çağıramazsınız. Köprü tek yönlüdür.

Filtre bu köprüyü bilmez, çünkü kararı yalnız kaydın ilan ettiği operasyona bakarak verir. Sonuç şu: sohbet tipi bir bağlantıda yalnız RESPONSES ilan eden kayıtlar listeden düşer, oysa gateway o isteği karşılayabilirdi. Katalogda openai/gpt-5.6-terra ve xai/grok-4.6 bu durumdadır. google/gemini-3.7-flash gibi iki binding’i birden taşıyan kayıtlar her iki bağlantı tipinde de listede kalır.

Bağlantıyı responses tipinde kurarsanız denklem tersine döner: bu kez yalnız sohbet binding’i taşıyan anthropic/claude-sonnet-5 ve llmtr/gemma-4 gibi kayıtlar listeden düşer, ve bu doğrudur çünkü o istek gerçekten karşılanmaz.

• Sohbet tipi bağlantı, sohbet ve Responses binding’i olan modellerin ikisini de çağırabilir.
• Responses tipi bağlantı yalnız RESPONSES binding’i olan modellerde çalışır.
• Filtre köprüyü hesaba katmadığı için sohbet tipi bağlantıda birkaç geçerli model gereksiz yere elenir.
• Bu kaydı listede tutmak isterseniz onu elle model kimliği listesine eklemeniz gerekir.

Yamayı uygulamıyorsanız: elle model kimliği listesi

Open WebUI’nin kendi sürümünde bu filtre yok; orada bağlantı başına elle yazılan bir model kimliği listesi var. O liste doluysa Open WebUI katalogdan gelen kayıtları olduğu gibi kabul eder ve seçici yalnız sizin yazdığınız kimliklerden kurulur. Yamalı sürümde de bu bağlantılara dokunulmaz, yani iki yaklaşım çakışmaz.

Bu yol, kısa ve sabit bir model seti çalıştıran kurulumlarda yeterlidir. Bedeli, katalog değiştikçe listeyi elle güncellemek zorunda kalmanızdır: yeni bir model geldiğinde kimse fark etmez, emekli olan bir model listede kalmaya devam eder. Filtre ise listeyi her katalog çekilişinde yeniden hesaplar.

Pratikte ikisini birlikte kullanmak da mantıklıdır: gündelik bağlantı filtreye bırakılır, önceden RESPONSES binding’i seçilmiş özel bir bağlantı ise elle listeyle sabitlenir.

Bağlantı yapılandırmasındaki elle model kimliği listesi katalog süzmesini devre dışı bırakır

{
  "model_ids": [
    "anthropic/claude-sonnet-5",
    "google/gemini-3.7-flash",
    "llmtr/gemma-4"
  ]
}

Çok kullanıcılı kurulumda ne değişir

Filtre kullanıcı düzeyinde değil bağlantı düzeyinde çalışır. Bir bağlantının yapılandırmasına dokunduğunuzda o bağlantıyı kullanan herkesin seçicisi birlikte değişir; kullanıcı başına ayar tutmanız gerekmez. Aynı sunucuda iki bağlantı tanımlayıp birini sohbet, diğerini Responses tipinde kurabilir, ekiplere farklı listeler verebilirsiniz.

Maliyet tarafı arayüzden bağımsızdır. Ücretlendirme token bazlıdır ve kredi bakiyesinden düşer; hangi modelin seçildiği doğrudan tüketimi belirler. LLMTR’de platform marjı yalnız kredi yüklemede uygulanır ve yüzde 8’dir, model fiyatlarına marj eklenmez. Kısa listeler bu yüzden yalnız kullanılabilirlik değil, harcama öngörülebilirliği meselesidir.

Gizlilik tarafında bilmeniz gereken tek şey şudur: kullanıcı istemleri ve model yanıt gövdeleri veritabanına kaydedilmez. Sohbet geçmişini saklayan taraf, kendi sunucunuzda çalışan Open WebUI kurulumunuzdur.

Sık sorulan sorular

Sağlayıcı operasyon alanı göndermezse modelleri kaybeder miyim?

Hayır. Hiçbir alan göndermeyen kayıtlar sohbet yapabilir kabul edilir ve listede kalır. Düz OpenAI, Ollama ve vLLM bağlantıları bu yüzden yamadan etkilenmez; filtre yalnız alan yayımlayan kataloglarda devreye girer.

Bu düzeltme Open WebUI’nin kendi sürümünde var mı?

Hayır. Değişiklik knowhycodata/open-webui deposunda fix/gateway-non-chat-model-filter dalında duruyor. Open WebUI’nin kendi sürümünde eşdeğer bir alan okuması yok; oradaki karşılık bağlantı başına elle yazılan model kimliği listesidir.

Gömme ve yeniden sıralama modellerini artık kullanamaz mıyım?

Filtre yalnız sohbet model seçicisini daraltır. Gömme ve yeniden sıralama kayıtları kendi uçlarından çağrılmaya devam eder; bu yama o çağrıları kapatmaz, sadece sohbet listesinden çıkarır. Bir kaydın hangi uçlara gittiğini model listesindeki uç alanından görebilirsiniz.

Sohbet listesinde beklediğim bir model görünmüyorsa nereye bakmalıyım?

Önce model listesi ucundan o kaydın operasyon alanını okuyun. Yalnız RESPONSES yazıyorsa ve bağlantınız sohbet tipindeyse kayıt filtreye takılmıştır; onu elle model kimliği listesine ekleyerek geri getirebilirsiniz. Alan boş dönüyorsa kayıt bugün hiçbir yayımlanmış uçtan çağrılamıyor demektir.

İlgili yazılar

• LLMTR entegre geliştirici araçları: 21 aracın bağlanma biçimi
• models.dev LLMTR sağlayıcı kaydı ve model metadata senkronu
• Open SEO’nun SAM ajanını LLMTR üzerinden çalıştırma rehberi

• Model katalogu
• Chat Completions rehberi
• API anahtarlari
• Fiyatlandirma