Strix LLMTR kurulumu: model öneki, tekilleştirme ve rapor zinciri

Strix ne yapar, bu rehber neyi kapsar

Strix, Python ile yazılmış otonom bir güvenlik test ajanıdır. Model çağrılarını LiteLLM üzerinden yürütür, bu yüzden yeni bir sağlayıcı eklemek çoğunlukla bir yönlendirme meselesidir: hangi önek hangi istemciye düşecek ve taban adres nereden gelecek. Bu rehber tam olarak o katmanı anlatır.

Aşağıdaki her adım koşturmanın yetkili olduğu varsayımıyla yazılmıştır. Elinizde imzalı bir test izni, sınırları çizilmiş bir hedef listesi ve üretim dışı bir ortam bulunmalıdır. Bu üçü sağlanmadan model yapılandırmasının teknik olarak doğru olması hiçbir şey ifade etmez. Metin tespit atlatma, kitlesel tarama veya izinsiz hedefleme konularına girmez; yalnızca sağlayıcı yönlendirmesini ve model seçimini ele alır.

• Hangi dalda hangi yapılandırma yüzeyinin bulunduğu.
• Ortam değişkenlerinin hangi değeri nereye taşıdığı.
• Önek çözümlemesinin LiteLLM rotasına nasıl döndüğü.
• Bulgu tekilleştirmesinin neden kendi uç noktasını taşıdığı.

İki dal, iki yapılandırma yüzeyi

Entegrasyon üst akış deposuna alınmadı, dolayısıyla aracın yayımlanmış sürümünde aşağıdaki davranışların hiçbiri yoktur. Kod knowhycodata/strix deposunda iki ayrı dalda duruyor ve ikisi farklı şeyler yapıyor.

Belge dalı olan docs/add-llmtr-provider hiçbir çalışma zamanı davranışını değiştirmez; yalnızca mevcut LiteLLM yeteneğinin nasıl kullanılacağını yazar. Model değeri openai öneki ile yazılır ve taban adres elle verilir. Yerleşik dal olan feat/llmtr-native-provider ise llmtr önekini birinci sınıf hale getirir: önek tanındığı anda gateway adresi ve atıf başlıkları kendiliğinden yerleşir, kullanıcı yalnızca model adını ve anahtarı tanımlar.

Seçim pratikte şuna iner: belge dalında üç değişken, yerleşik dalda iki değişken tanımlarsınız. Elle verilen taban adres her iki dalda da önceliklidir, yani gateway’in önüne bir vekil koyduğunuzda davranış değişmez.

Ortam değişkenleriyle kurulum

Belge dalının kurulumu üç değişkenden ibarettir: model dizesi, anahtar ve taban adres. Anahtar panelde üretilir ve llmtr ön ekiyle başlar; başka bir ön ek gördüğünüzde yanlış sağlayıcının anahtarını kopyalamışsınız demektir.

Model dizesindeki baştaki openai öneki bir sağlayıcı tekrarı değildir. LiteLLM tarafında OpenAI uyumlu istemciyi seçen rota adıdır; ondan sonrası gateway’e gönderilen kanonik kimliktir. Katalogdaki herhangi bir model aynı biçimle çalışır, tek yapmanız gereken kimliğin önüne o rota adını koymaktır.

Atıf başlıkları isteğe bağlıdır ve her isteğe uygulanan bir JSON nesnesi olarak verilir. Taramaların panelde Strix adıyla ayırt edilmesini istiyorsanız bu değişkeni tanımlayın; yerleşik dalda aynı başlıklar zaten kendiliğinden ekleniyor.

Belge dalındaki üç değişkenli kurulum

export STRIX_LLM="openai/anthropic/claude-sonnet-5"
export LLM_API_KEY="llmtr-your_key"
export LLM_API_BASE="https://llmtr.com/v1"

# İsteğe bağlı: taramaların panelde ayırt edilmesi için atıf başlıkları
export LLM_EXTRA_HEADERS='{"HTTP-Referer":"https://strix.ai","X-Title":"Strix"}'

Önek çözümlemesi: llmtr nasıl LiteLLM rotasına dönüyor

Yerleşik dalda model çözümleyicisi strix/config/models.py dosyasında yaşar. Önek llmtr olarak tanındığında, kalan dize LiteLLM’in OpenAI uyumlu rotasının önüne yapıştırılır. İç içe ad alanı korunur, yani Türkiye’de barındırılan bir satırda önek iki kez görünür ve bu bir yazım hatası değildir: ilki rota seçicisi, ikincisi kimliğin kendi ad alanıdır.

Tanıma toleranslıdır. Büyük harfle yazılmış bir önek de, baştaki ve sondaki boşluklar da kabul edilir. Buna karşılık başka bir sağlayıcının öneki geldiğinde yönlendirici hiçbir şey yapmaz; ne taban adres atar ne başlık ekler.

Yönlendirme yapılandırıcısı iki iş yapar. Taban adres elle verilmemişse gateway kökünü LiteLLM varsayılanı olarak atar, elle verilmişse ona dokunmaz. Atıf başlıklarını ise her durumda mevcut başlıklarla birleştirir. Böylece vekil arkasından çalışan bir kurulumda bile taramalar panelde ayırt edilebilir kalır.

Model dizesinin çözümlenmiş rotaya dönüşümü

STRIX_LLM=llmtr/anthropic/claude-sonnet-5   ->  openai/anthropic/claude-sonnet-5
STRIX_LLM=llmtr/openai/gpt-5.5              ->  openai/openai/gpt-5.5
STRIX_LLM=llmtr/llmtr/gemma-4               ->  openai/llmtr/gemma-4
STRIX_LLM=LLMTR/openai/gpt-5.5              ->  openai/openai/gpt-5.5
STRIX_LLM=openrouter/anthropic/claude-sonnet-5  ->  dokunulmaz, LLMTR yönlendirmesi devreye girmez

Bulgu tekilleştirmesi kendi uç noktasını taşır

Strix bulguları rapora yazmadan önce tekilleştirir ve bu iş için ana modelden ayrı bir model tanımlanabilir. Ayrı model, ayrı anahtar ve ayrı taban adres için kendi değişkenleri vardır; tekilleştirme isteği bu değerleri çağrı başına ek argüman olarak taşır.

Buradaki incelik şu: LiteLLM’in küresel taban adres varsayılanı ana modelden türetilir. Ana model başka bir sağlayıcıda çalışıyorsa o varsayılan tekilleştirme modeli için yanlıştır ve istek gateway’e hiç ulaşmaz. Bu yüzden tekilleştirme modeli llmtr önekli olduğunda ve elle bir adres verilmediğinde, gateway adresi isteğin kendisine sabitlenir.

Kural iki yönde de temizdir: elle verilen tekilleştirme adresi her zaman kazanır, llmtr önekli olmayan bir tekilleştirme modeline ise hiçbir adres enjekte edilmez. Böylece ana model ile tekilleştirme modelinin farklı sağlayıcılarda olması desteklenen bir kurulum haline gelir.

• Ana model ve tekilleştirme modeli farklı sağlayıcılarda olabilir; her biri kendi anahtarını taşır.
• Tekilleştirme için elle bir taban adres tanımlarsanız gateway varsayılanı devreye girmez.
• Tekilleştirme modeli llmtr önekli değilse adres enjeksiyonu hiç yapılmaz.
• Rapora hangi bulgunun hangi model tarafından tekilleştirildiğini yazmak, sonradan yapılan incelemeyi kolaylaştırır.

Belgede listelenen Türkiye satırları ve araç çağrısı uyumu

Belge dalı iki liste veriyor: sınır modelleri ve Türkiye’de barındırılan satırlar. Aynı sayfanın faydalar bölümü ise Strix’in yerel araç çağrılarına dayandığını söylüyor. Bu iki ifade birlikte okunduğunda bir eleme çıkıyor, çünkü listelenen her satır ajan döngüsüne uygun değil.

Araç çağrısı bayrağı katalogda model başına ölçülür, aile bazında kopyalanmaz. Aşağıdaki tablo belgede geçen Türkiye satırlarının bugünkü durumunu gösteriyor. Araç çağrısı bulunmayan bir satır özetleme veya metin üretimi için kullanılabilir, ama araç çağıran bir ajan döngüsünde yanlış seçimdir.

Rapor zinciri, doğrulama ve dalların kapsamadıkları

İstek başlıkları model adına göre kurulur: kimlik llmtr önekli olduğunda atıf başlıkları eklenir, kullanıcının kendi tanımladığı başlıklar sonradan birleştiği için sizin değeriniz korunur. Sınır modeli kontrolü de llmtr önekli kimlikleri kabul eder, yani önek yüzünden bir model bilinmeyen sayılıp elenmez.

Bu dalların kapsamadığı üç şey var ve bunları uydurmak yerine açıkça yazmak daha doğru. Kurulum komutu, ajanın çalıştığı yalıtılmış ortamın kendisi ve rapor dosya biçimi bu değişikliklerin dışında kalıyor; ilgili diff’ler yalnızca model yönlendirmesini, istek başlıklarını ve tekilleştirme uç noktasını değiştiriyor. Aracın kendi kurulum belgesi bu konularda geçerli kaynaktır.

• İlk doğrulama: model dizesi çözümlendikten sonra hangi rotaya düştüğünü kontrol edin.
• İkinci doğrulama: tek bir kısa istek gönderin, kimlik doğrulama hatası alıyorsanız anahtar ön ekine bakın.
• Üçüncü doğrulama: tekilleştirme modeli tanımlıysa onun için ayrı bir istek daha deneyin.
• Kimlik kanonik biçimde değilse gateway isteği eşleştiremez; katalogdaki yazımı birebir kopyalayın.

Sık sorulan sorular

Model dizesinde openai öneki neden iki kez görünüyor?

Baştaki önek LiteLLM tarafında OpenAI uyumlu istemciyi seçen rota adıdır, ikinci parça ise gateway’e gönderilen kanonik kimliğin kendi ad alanıdır. Sınır modelleri için ikisi farklı göründüğü halde Türkiye satırlarında aynı sözcük iki kez yazılır; bu beklenen davranıştır.

Ana model ile tekilleştirme modeli farklı sağlayıcılarda olabilir mi?

Olabilir. Tekilleştirme için ayrı model, ayrı anahtar ve ayrı taban adres tanımlanabilir. Tekilleştirme modeli llmtr önekli olduğunda ve elle bir adres verilmediğinde gateway adresi o isteğe sabitlenir, böylece ana modelin sağlayıcısından bağımsız çalışır.

Yayımlanmış Strix sürümünde LLMTR seçeneğini göremiyorum, neden?

Entegrasyon üst akışa alınmadı. Belge yüzeyi knowhycodata/strix deposunda docs/add-llmtr-provider dalında, önek çözümlemesi ise feat/llmtr-native-provider dalında duruyor. Belge dalındaki üç değişkenli kurulum, önek desteği olmayan bir sürümde de çalışır çünkü mevcut LiteLLM davranışını kullanır.

Bu kurulum hangi ortamda kullanılmalı?

Yalnızca yetkili bir testte. İmzalı test izni, sınırları çizilmiş hedef listesi ve üretim dışı bir ortam ön koşuldur. Rehber sağlayıcı yönlendirmesini anlatır; hedef seçimi, tespit atlatma veya kitlesel tarama kapsam dışıdır.

İlgili yazılar

• LLMTR entegre geliştirici araçları: 21 aracın bağlanma biçimi
• HarnessRouter LLMTR sağlayıcısı: tek anahtarla üç harness
• PentestCode LLMTR sağlayıcı kurulumu ve yetkili test yapılandırması

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