“OpenAI uyumlu” aslında ne anlama gelmek zorunda

“OpenAI uyumlu”, hem relay’leri hem kendi sunucunuza kurulan çözümleri satan ifadedir ve geniş bir aralığı kapsar. Bir ucunda mevcut kodun değişmeden taşındığı sadık bir yeniden uygulama vardır. Diğer ucunda benzer bir JSON gövdesini kabul edip benzerini döndüren bir URL. İkisi de aynı şekilde tarif edilir.

Gerçekten uyması gereken yüzey, kabaca uymadığında kırılma sırasıyla aşağıda.

Herkesin doğru yaptığı kısım

İstek gövdesi. model, rolleriyle messages, temperature, max_tokens ve choices[0].message.content artı bir usage bloğu içeren bir cevap. Bu çalışmasaydı uç hiç kullanılamazdı, o yüzden hep çalışır.

from openai import OpenAI

client = OpenAI(
    base_url="https://proxystation.co/v1",   # degisen tek satir
    api_key="sk-...",
)

resp = client.chat.completions.create(
    model="gpt-5.6-sol",
    messages=[{"role": "user", "content": "hi"}],
)

Değişen tek şeyin temel URL olması, ticari önerinin tamamıdır. Aynı zamanda ayrılmanın da ucuz olmasının sebebidir ve bu, herhangi bir relay müşterisinin sahip olduğu en güçlü korumadır.

Akış: uygulamaların ayrıştığı yer

İlk gerçek fay hattı. Sadık bir uygulama sunucu olaylarını geldikçe iletir, parça sınırlarını ve data: [DONE] sonlandırıcısını korur. Tembel olanı tüm üst akış cevabını bekler, sonra onu bir parça salvosu olarak tekrar oynatır.

Yalnızca birleştirilmiş son metni okuyan kod için bu ikisi ayırt edilemez. Token’ların belirmesini izleyen bir kullanıcı için tamamen farklı ürünlerdir: biri birkaç yüz milisaniyede cevaplamaya başlar, diğeri sessizce oturur ve sonra her şeyi bir anda döker. Arayüzünüz akış yapıyorsa bunu özellikle test edin — sessizce eksik kalması en muhtemel uyumluluk boşluğudur.

Kontrol edilmeye değer iki ilgili ayrıntı: usage son akış parçasında dönüyor mu, çünkü bazı uygulamalar onu düşürür ve muhasebeniz ona bağlıdır; ve istemci bağlantıyı kestiğinde bağlantı temiz kapanıyor mu, çünkü siz koptuktan sonra üst akışta üretmeye devam eden bir relay, kimsenin okumayacağı token’ları size faturalandırıyordur.

Hatalar: neredeyse kimsenin doğru yapmadığı

OpenAI hata sözleşmesi belirlidir: bir HTTP durumu ve error.type, error.code, error.message içeren bir gövde. İstemci kütüphaneleri bu alanlara göre dallanır — hız sınırında yeniden dener, geçersiz istekte hızlı başarısız olur.

Yaygın başarısızlık, gövdede bir iş hatasıyla HTTP 200 dönen bir sunucudur. Her SDK bunu başarı sayar. Yeniden deneme mantığınız hiç tetiklenmez, hata izlemeniz sessiz kalır ve başarısızlık daha sonra bir dizenin olması gereken yerde bir null olarak yüzeye çıkar.

Araçlar, yapılandırılmış çıktı ve uzun kuyruk

Düz metin tamamlamasının ötesinde yüzey genişler ve destek düzensizleşir. Kabaca eksik olma sıklığı sırasıyla:

Dikkat edilecek desen baştan sona aynı: kabul edilip yok sayılan bir parametre. Desteklenmeyen bir parametreyi reddetmek dürüsttür ve ele alması kolaydır. Kabul edip hiçbir şey yapmamak, çalışıyor görünen ve sessizce çalışmayan bir sistem üretir; bunu keşfetmek çok daha pahalıdır.

Sistem istemi meselesi

Bazı relay’ler kendi sistem istemlerini enjekte eder — güvenlik, marka veya davranışı şekillendirmek için. Bu, modeli değiştirmeden üslubu, biçimi ve reddetme sınırlarını değiştirir.

Bunun iki kere önemi var. İstem mühendisliğinizi daha az öngörülebilir kılar, çünkü artık bağlamın tek yazarı siz değilsinizdir. Ve bir relay’i canary ile test ederken en yaygın yanlış pozitiftir: sağlayıcınınkinden üslupça farklı ama ayırt edici olguları hâlâ eşleşen cevaplar, genelde ikame edilmiş bir modeli değil enjekte edilmiş bir istemi gösterir.

İki protokol, tek uç

Bazı relay’ler birden fazla lehçe konuşur. Bu istasyon aynı temel URL’de hem OpenAI sohbet tamamlama biçimini hem Anthropic mesaj biçimini kabul eder; bir Anthropic SDK’sının — veya onun üzerine kurulmuş bir aracın — çağrı yerini yeniden yazmadan buraya yöneltilebilmesinin sebebi budur.

Ayrım anlaşılmaya değer çünkü iki protokol gerçek şeylerde anlaşamaz. Anthropic sistem istemini rol taşıyan bir mesaj olarak değil üst düzey bir parametre olarak alır; çok kipli girdi için içerik bloğu yapısı farklıdır; ve durma sebepleri farklı adlandırılır. İkisini birden iddia eden bir relay çeviri yapmak zorundadır ve davranışın kaybolduğu yer çeviridir.

Buna güveniyorsanız kontrol edilecekler: sistem istemi gönderdiğiniz biçimde hayatta kalıyor mu, durma sebepleri kodunuzun dallanabileceği bir şeye eşleniyor mu, ve akış işletmecinin kendi kullandığı lehçede değil her iki lehçede de çalışıyor mu.

Hız sınırları ve başlıkların anlattığı

Sağlayıcılar hız sınırı durumunu cevap başlıklarında döndürür — kalan istek, kalan token ve pencerenin ne zaman sıfırlanacağı. İyi davranan istemciler bunları okur ve duvara yeniden denemek yerine kendilerini ayarlar.

Relay’ler bunlarla ne yaptıkları konusunda ayrışır. Faydadan azalan sırayla üç davranış:

Üçüncü durum yaygındır ve atlatılabilir, ama sahip olduğunuz tek ayarlamanın yeniden deneme politikanız olduğu anlamına gelir — yani sabit gecikme değil, sıçramalı üstel geri çekilme olmalıdır. Sıfırlama ipucu olmayan bir 429’u sabit zamanlayıcıyla yeniden denemek, tam da yavaşlamanızı isteyen uca karşı bir sürü hücumu üretir.

İlgili ve gözden kaçması kolay: üst akıştan gelen bir 429 size 429 olarak mı ulaşıyor yoksa 500’e mi çevriliyor. İkisi farklı istemci davranışı gerektirir — biri bekle der, diğeri bir şey bozuk der — ve ikisini birleştiren bir relay ayırt etme yeteneğinizi elinizden alır.

On dakikalık bir uyumluluk kontrolü

1. 01GET /v1/models — beklediğinizi listeliyor mu ve anahtarınız erişiyor mu?
2. 02Akışsız düz bir tamamlama. usage okuyun ve faturalandırıldığınızla karşılaştırın.
3. 03Aynı istek akışlı. İlk parçayı süreleyin; sonunda usage geldiğini doğrulayın.
4. 04Var olmayan bir model adı. 200 değil, tipli hatayla 404 bekleyin.
5. 05Bozuk bir gövde. Tipli hatayla 400 bekleyin.
6. 06Kullanıyorsanız bir araç çağrısı. Argümanların JSON olarak ayrıştığını kontrol edin.
7. 07Akışlı bir isteği yarıda kesin ve ücretin durduğunu doğrulayın.

Yedi istek, ve size bir uç hakkında herhangi bir dokümantasyondan fazlasını söylerler. Bizim temel URL’imiz https://proxystation.co/v1 ve API dokümanları OpenAI SDK, Anthropic SDK ve düz cURL için aynı kurulumu gösteriyor — ama yediyi yine de çalıştırın, burada ve değerlendirdiğiniz her yerde.

Uyumluluk, bir relay’i benimsemeyi de bırakmayı da ucuz kılan şeydir. Relay’lere dair geniş rehber geri kalanını, canary testi ise uyumluluğun size veremeyeceği tek kontrolü ele alıyor: cevaplayan modelin adını verdiğiniz model olup olmadığı.