Responses API'de WebSocket kullanarak ajan tabanlı iş akışlarını hızlandırıyoruz

Codex'ten bir hatayı düzeltmesini istediğinizde, ilgili dosyaları bulmak için kod tabanınızı tarar, bağlam oluşturmak üzere bu dosyaları okur, gerekli düzenlemeleri yapar ve düzeltmenin işe yarayıp yaramadığını doğrulamak için testleri çalıştırır. Bu sürecin arkasında, Responses API üzerinden tekrar tekrar yürütülen onlarca istek bulunur: model bir sonraki adımı belirler, bilgisayarınızda bir araç çalıştırılır, aracın çıktısı API'ye geri gönderilir ve bu döngü yeniden başlar.

Bu isteklerin tümü bir araya geldiğinde, kullanıcıların Codex'in karmaşık görevleri tamamlamasını beklerken harcadığı süre dakikaları bulabilir. Gecikme açısından bakıldığında, Codex ajan döngüsündeki sürenin büyük bölümü üç ana aşamada geçer: API hizmetleri (isteklerin doğrulanması ve işlenmesi); model çıkarımı; ve istemci tarafındaki süre (araçların çalıştırılması ve model bağlamının oluşturulması). Çıkarım, modelin GPU'larda çalışarak yeni tokenlar ürettiği aşamadır. Geçmişte, GPU'larda LLM çıkarımı çalıştırmak bu döngünün en yavaş kısmıydı; bu nedenle API servislerinin getirdiği ek yük büyük ölçüde göz ardı edilebiliyordu. Çıkarım hızlandıkça, ajan tabanlı kullanımda API'nin toplam gecikmeye etkisi daha belirgin hale geliyor.

Bu yazıda, API kullanarak ajan döngülerini uçtan uca nasıl %40 daha hızlı hale getirdiğimizi anlatıyoruz. Böylece kullanıcılar, çıkarım hızının saniyede 65 token'dan neredeyse 1.000 token'a çıkmasını doğrudan deneyimleyebiliyor. Bunu; önbelleğe alma, gereksiz ağ geçişlerini ortadan kaldırma, sorunları hızlıca tespit etmek için güvenlik katmanını iyileştirme ve en önemlisi, senkronize API çağrıları yerine Responses API'ye kalıcı bağlantı kurmayı sağlayan bir yapı geliştirerek başardık.

Responses API'de GPT‑5 ve GPT‑5.2 gibi önceki amiral modeller, yaklaşık saniyede 65 token (TPS) hızında çalışıyordu. Hızlı bir kodlama modeli olan GPT‑5.3 Codex-Spark'ın lansmanında hedefimiz büyük bir sıçrama yapmaktı: saniyede 1.000'in üzerinde token üretimi. Bu hız, LLM çıkarımı için optimize edilmiş özel Cerebras donanımı sayesinde mümkün oldu. Kullanıcıların bu yeni modelin gerçek hızını deneyimleyebilmesi için API kaynaklı ek yükü azaltmamız gerekiyordu.

2025 Kasım civarında Responses API üzerinde bir performans çalışması başlattık ve tek bir isteğin kritik yol gecikmesini azaltan birçok optimizasyon uyguladık:

• Çok turlu yanıtlar için maliyetli tokenizasyon ve ağ çağrılarını atlamak amacıyla işlenmiş token'ları ve model yapılandırmasını bellekte önbelleğe aldık
• Ara hizmet çağrılarını kaldırarak, örneğin, görsel işleme çözümlemesi yerine doğrudan çıkarım servisini çağırarak, ağ gecikmesini azalttık.
• Konuşmaları daha hızlı işaretleyebilmek için güvenlik katmanımızı iyileştirdik.

Bu iyileştirmelerle ilk token'a ulaşma süresinde (TTFT) yaklaşık %45 iyileşme sağladık. Bu metrik, API'nin ne kadar hızlı tepki verdiğini gösterdi. Ancak bu halen GPT‑5.3 Codex-Spark için yeterli değildi. Bu iyileştirmelere rağmen, Responses API'nin oluşturduğu ek yük, modelin hızına kıyasla halen çok yüksekti. Başka bir deyişle kullanıcılar, model GPU'larda çalışmaya başlamadan önce API'yi çalıştıran CPU'ların işlemlerini beklemek zorunda kalıyordu.

Asıl sorun yapısaldı: Her Codex isteğini bağımsız olarak ele alıyor, her takip isteğinde konuşma durumunu ve yeniden kullanılabilecek bağlamı baştan işliyorduk. Konuşmanın büyük kısmı değişmemiş olsa bile, tüm geçmişe bağlı işlemler için yeniden maliyet ödüyorduk. Konuşmalar uzadıkça bu tekrar eden işlem daha da maliyetli hale geliyordu.

Tasarımı daha verimli hale getirmek için iletişim protokolünü baştan ele aldık: Her istekte HTTP üzerinden yeni bir bağlantı kurup tüm konuşma geçmişini göndermek yerine, kalıcı bir bağlantı kurarak durumu önbelleğe alabilecek miydik? Fikir basitti: Yalnızca doğrulanması ve işlenmesi gereken yeni bilgileri göndermek, yeniden kullanılabilecek durumu ise bağlantı süresince bellekte tutmak. Böylece gereksiz tekrarların oluşturduğu ek yük azalacaktı.

WebSocket ve gRPC çift yönlü akış gibi farklı yaklaşımları değerlendirdik. Sonunda WebSocket'ı tercih ettik; çünkü basit bir mesajlaşma protokolü olarak kullanıcıların Responses API girdi/çıktı yapısını değiştirmesini gerektirmiyordu. Geliştirici dostuydu ve mevcut mimarimize büyük değişiklikler yapmadan uyum sağladı.

İlk WebSocket prototipi, Responses API gecikmesi konusunda mümkün olduğunu düşündüğümüz sınırları değiştirdi. API katmanında derin uzmanlığa sahip bir Codex mühendisi, bir Codex ajanını çalıştırarak bu prototipi bir gecede ortaya çıkardı.

Bu prototipte, ajan tabanlı kullanımlar, uzun süre çalışan tek bir Yanıt olarak modellenmişti. asyncio özellikleri sayesinde, model bir araç çağrısı seçtiğinde Responses API, yanıt üretim döngüsünde asenkron olarak beklemeye geçer; ardından işlem tamamlandığında istemciye response.done olayı gönderir. Araç çağrısı tamamlandığında istemciler, araç çıktısıyla birlikte response.append olayı gönderiyor; bu da örnekleme döngüsünü yeniden başlatıyor ve modelin devam etmesini sağlıyordu.

Bunu, yerel araç çağrısını barındırılan bir araç çağrısı gibi ele almak şeklinde düşünebilirsiniz. Model web araması yaptığında da benzer bir süreç işler: çıkarım döngüsü durur, web arama hizmetini çağırır ve dönen yanıtı model bağlamına ekler. Bu tasarımda benzer bir yaklaşım kullandık; ancak uzak bir hizmeti çağırmak yerine, modelin araç çağrısını WebSocket üzerinden doğrudan istemciye ilettik. İstemci yanıt verdiğinde, bu yanıtı bağlama ekleyip üretime kaldığımız yerden devam ettik.

Ajan çalışması boyunca tekrarlanan API işlemlerini ortadan kaldırdığı için bu yöntem oldukça etkili oldu. Ön işleme adımlarını bir kez gerçekleştirebildik, araç çalışırken süreci duraklatabildik ve ardından kalan işlemleri yine tek seferde tamamlayabildik.

Ancak bunun bir maliyeti vardı: API yapısı daha az tanıdık ve daha karmaşık hale geldi. Geliştiricilerin tüm entegrasyonu baştan yazmak zorunda kalmadan WebSocket desteği ekleyebilmesini istedik.

Yayınladığımız versiyonda, yeniden alışıldık yapıya döndük: aynı istek gövdesiyle response.create kullanılmaya devam ediyor ve previous_response_id ile önceki yanıtın bağlamı korunuyor.

WebSocket bağlantısında sunucu, önceki yanıt durumunu bağlantı süresince bellekte saklıyor. Bir sonraki istekte response.create içinde previous_response_id varsa, tüm konuşmayı baştan kurmak yerine bu durumu doğrudan önbellekten alıyoruz.

Önbelleğe alınan bu durum şunları içerir:

• Önceki response nesnesi
• Önceki girdi ve çıktı öğeleri
• Araç tanımları ve ad alanları
• Daha önce üretilmiş token'lar gibi yeniden kullanılabilir örnekleme yapıtları

Bellekte tutulan bu önceki yanıt durumunu yeniden kullanarak önemli performans artışları elde ettik:

• Güvenlik sınıflandırıcıları ve istek doğrulayıcılarının her seferinde tüm geçmişi değil, yalnızca yeni girdiyi işlemesini sağlıyoruz
• Üretilmiş token'ları bellekte tutup üzerine ekleyerek gereksiz tokenizasyon adımlarını atlıyoruz
• Başarılı model çözümleme/yönlendirme mantığını istekler arasında yeniden kullanıyoruz
• Faturalandırma gibi engelleyici olmayan çıkarım sonrası işlemleri, sonraki isteklerle eş zamanlı yürütüyoruz.

Hedefimiz, mümkün olan en düşük ek yükle çalışan prototipe yaklaşırken geliştiricilerin zaten aşina olduğu API yapısını korumaktı.

WebSocket modunu geliştirmek için iki aylık yoğun bir çalışmanın ardından, önde gelen kodlama ajanı startup'larıyla bir alfa sürüm başlattık; böylece bu modu kendi altyapılarına entegre edip trafiği güvenli şekilde kademeli olarak artırabildiler. Alfa kullanıcıları bu yaklaşımı benimsedi ve ajan tabanlı iş akışlarında %40'a varan iyileşmeler⁠(yeni bir pencerede açılır) bildirdi. Bu olumlu geri bildirimlerin ardından lansmana hazır hale geldik.

Sonuçlar hemen görüldü. Codex, Responses API trafiğinin büyük kısmını hızla WebSocket moduna taşıdı ve gecikmede önemli düşüşler sağladı. GPT‑5.3 Codex-Spark ile saniyede 1.000 token hedefimize ulaştık ve anlık olarak 4.000 TPS'ye kadar çıktık. Bu da Responses API'nin gerçek üretim trafiğinde çok daha yüksek çıkarım hızlarına ayak uydurabildiğini gösterdi. Bu etkinin geliştirici topluluğunda da hızla karşılık bulduğunu gördük:

• Codex, trafiğinin büyük kısmını kısa sürede WebSocket'lara taşıdı. GPT‑5.3‑Codex⁠(yeni bir pencerede açılır), GPT‑5.4⁠(yeni bir pencerede açılır) ve daha yeni modelleri kullanan tüm Codex kullanıcıları, WebSocket modunun hız avantajından yararlandı.
• Vercel, WebSocket modunu AI SDK'sına entegre etti ve gecikmede %40'a varan⁠(yeni bir pencerede açılır) azalma gördü.
• Cline'ın çok dosyalı iş akışları %39 daha hızlı⁠(yeni bir pencerede açılır) hale geldi.
• Cursor'daki OpenAI modelleri %30'a kadar hızlandı⁠(yeni bir pencerede açılır).

WebSocket modu, Mart 2025'teki lansmanından bu yana Responses API'ye eklenen en önemli yeteneklerden biri. OpenAI'ın API ve Codex ekipleri arasındaki yakın iş birliği sayesinde, fikir aşamasından canlı kullanıma geçişi yalnızca birkaç hafta içinde tamamladık. Bu yaklaşım, yalnızca ajan devreye alma gecikmesini ciddi biçimde azaltmakla kalmıyor; aynı zamanda geliştiricilerin ihtiyaç duyduğu daha geniş bir gereksinimi de karşılıyor: model çıkarımı hızlandıkça, çevresindeki hizmetlerin de bu kazanımı kullanıcıya yansıtacak hızda çalışması gerekiyor.