Codex CLI için LLMTR model sağlayıcısı: Responses zorunluluğu

Tel protokolünde artık tek varyant var

Codex CLI için ayrı bir sürüm veya yama gerekmez; sağlayıcı tanımı kendi yapılandırma dosyanızda yaşar. Ancak bu esnekliğin bir sınırı var ve rehberin geri kalanı o sınırın etrafında dönüyor: aracın protokol numaralandırması bugün tek bir varyant içeriyor, o da Responses.

Kaynaktaki numaralandırma yalnızca responses değerini kabul ediyor ve bu değer aynı zamanda varsayılan. Eski chat değeri artık ayrı bir hata mesajıyla reddediliyor; tanınmayan başka bir değer yazarsanız çözümleyici geçerli seçenek olarak yine sadece responses gösteriyor. Yani araç tarafında sohbet tamamlama protokolüne dönüş yolu kalmamış durumda.

Yapılandırmada eski protokol değeri kullanıldığında dönen mesaj

`wire_api = "chat"` is no longer supported.
How to fix: set `wire_api = "responses"` in your provider config.

Sağlayıcı tablosunu config.toml içine yazmak

Sağlayıcılar iki yerden gelir: ikiliye derlenmiş yerleşik varsayılanlar ve kullanıcının yapılandırma dosyasındaki model_providers anahtarı altındaki kayıtlar. Yerleşik küme dar tutulmuş; içinde openai, iki Amazon Bedrock girdisi ve yerel çalıştırma için ollama ile lmstudio bulunuyor. Üçüncü taraf sağlayıcıların kullanıcı tarafından eklenmesi bilinçli bir tasarım tercihi olarak açıklanıyor.

Burada kolayca gözden kaçan bir davranış var: yerleşik kayıtlar genel olarak üzerine yazılamaz. Birleştirme mantığı, Bedrock dışındaki anahtarlar için var olan girdiyi koruyup yenisini yalnızca anahtar boşsa ekliyor. Dolayısıyla openai anahtarını yeniden tanımlayarak LLMTR’ye yönlendirmeye çalışırsanız kaydınız sessizce yok sayılır. Yeni ve serbest bir kimlik seçin.

Alan adları sağlayıcı kaydından birebir gelir. Taban adres yol sonekini içerir: aracın yerleşik varsayılanı da /v1 ile biter, uç yolu bunun üzerine eklenir. Anahtar doğrudan dosyaya yazılmaz; env_key ile bir ortam değişkeninin adı verilir ve değer boşsa araç eksik değişkeni adıyla bildirir. Kayıt şeması bilinmeyen alanları reddettiği için yazım hatası yapılan bir alan adı yapılandırmayı bütünüyle geçersiz kılar.

Kullanıcı yapılandırmasına eklenen LLMTR sağlayıcı kaydı

model_provider = "llmtr"
model = "openai/gpt-5.3-codex"

[model_providers.llmtr]
name = "LLMTR"
base_url = "https://llmtr.com/v1"
env_key = "LLMTR_API_KEY"
wire_api = "responses"

Köprü tek yönlüdür, model seçimi buna göre daralır

LLMTR’de her modelin bir veya birden çok binding’i vardır. Responses ucuna gelen istek yalnızca Responses binding’i olan kimliklerde çalışır; sohbet tamamlama tarafına açılmış bir modeli bu uçtan çağırmanın bir yolu yoktur. Codex CLI de sadece bu ucu konuştuğuna göre, iki kısıt üst üste biner ve seçilebilecek küme kataloğun bir alt kümesine iner.

Uygulamada yapılacak iş şudur: model kimliğini yapılandırmaya yazmadan önce katalogda o kimliğin desteklenen operasyonlarına bakın. Sohbet tamamlamaya bağlı bir kimlik yazılırsa istek yapılandırma aşamasında değil, ilk çağrıda başarısız olur; terminalde göreceğiniz şey uç uyuşmazlığı hatasıdır. Aşağıdaki tablo katalogda bugün bulunan birkaç kimliği bu gözle karşılaştırıyor.

Codex ailesinde emekli kimliklere dikkat

Bu rehberi hazırlarken çıkan bir bulguyu ayrıca söylemek gerekiyor: Responses ucu dokümantasyonunda örnek olarak geçen Codex model kimliklerinin çoğu katalogda artık emekli durumda. Emekli kayıtlar erişilebilir kalır ve sayfaları yayında durur, ancak yeni bir kurulumda örnek olarak alınmamalıdır.

Bugün canlı olan tek Codex kimliği openai/gpt-5.3-codex. Elinizde eski bir yapılandırma varsa model satırını bununla değiştirin. İnternette bulduğunuz örnekleri kopyalarken kimliği katalogdan bir kez daha doğrulamak, ilk çağrıda alınacak bir hatadan daha ucuza gelir.

Reasoning effort iki farklı yerden verilebilir

Responses ucu akıl yürütme seviyesini iki yoldan kabul eder. Birincisi model kimliğine eklenen sonek, ikincisi istek gövdesindeki reasoning nesnesi. İkisi birden gönderilirse gövdedeki değer kazanır. Codex CLI tarafında gövdeye doğrudan müdahale etmek yerine kimliğe sonek yazmak daha pratiktir, çünkü yapılandırmada zaten bir model satırı vardır.

Seviyeler minimal, low, medium, high ve xhigh olarak tanımlıdır; sonek yazımında med ve max gibi kısa karşılıklar da kabul edilir. Desteklenmeyen bir seviye gönderildiğinde 400 ile yetenek uyuşmazlığı, tanınmayan bir sonek yazıldığında yine 400 ile geçersiz istek hatası döner. Yüksek seviyeler genellikle daha fazla çıktı tokeni ve daha uzun süre üretir; ücretlendirme token bazlı olduğu için bu seçim doğrudan maliyete yansır.

• Sonek biçimi kimliğin sonuna iki nokta ile eklenir ve yapılandırmadaki model satırında durur
• Gövde alanı aynı isteği tek seferlik olarak farklı bir seviyeye çekmek istediğinizde kullanışlıdır
• İki yol birlikte kullanılırsa gövde alanı geçerli olur
• Tanınmayan sonekler sessizce yok sayılmaz, istek reddedilir

Akıl yürütme seviyesini model satırına sonek olarak yazmak

model_provider = "llmtr"
model = "openai/gpt-5.3-codex:high"

[model_providers.llmtr]
name = "LLMTR"
base_url = "https://llmtr.com/v1"
env_key = "LLMTR_API_KEY"
wire_api = "responses"
request_max_retries = 4

Doğrulama ve hataların ayrıştırılması

Aracı çalıştırmadan önce aynı kimliği tek bir istekle uca gönderin. Bu, yapılandırma hatası ile model seçimi hatasını birbirinden ayırmanın en hızlı yoludur: istek doğrudan çalışıyorsa sorun sağlayıcı kaydındadır, istek burada da düşüyorsa sorun model kimliğindedir.

Hataları kaynağına göre üç kümede düşünmek işe yarar. Yapılandırma çözümleme hataları araç açılırken çıkar ve dosyadaki bir alanı işaret eder. Kimlik hataları ortam değişkeni okunamadığında çıkar ve değişkenin adını söyler. Uç hataları ise ilk çağrıda gelir ve gövdedeki hata türü hangi kısıtı çiğnediğinizi belirtir.

• Uç uyuşmazlığı hatası, seçilen modelin Responses binding’i olmadığını gösterir
• Yetenek hatası, modelin istenen akıl yürütme seviyesini desteklemediğini gösterir
• Kimlik doğrulama hatası, env_key ile verilen değişkenin boş veya geçersiz olduğunu gösterir
• Bakiye hatası, kredi yüklemesi gerektiğini gösterir; platform marjı yalnızca kredi yüklemede uygulanır ve yüzde sekizdir

Model kimliğini araçtan bağımsız olarak sınama

export LLMTR_API_KEY=llmtr-your_key

curl https://llmtr.com/v1/responses \
  -H "Authorization: Bearer $LLMTR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"openai/gpt-5.3-codex","input":"ping"}'

Sık sorulan sorular

Codex CLI için ayrı bir sürüm kurmam gerekiyor mu?

Hayır. Sağlayıcı kaydı kullanıcı yapılandırmasına eklenir ve araç bu kaydı yerleşik listeye ekler. Değiştirilmiş bir ikili veya ayrı bir depo gerekmez; gereken tek şey doğru alanlarla yazılmış bir model_providers tablosu ve anahtarı taşıyan bir ortam değişkenidir.

Sohbet tamamlamaya bağlı bir modeli neden seçemiyorum?

Araç yalnızca Responses protokolünü konuşuyor ve LLMTR tarafında Responses ucu yalnızca Responses binding’i olan kimlikleri kabul ediyor. İki kısıt aynı yöne baktığı için ters yönde köprü yok. Model kimliğini yazmadan önce katalogdaki desteklenen operasyon listesine bakın.

Yerleşik openai kaydını LLMTR’ye yönlendirebilir miyim?

Pratikte hayır. Birleştirme mantığı Bedrock dışındaki yerleşik anahtarlar için var olan kaydı korur, sizin girdiğiniz kayıt eklenmez. Sonuç bir hata değil sessiz bir yok sayma olduğu için teşhisi zordur. Bunun yerine llmtr gibi kullanılmamış bir kimlik seçin.

Akıl yürütme seviyesini artırmak maliyeti nasıl etkiler?

Yüksek seviyeler genellikle daha fazla çıktı tokeni üretir ve yanıt süresini uzatır. Ücretlendirme token bazlı olduğundan bu doğrudan tüketime yansır. Seviye seçimini görev başına ayarlamak, sabit bir yüksek değeri her oturumda taşımaktan daha ölçülüdür.

İlgili yazılar

• LLMTR entegre geliştirici araçları: 21 aracın bağlanma biçimi
• OpenClaude’a LLMTR gateway girdisi ekleme ve model keşfi
• Claude Code’u LLMTR’ye bağlama: Anthropic Messages ucu rehberi

• Model katalogu
• Responses ucu
• API anahtarlari
• Fiyatlandirma