Çıktıyı Yinelemeden Streaming LLM Yanıtlarını Yeniden Deneme

Bir akış isteği, yalnızca üç durum aynı anda geçerli olduğunda yeniden oynatılmak için güvenlidir. İstemcinize hiçbir şey ulaşmamıştır. Gözlemlenebilir hiçbir şey ücretlendirilmemiştir. Ve istek sunucu tarafında hiçbir durum (state) taşımamaktadır. İlk çıktı olayından sonra yapılacak doğru hareket, isteği yeniden oynatmak yerine hatayı bildirmektir.

TokenLab, Responses API akışına yönelik ağ geçidinde, hem HTTP hem de WebSocket üzerinden bu kuralı uygular. WebSocket yolu, 2026-09-28 tarihinde HTTP ile eşleşecek şekilde değiştirilmiştir.

Bir akış neden normal bir istekten farklıdır?

Akış içermeyen bir çağrı bir gövde veya bir hata döndürür. Geri hiçbir şey almadığınız için hatayı yeniden deneyebilirsiniz.

Bir akış, istek tamamlanmadan önce size çıktı sunar. İlk çıktı olayı, geri dönüşü olmayan noktadır. Bağlantı bundan sonra koparsa, elinizde kısmi metin kalır. İsteği yeniden oynatmak, aynı yanıtı tekrar oluşturmak ve bunun için iki kez ödeme yapmak anlamına gelir. Ayrıca, temsilcinizin (agent) zaten çalıştırdığı bir araç çağrısını da çoğaltabilirsiniz.

TokenLab akış kılavuzu bunu doğrudan belirtir:

İlk olay ulaştıktan sonra, kesintiye uğrayan bir akış eksiktir ve otomatik olarak yeniden başlatılmaz.

Bu nedenle istemcinizin yerel bir duruma (state) ihtiyacı vardır: saw_output. Herhangi bir çıktı kodunuza ulaştığı anda bu değer true olur. Her yeniden deneme kararı önce bu biti okur.

response.completed olmadan sona eren bir akış başarısızdır. Elinizdeki metnin tam olduğunu varsaymayın. response.failed, response.incomplete ve error olaylarını yönetin.

Madde madde yeniden oynatma kararı

TokenLab, tüm bunlar geçerli olduğunda bir isteği mevcut başka bir rota üzerinde bir kez yeniden oynatır. İstek durumsuzdur (stateless). İstemciye hiçbir şey ulaşmamıştır. Başarısız olan deneme için hiçbir sonuç veya kullanım gözlemlenmemiştir. Ve hata, ya yeniden denenebilir bir çıktı öncesi olaydır ya da ilk olaydan önce gerçekleşen bir upstream okuma hatasıdır. İstek başına en fazla bir yeniden oynatma gerçekleşir. Eğer yedek istek de çıktıdan önce başarısız olursa, bu hata tekrar yeniden oynatılmaz.

Kaynak: TokenLab akış kılavuzu ve ağ geçidi davranışı, 2026-09-28 tarihinde gözlemlenmiştir.

Hata noktası	TokenLab tarafından yeniden oynatılır mı?	Neden
Yeniden denenebilir çıktı öncesi olay (response.failed veya aşırı yüklenme ya da dahili upstream hatası gibi yeniden denenebilir olarak işaretlenmiş bir error olayı)	Evet, bir kez, eğer istek durumsuzsa	İstemciye hiçbir şey ulaşmadı ve kullanım gözlemlenmedi, bu nedenle ikinci bir yürütme görünmezdir.
İlk olaydan önce upstream akış kopması (okuma hatası)	Evet, bir kez, eğer istek durumsuzsa	Aynı pencere. İstemci hiçbir çıktı tutmaz ve ücretlendirilmez.
Çıktıdan önce ikinci hata, bir yeniden oynatmadan sonra	Hayır	Bütçe, istek başına bir yeniden oynatmadır.
İstemciye çıktı ulaştıktan sonra herhangi bir hata	Hayır	İstemci zaten kısmi metni tutuyor. Bir yeniden oynatma, çıktıyı ve maliyeti çoğaltır.
Depolanmış yanıt (store), devam ettirme (previous_response_id) veya kaynağa bağlı istek	Hayır	İkinci bir yürütme, ikinci bir depolanmış yanıt oluşturabilir veya konuşma durumunu saptırabilir.
İlk olay zaman aşımı	Hayır	Upstream hala üretim yapıyor olabilir. Bir yeniden oynatma, ilk deneme devam ederken aynı işi iki kez çalıştırabilir.
Çıktı öncesi arabellek (buffer) taşması	Hayır	Sınır ağ geçidine özeldir. Aynı büyük ön ek, bir sonraki rotada da muhtemelen aynı sınıra takılacaktır.
İstemci bağlantısı koptu	Hayır	İstemci dinlemeyi bıraktı.
Belirleyici hata, örneğin geçersiz bir istek	Hayır	Yeniden denemek sonucu değiştiremez. Değiştirilmeden iletilir.
Zaten kullanım (usage) içeren hata	Hayır	Deneme ücretlendirildi. Değiştirilmeden iletilir.
Başka rota kalmadı	Hayır	Gönderilecek yer yok. İstemci hatayı kendi koduyla alır.

Bir hata yeniden oynatılmadığında veya başka rota kalmadığında, hatayı kendi hata koduyla alırsınız. Genel örnekler: upstream akışı koptuğunda stream_read_error ve arabellek taşmasında upstream_stream_buffer_limit. Eğer rota seçimi bir yeniden oynatma kararından sonra başarısız olursa, WebSocket turu websocket_response_failed (durum 500) ile sona erer ve ayrılan ücret iade edilir.

Faturalandırma aynı çizgiyi izler. Yalnızca iletilen deneme için ödeme yaparsınız. Yeniden oynatılan bir istek upstream tarafında iki kez yürütülmüş olabilir ve bu ekstra upstream maliyeti TokenLab'e aittir, çünkü ilk denemeden size hiçbir şey ulaşmamıştır. Hiçbir şey iletmeyen başarısız bir tur ücreti iade edilir.

Hata yönetiminiz için bir zamanlama detayı önemlidir. Çıktı başlamadan önce ağ geçidi, ilk çıktı olayı veya bir hata gelene kadar en fazla 10 saniye boyunca response.created ve response.in_progress olaylarını tutar. Bu tutulan olaylar daha sonra ilk çıktı ile veya terminal olayı ile birlikte size ulaşır. Sıralama ve içerik değişmez. Bunları sadece biraz daha geç görürsünüz. Bu 10 saniye tipik bir gecikme değil, maksimum süredir.

WebSocket için 2026-09-28 tarihinde ne değişti?

TokenLab, Responses API'yi HTTP akışı ("stream": true, server-sent events) üzerinden ve istemcinin response.create olaylarını gönderdiği wss://api.tokenlab.sh/v1/responses adresindeki WebSocket üzerinden sunar. WebSocket yanıtları her zaman akış halindedir. background veya response.cancel desteklemezler. Her bağlantı, 60 dakikaya kadar bir seferde bir aktif yanıtı yönetir.

Değişiklikten önce, iki yol birbirinden farklıydı. HTTP yaşam döngüsü olaylarını tutuyor ve durumsuz çıktı öncesi hataları yeniden oynatıyordu. WebSocket ise response.created olayını hemen iletiyor ve çıktı öncesi hataları istemciye göndererek ücreti iade ediyordu. Aynı upstream aksaklığı, HTTP'de temiz bir yanıt üretirken WebSocket'te hata üretiyordu.

WebSocket yolu artık, herhangi bir olay gelmeden önce kopan bir akışın yeniden oynatılması da dahil olmak üzere HTTP kuralını izlemektedir. Dahili olarak, WebSocket turlarında görülen çoğu upstream hatası herhangi bir çıktıdan önce gerçekleşmiştir. Bu, yeniden oynatmanın güvenli olduğu penceredir.

Ağ geçidi, çıktı öncesi hata durumunu iyileştirir. Bir akışın tamamlanacağını garanti etmez.

Değişiklik diğer davranışları bozmadan nasıl yayınlandı?

Çalışma, sessiz davranış değişikliklerini yakalamak için oluşturulmuş bir süreci izledi.

• Davranış kilidi. Değişiklikten önce, her WebSocket turu senaryosu bir fikstür olarak kaydedildi: istemcinin aldığı çerçeveler, yapılan upstream çağrıları ve faturalandırma sonucu. Bu çalışma sırasında paket 63 kayıtlı senaryoya ulaştı. Bir davranış değişikliği önceden beyan edilmelidir. Sadece bu beyanda adı geçen fikstürler değişebilir. Diğer tüm fikstürler bayt bazında aynı kalmalıdır.
• Mutasyon kontrolleri. Her yeni karar kuralı, ilk olay zaman aşımını yeniden oynatmak veya okuyucu hatasını yeniden oynatmamak gibi kasten değiştirilerek ve kilidin başarısız olduğu doğrulanarak test edildi.
• İnceleme yakalaması. İlk sürüm, HTTP ile uyumluluk iddiasıyla arabellek taşması durumunu da yeniden oynatılabilir hale getirdi. İnceleme, tablodaki nedenden dolayı HTTP'nin bu durumu asla yeniden oynatmadığını gösterdi. Bir takip çalışması eski davranışı geri yükledi ve sınır senaryoları ekledi: ikinci bir okuyucu hatası yeniden oynatılmaz, rota kalmadı, tutulan bir response.created sonrası hata ve ardından kopan bir yedek akış.

Yeniden oynatmadan sonra başarılı olan bir turun istek günlükleri, HTTP'nin zaten yaptığı gibi, daha önce başarısız olan denemeyi de kaydeder.

Yeniden deneme kararına sahip olan istemci kodu

Akış çağrıları için SDK otomatik yeniden denemelerini 0 olarak ayarlayın. Bu, kararı kendi kodunuzda tutar. Yeniden oynatma kararını işleyicilere yaymak yerine tek bir yerde tutun. HTTP hataları için hata yönetimi kılavuzunda açıklandığı gibi retryable ve retry_after değerlerine uyun ve istek kimliklerini (request IDs) koruyun.

HTTP üzerinden SSE

import os

from openai import OpenAI

with OpenAI(
    api_key=os.environ["TOKENLAB_API_KEY"],
    base_url="https://api.tokenlab.sh/v1",
    timeout=30.0,
    max_retries=0,  # yarıda kesilmiş bir akışı yeniden göndermek yerine yeniden deneme kararını kendiniz verin
) as client:
    completed, saw_output = False, False
    with client.responses.create(
        model="gpt-5.6-terra",
        input="Yeniden denemeler hakkında kısa bir cümle ile yanıt verin.",
        stream=True,
    ) as stream:
        for event in stream:
            if event.type == "response.output_text.delta":
                saw_output = True
                print(event.delta, end="", flush=True)
            elif event.type == "response.completed":
                completed = True
            elif event.type in {"response.failed", "response.incomplete", "error"}:
                raise RuntimeError(f"{event.type} after_output={saw_output}")
    if not completed:
        raise RuntimeError(f"akış response.completed olmadan kapandı, after_output={saw_output}")
    print()

Örnek, max_retries=0 ile https://api.tokenlab.sh/v1 adresine karşı OpenAI SDK 2.15.0 kullanır. saw_output değerini izler ve response.failed, response.incomplete, error olaylarında ve response.completed öncesinde kapanan bir akışta hata fırlatır. 2026-09-28 tarihinde gpt-5.6-terra ile üretim ortamında doğrulanmıştır.

Eğer hata saw_output == false ile gelirse ve istek uygunsa (durumsuz, yeniden oynatılabilir bir hata ile), TokenLab onu zaten bir kez yeniden oynatmıştır; depolanmış yanıtlar, devam ettirmeler ve ilk olay zaman aşımları hiç yeniden oynatılmamıştır. Uygulama düzeyinde yeni bir isteğin kabul edilebilir olup olmadığına karar verin, çünkü yeni bir istek yeni bir üretimdir. Eğer saw_output == true ise, hatayı bildirin ve elinizdekini gösterin veya kısmi metni kasten atın.

WebSocket

import asyncio
import json
import os

import websockets

URL = "wss://api.tokenlab.sh/v1/responses"
TERMINAL = {"response.completed", "response.failed", "response.incomplete", "error"}


async def run_turn(prompt: str) -> str:
    headers = {"Authorization": f"Bearer {os.environ['TOKENLAB_API_KEY']}"}
    async with websockets.connect(URL, additional_headers=headers, max_size=None) as ws:
        await ws.send(json.dumps({
            "type": "response.create",
            "model": "gpt-5.6-terra",
            "input": prompt,
            "store": False,
        }))
        text, saw_output = [], False
        async for raw in ws:
            event = json.loads(raw)
            kind = event.get("type")
            if kind == "response.output_text.delta":
                saw_output = True
                text.append(event["delta"])
            elif kind in TERMINAL:
                if kind != "response.completed":
                    # Çıktı başladıktan sonra bir hata bu tur için nihaidir.
                    # Yalnızca uygulamanız kısmi metni atabiliyorsa yeniden gönderin.
                    raise RuntimeError(f"{kind} after_output={saw_output}: {json.dumps(event)[:300]}")
                return "".join(text)
        raise RuntimeError(f"soket terminal olayı olmadan kapandı, after_output={saw_output}")


print(asyncio.run(run_turn("Yeniden denemeler hakkında kısa bir cümle ile yanıt verin.")))

Örnek, websockets 16.0 kullanır, Bearer başlığı ile wss://api.tokenlab.sh/v1/responses adresine bağlanır, store: false ile bir response.create gönderir ve response.output_text.delta olaylarını toplar. Tamamlanmayan herhangi bir terminal olayında veya erken kapanmada after_output ile hata fırlatır. 2026-09-28 tarihinde gpt-5.6-terra ile üretim ortamında doğrulanmıştır.

after_output bayrağı, saw_output ile aynı fikirdedir. Çağıran kodunuza, yan etkileri çoğaltmadan yeni bir tur başlatmanın mümkün olup olmadığını söyler.

Kendi yeniden deneme mantığınız için kontrol listesi

• response.completed olmadan sona eren bir akışı her zaman hata olarak değerlendirin.
• Çıktının kodunuza ulaşıp ulaşmadığını takip etmek için bir boolean kullanın. Bunu ilk yaşam döngüsü olayında değil, ilk çıktı olayında true yapın.
• Uygun bir istekteki çıktı öncesi hatanın zaten ağ geçidi tarafından bir kez yeniden oynatıldığını unutmayın; daha fazla deneme sizin kararınızdır.
• Kısmi çıktıdan sonra, yalnızca uygulamanız kısmi metni atabiliyorsa ve iki üretim için ödeme yapmayı kabul ediyorsa yeniden gönderin.
• Temsilci döngülerinde, kısmi akışın kodunuzun üzerinde işlem yaptığı bir araç çağrısı içerip içermediğini kontrol edin. Yan etkilerini geri alamayacağınız bir turu yeniden oynatmayın.
• Depolanmış yanıtlar ve previous_response_id devam ettirmeleri için, herhangi bir şeyi yeniden göndermeden önce hangi durumun mevcut olduğunu inceleyin.
• SDK'nızda akış yeniden denemelerini 0 olarak ayarlayın ve yeniden oynatma kararını tek bir fonksiyonda tutun.
• İletilen bir yanıtı arkasındaki denemelerle eşleştirebilmek için istek kimliklerini (request IDs) kaydedin.

SSS

TokenLab, kısmi çıktıdan sonra bir akışı yeniden başlatır mı?

Hayır. Çıktı istemcinize ulaştıktan sonra, bir hata bildirilir ve asla yeniden oynatılmaz. Elinizde kısmi metin olduğu için, yeniden başlatma çıktıyı ve maliyeti çoğaltır. Uygulamanız elindekini gösterip göstermeyeceğine, kısaltacağına veya atacağına karar verir.

Ağ geçidi isteğimi yeniden oynatırsa iki kez ücretlendirilir miyim?

Hayır. Yalnızca iletilen deneme için ödeme yaparsınız. Yeniden oynatılan bir istek upstream tarafında iki kez yürütülmüş olabilir, ancak ilk denemeden size hiçbir şey ulaşmamıştır ve bu ekstra upstream maliyeti TokenLab'e aittir. Hiçbir şey iletmeyen başarısız bir tur ücreti iade edilir.

Neden ilk olay zaman aşımı yeniden denenmiyor?

Çünkü upstream hala üretim yapıyor olabilir. Bir yeniden oynatma, ilk deneme devam ederken aynı işi iki kez çalıştırabilir. İlk olay zaman aşımı, akışı ilk olaydan önce kıran bir okuma hatasından farklı değerlendirilir.

Depolanmış bir yanıtı veya previous_response_id devam ettirmesini yeniden deneyebilir miyim?

Otomatik olarak hayır. TokenLab, depolanmış yanıtları, devam ettirmeleri veya kaynağa bağlı istekleri asla yeniden oynatmaz, çünkü ikinci bir yürütme ikinci bir depolanmış yanıt oluşturabilir veya konuşma durumunu saptırabilir. Herhangi bir şeyi yeniden göndermeden önce hangi durumun mevcut olduğunu kontrol edin ve yalnızca uygulamanız bu durumu uzlaştırabiliyorsa yeniden gönderin.

Ham olay akışını kendiniz izlemek isterseniz, bir API anahtarı oluşturun ve istemcinizin aldığı her olay türünü kaydedin. Akış kılavuzu ve hata yönetimi kılavuzu tüm olay kümesini kapsar. Ağ geçidinin nasıl yönlendirme yaptığı ve kurtarma sağladığına dair arka plan bilgisi için TokenLab AI API güvenilirlik altyapısı ve Temsilciler için Responses API vs Chat Completions yazılarına göz atın.