OpenReview kod inceleme botunu LLMTR'ye bağlama

OpenReview ne yapıyor ve varsayılan olarak nereye bağlanıyor

OpenReview, kendi kendine barındırılan açık kaynaklı bir kod inceleme botu. Vercel üzerine dağıtılıyor, bir GitHub App ile depoya bağlanıyor ve pull request açıldığında incelemeyi dayanıklı bir iş akışı olarak yürütüyor. İnceleme yorumlarının altındaki olumlu tepkiler önerilerin uygulanmasını onaylıyor, olumsuz tepkiler öneriyi atlıyor. Talimat kümesi .agents/skills/ altından çalışma anında keşfediliyor; ajan sistem isteminde yalnızca beceri adlarını ve açıklamalarını görüyor, ayrıntıyı gerektiğinde yüklüyor.

Model çağrıları varsayılan olarak dağıtım platformunun kendi gateway'i üzerinden çözülüyor. İncelemeyi yapan model MODEL değişkeniyle belirleniyor ve bu değişken ayarlanmadığında anthropic/claude-sonnet-4.6 kimliği kullanılıyor. Yönlendirme lib/model.ts dosyasında duruyor; ajan modeli yalnızca resolveModel çağrısıyla istiyor ve isteği hangi kapının yanıtladığını bilmiyor.

Bu rehberin anlattığı seçenek knowhycodata/openreview deposundaki openai-compatible-gateway dalında bulunuyor. Değişiklik upstream sürüme alınmadı, dolayısıyla resmi dağıtımı kuran bir okuyucu bu değişkenleri bulamaz. Kurulumu yapmadan önce kodu bu daldan almanız gerekiyor.

Değişikliğin büyüklüğü: üç değişken, sıfır kod

Dalın eklediği yetenek tek cümleyle özetlenebilir: model çağrıları OpenAI uyumlu herhangi bir uç noktaya yönlendirilebiliyor. Bunun için yeni bir sağlayıcı sınıfı, yeni bir adapter ya da yapılandırma dosyası yok. MODEL_BASE_URL ayarlandığı anda bütün çağrılar o adresin sohbet tamamlama yoluna gidiyor.

Üç değişkenin üçü de isteğe bağlı ve birbirinden bağımsız görevler üstleniyor. MODEL_BASE_URL yolu belirliyor, MODEL_API_KEY o yolun kimlik doğrulamasını taşıyor, MODEL ise incelemeyi yapacak satırı seçiyor. Anahtar alanının isteğe bağlı olması bilinçli: kimlik doğrulaması istemeyen yerel bir sunucu yalnızca taban adres verilerek kullanılabiliyor. LLMTR bu gruba girmiyor, çünkü istekler yetkilendirme başlığındaki anahtarla karşılanıyor.

Dağıtım tarafında bu değişkenler proje ortamına ekleniyor. Değerin dağıtımda görünür olması gerektiği için, ekledikten sonra çalışan sürümün bu ortamı okuduğundan emin olun.

Yapılandırma: taban adres, anahtar ve model kimliği

LLMTR tarafında taban adres sürüm ekiyle birlikte veriliyor, çünkü istemci yolları bu değerin üzerine ekliyor. Anahtar llmtr önekiyle başlıyor ve doğrudan MODEL_API_KEY alanına giriyor. Deponun kendi belgesinde örnek model kimliği olarak zai/glm-5.3 geçiyor; bu satırın public katalogda canlı olduğunu ve sohbet tamamlama bağlantısı taşıdığını doğruladık.

Yapılandırmanın tamamı aşağıdaki üç satır. Bunun dışında dokunulacak bir dosya yok; ajan modeli yine aynı çağrıyla istiyor.

Kimlik dizesinin olduğu gibi iletildiğini unutmayın. MODEL değeri hedef katalogda birebir yazıldığı biçimde bulunmalı; küçük bir yazım farkı çalışma anında model bulunamadı hatasına dönüşür.

Varsayılan gateway'in yerini alan yapılandırma

MODEL_BASE_URL=https://llmtr.com/v1
MODEL_API_KEY=llmtr-your_key
MODEL=zai/glm-5.3

Model kimliğini seçmek ve uç nokta bağlantısını doğrulamak

Varsayılan kimlik olan anthropic/claude-sonnet-4.6 public katalogda aynı yazımla canlı. Yani ilk adımda MODEL değerine hiç dokunmadan yalnızca taban adres ve anahtar vererek geçiş yapılabiliyor; model seçimi ayrı bir karar olarak sonraya bırakılabiliyor.

Model değiştirirken iki şeye bakın. Birincisi satırın katalogda canlı olması: emekli işaretli satırlar yeni kurulumda örnek alınmaz, halefini seçin. İkincisi uç nokta bağlantısı. OpenReview isteği sohbet tamamlama yoluna gönderiyor; bu yol, satırın sohbet tamamlama bağlantısı olduğu durumda çalışıyor. Köprüsü olmayan yön tersi, yani yalnızca Responses bağlantısı taşıyan satırlara Responses yolundan gidilebiliyor.

Aşağıdaki iki komut geçişi tek seferde doğruluyor: kimliğin katalogda birebir bulunduğunu ve aynı anahtarla gerçek bir yanıt alındığını. İkinci komut kısa bir istek olduğu için inceleme akışını beklemeden sonuç veriyor.

Kimliği doğrulama ve tek istekle duman testi

# 1) Kimlik katalogda birebir var mi (anahtar gerekmez)
curl -s https://llmtr.com/v1/models \
  | jq -r '.data[].id' | grep -x 'zai/glm-5.3'

# 2) Ayni anahtarla gercek bir yanit aliniyor mu
curl -s https://llmtr.com/v1/chat/completions \
  -H "Authorization: Bearer llmtr-your_key" \
  -H "Content-Type: application/json" \
  -d '{"model":"zai/glm-5.3","max_tokens":16,"messages":[{"role":"user","content":"ping"}]}'

Pull request başına inceleme maliyetini yönetmek

Kod incelemesi tek bir soru sormuyor. Ajan depoyu geziyor, ilgili dosyaları okuyor, gerektiğinde beceri talimatlarını yüklüyor ve yorumları üretiyor. Deponun kendi belgesi bunu açıkça söylüyor: bir inceleme depoyu keşfederken çok sayıda token harcayabiliyor, bu yüzden kendi kurulumunu yapanlar varsayılandan daha düşük maliyetli bir modeli tercih edebiliyor.

Ücretlendirme token bazlı olduğu için bir pull request'in maliyeti üç şeyin çarpımı: incelemede okunan bağlam miktarı, üretilen yorum uzunluğu ve seçilen satırın tarifesi. İlk ikisi deponun ve değişikliğin doğasından geliyor; kurulumu yapanın kod yazmadan değiştirebildiği tek girdi üçüncüsü, yani MODEL. Bu yüzden model seçimi bu entegrasyonda bir kalite tercihi olduğu kadar bir bütçe kararı.

Pratikte işleyen bir düzen şöyle kurulabiliyor: kurulum ve duman testleri için katalogdaki ücretsiz satırlardan biri, örneğin qwen/qwen3.6-27b-free; gündelik incelemeler için sohbet tamamlama bağlantısı olan daha küçük bir satır; kritik depolarda ise varsayılan aileye geri dönüş. Üçü arasında geçiş yalnızca MODEL değerini değiştirmek demek. Harcama tarafında ise kredi bakiyesi tükendiğinde çağrılar durur; bakiyeyi izlemek, inceleme hacmi arttığında ilk bakılacak yer.

• İnceleme başına token tüketimi depo gezintisiyle birlikte artıyor.
• Kod değişikliği gerektirmeyen tek kaldıraç MODEL değeri.
• Duman testleri için katalogdaki ücretsiz satırlar kullanılabiliyor.
• Model fiyatlarına marj eklenmiyor; LLMTR'nin yüzde 8 marjı yalnızca kredi yüklemede uygulanıyor.

Doğrulama ve sık karşılaşılan hatalar

Geçişten sonra tek bir pull request açıp incelemeyi baştan sona izlemek en hızlı doğrulama. Yorum geliyorsa yol, anahtar ve model kimliği birlikte çalışıyor demektir. Gelmiyorsa aşağıdaki tablo hangi katmanda durduğunuzu daraltıyor.

Tablodaki nedenler dalın belgelediği davranışlardan ve LLMTR'nin uç nokta sözleşmesinden çıkarıldı; ölçüm değil, eşleme.

Sık sorulan sorular

Bu seçenek OpenReview'in resmi sürümünde var mı?

Hayır. Anlatılan değişkenler knowhycodata/openreview deposundaki openai-compatible-gateway dalında bulunuyor ve bu değişiklik upstream sürüme alınmadı. Resmi dağıtımı kuran bir okuyucu bu alanları göremez; kurulum için kodu o daldan almanız gerekir.

MODEL_BASE_URL ayarlandığında ANTHROPIC_API_KEY hâlâ gerekli mi?

Deponun ortam değişkenleri tablosu bu alanı listelemeye devam ediyor ve dal, yönlendirme yapıldığında alanın kaldırılabileceğini söylemiyor. Bu sürümde doğrulanmadı; kurulumu yaparken alanı kaldırmadan önce kendi dağıtımınızda deneyin.

Model değiştirmek için kod yazmam gerekir mi?

Hayır. İncelemeyi yapan satır MODEL değişkeniyle seçiliyor ve yönlendirme lib/model.ts içinde duruyor. Ajan modeli tek bir çözümleme çağrısıyla istiyor, isteği hangi kapının yanıtladığını bilmiyor.

Anahtar istemeyen bir uç noktaya bağlanabilir miyim?

Evet, MODEL_API_KEY isteğe bağlı olduğu için kimlik doğrulaması istemeyen yerel bir sunucu yalnızca taban adres verilerek kullanılabiliyor. LLMTR için bu geçerli değil: istekler yetkilendirme başlığında bir anahtar taşımak zorunda.

İlgili yazılar

• LLMTR entegre geliştirici araçları: 21 aracın bağlanma biçimi
• OpenBot’u LLMTR ile çalıştırmak: tek taban URL, iki ajan çalışma zamanı
• OpenStory'de LLMTR gateway'ini takım anahtarıyla bağlama

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