Öğle yemeğinden önce üç çalıştırma başlatıyorsunuz. Doksan saniye sonra, üç terminalden ikisi hiçbir şey yazdırmamış. Biri depoda akıl yürütüyor. Biri çıkışta 504 aldı ve bir daha geri dönmeyecek. Oturduğunuz yerden bakınca ikisi de içinde bir imleç duran aynı kaydırma penceresi.
Bu yeni bir sorun değil, ancak 2026-09-22 tarihli lansmanlar işi belirli ve ölçülebilir bir biçimde daha da kötüleştirdi. Yeni modellerdeki en yüksek akıl yürütme ayarları, doğruluğu herhangi bir şey söylemeden önce uzun süre düşünerek satın alıyor. Artificial Analysis, GPT-6 Sol'un "max" akıl yürütme varyantını ilk token için 102,15 saniye, GPT-6 Luna'yı ise 124,23 saniye olarak ölçtü. Bunlar belirli bir yapılandırma üzerinde üçüncü taraf ölçümleri, satıcı rakamları değil ve bu uyarı önemli; ama yön konusunda şüphe yok: bir çalıştırmanın başındaki sessizlik artık bir hatadan ayırt edilemeyecek kadar uzun.
TL;DR
İlk token süresi, bir isteğin gönderilmesi ile yanıtın ilk karakterinin gelmesi arasındaki gecikmedir ve yüksek eforlu bir akıl yürütme modelinde düşünmenin büyük kısmı tam da bu gecikmede gerçekleşir. Bir terminal size düşünen bir çalıştırma, insan bekleyen bir çalıştırma ve iki dakika önce ölmüş bir çalıştırma arasındaki farkı söyleyemez, çünkü üçü de hiçbir şey yazdırmaz. Bir durum bilgisi söyleyebilir. Ajanlar araştırır, yürütür, test eder ve raporlar. İnsanlar yön belirler, yetki verir ve sonucu kabul eder. Bu sözleşmenin işlemesi için gereken şey, başında birinin beklemesine gerek kalmadan görülebilen bir çalıştırma durumudur: Sharkly bağlamı, ilerlemeyi, engelleri, sonuçları ve insan incelemesini istekten yayına kadar Görev üzerinde tutar; böylece uzun bir düşünme ile ölmüş bir çalıştırma birbirine benzemeyi bırakır.
Bekleme uzadı ve ucuz model hızlı olan değil
Üçüncü taraf ölçümlerin, maksimum akıl yürütme ayarındaki iki yeni GPT-6 modeli hakkında söyledikleri şöyle.
| Model | API kimliği | Çıktı hızı | İlk token süresi | 1M token başına giriş / çıktı |
|---|---|---|---|---|
| GPT-6 Sol (max) | gpt-6-sol |
115,2 token/s | 102,15 sn | $2 / $10 |
| GPT-6 Luna (max) | gpt-6-luna |
153,9 token/s | 124,23 sn | $0,10 / $0,50 |
Son iki sütunu birlikte okuyun. Luna, token başına Sol'un yirmide biri kadar maliyetli ve konuşmaya başlamadan önce sizi daha uzun bekletiyor. Maliyet ve gecikme ayrı eksenlerdir ve ucuz bir modelin daha çevik bir model olduğu sezgisi burada düpedüz yanlış.
Kimse bu rakamların üzerine bir gösterge paneli kurmadan önce iki dürüst çekince. Birincisi, bu rakamlar OpenAI'den değil Artificial Analysis'ten geliyor ve özellikle "max" akıl yürütme varyantlarını tanımlıyor. Daha düşük efor ayarları bambaşka bir hayvan ve sizin kendi rakamlarınız prompt boyutuna, araç kullanılabilirliğine ve trafiğinizin nereye düştüğüne göre değişecek. İkincisi, ilk token süresi çıktı hızıyla aynı ölçüm değil. Anthropic, Claude Opus 5.5'in çıktıyı Opus 5'ten yaklaşık %30 daha hızlı ürettiğini söylüyor; bu, ilk token'dan sonraki token'lar hakkında bir ifade. Bir model hızlı akış sağlayabilir ve yine de bir buçuk dakika boyunca boşluğa bakmanıza neden olabilir.
Sessiz bir terminal durum bilgisi değildir
Bir terminaldeki sessizliğin en az dört nedeni vardır ve terminal hepsini aynı şekilde gösterir:
- Runtime çalışıyor. Akıl yürütme sürüyor, henüz çıktı yok.
- Çalıştırma bir süre önce bitti ve bir insanın bir soruyu yanıtlamasını bekliyor.
- İstek başarısız oldu. Sharkly dokümanları bunun ne kadar kolay yanlış okunabileceği konusunda açık sözlü: "Timeout / 408 / 504, isteğin yavaş olduğu, iptal edildiği veya bir ağ geçidi tarafından geciktirildiği anlamına gelir. Bu, Computer'ın çevrimdışı olmasıyla aynı şey değildir."
- Computer gerçekten gitmiştir ya da çalıştırmanın ihtiyaç duyduğu dizin hiç boşalmamıştır.
Tek ajan, tek terminal: bunu bir dakika daha bekleyerek çözersiniz. Üç depoya ve iki Computer'a yayılmış beş ajan: bunu pencereler arasında sekme değiştirip tahmin yürüterek çözersiniz. Ajan kaosunun olağan biçimi budur: dramatik bir başarısızlık değil, sadece bir ekibin dikkatini saatte birkaç kez "bu hâlâ yaşıyor mu?" sorusuna harcaması.
İnsanların başvurduğu refleks, onu öldürüp yeniden çalıştırmaktır. Yüksek akıl yürütme eforunda bu refleks iki kat pahalıdır. İlk token beklemesinin tamamını yeniden ödersiniz ve gelmek üzere olan düşünmeyi çöpe atarsınız.
Bir durum bilgisinin ayırması gerekenler
Sharkly'nin kendi modeli, Sharkly kullanın ya da kullanmayın, kopyalanmaya değer; çünkü bir terminalin birleştirdiği iki şeyi ayırıyor. Çalıştırma durumunu, logları ve hata sinyallerini okunur kılan da aynı ayrım. Bir çalıştırmanın bir yürütme durumu vardır: Kuyrukta, Gönderildi, Yerel dizin bekleniyor, Çalışıyor, Tamamlandı, Başarısız veya İptal edildi. Bir Görevin bir yaşam döngüsü durumu vardır ve bir Ajanın bunun üzerine bir çalışma durumu eklenir: Çalışıyor, İnsan yanıtı bekleniyor, İnsan incelemesi bekleniyor veya Hata. Dokümanlar bu sınırı net biçimde belirtiyor: bu çalıştırma durumları "Görevin aynı iş akışı durumuna sahip olduğunu otomatik olarak ima etmez."
Bu ayrım, takıldı mı yoksa düşünüyor mu sorusunun tüm yanıtıdır.
| Terminalin gösterdiği | Gerçekte ne olabilir | İkisini ne ayırt eder | Sırada kim harekete geçer |
|---|---|---|---|
| Hiçbir şey, 100. saniyede | Çalışıyor, ilk token öncesi | Çalıştırma durumu Çalışıyor, logda bir gönderim zaman damgası var | Kimse. Bırakın. |
| Hiçbir şey, 10. dakikada | İnsan yanıtı bekleniyor | Çalışma durumu değişti, Görev Inbox'ta bir dikkat öğesi oluşturuyor | Atanan kişi bağlam içinde yanıtlar |
| Hiçbir şey, sonsuza kadar | Başarısız | Çalıştırma durumu Başarısız, yürütme logu başlığı ve orijinal model-servis yanıtını taşıyor | Atanan kişi yeniden denemeden önce logu okur |
| Hiçbir şey, hiç başlamadı | Kuyrukta veya Yerel dizin bekleniyor | Çalıştırma durumu, artı hangi dizin havuzunun meşgul olduğu | Bir dizin boşaltın veya paralel kapasiteyi artırın |
Bu dört satırın hiçbiri, değiştiği anda birinin izliyor olmasını gerektirmiyor. Mesele de bu. Durum kaydediliyor ve "düşünüyor mu yoksa takıldı mı?" sorusu, başında oturup beklediğiniz bir şey değil, bakıp öğrendiğiniz bir şey hâline geliyor.
Mart ayında ayarladığınız görev başına zaman aşımı
Sharkly'de bir Ajan, maksimum paralel çalışan Görev sayısını ve görev başına bir zaman aşımını taşır. Çoğu ekip bu zaman aşımını bir kez, başlarda, bir terminale ne kadar bakmaya razı olduklarına göre ayarlar. Bu sayı iki dakikaysa ve o zamandan beri bir Ajanı max akıl yürütme ayarına taşıdıysanız, düşünme aşamasında çalıştırmaları iptal eden ve onları başarısız olarak bildiren bir politika yapılandırmışsınız demektir.
Bu hafta gidip kendinizinkine bakın. Alt sınır "ne kadar beklemeye razıyım" değil, "bu Runtime gerçekte kullandığım efor seviyesinde ne kadar sürüyor, artı işin kendisi" olmalı. Sadece ilk token'ı yüz saniyeden fazla sürebilen bir çalıştırma için beş dakikanın altındaki bir zaman aşımı, politika kılığına girmiş bir yazı tura atmadır.
Aynı gözden geçirmeyi hak eden iki ilgili ayar daha var. Maksimum paralel çalışan Görev sayısı gerçek eşzamanlılık sınırınızdır ve yapılandırılmış her dizin meşgul olduğunda yeni çalıştırmalar başarısız olmak yerine Yerel dizin bekleniyor durumunda oturur; bu doğru bir davranıştır ama yalnızca terminali izliyorsanız donma gibi görünür.
Önbellekleme bunu çözer mi?
Kısmen ve istediğiniz kısmı değil. OpenAI'nin GPT-6 için prompt önbelleklemesi, önbelleğe alınmış girdi okumalarında %90 indirim sağlıyor, varsayılan olarak daha yüksek isabet oranları sunuyor, önbelleğe alınmış bir önekin nerede biteceğini seçebilmeniz için açık kesme noktaları ekliyor ve akıl yürütme eforunu ya da araç kullanılabilirliğini değiştirdiğinizde artık önbelleği bozmuyor. GitHub, milyarlarca istek genelinde taze işleme ihtiyaç duyan prompt token'larında %50'den fazla azalma bildiriyor. Bu, prompt üzerinde gerçek bir maliyet ve gecikme kazancı ve efor değişikliği düzeltmesi, bir görevi akış ortasında ucuz bir ayardan pahalı bir ayara yükselten ajanlar için gerçekten faydalı.
Ancak akıl yürütme geçişini ortadan kaldırmıyor. Sıcak bir önbellek, promptunuzun daha azının sıfırdan işlendiği anlamına gelir. Modelin hatanız hakkında çoktan düşündüğü anlamına gelmez. Yine de bekleme için pay ayırın.
Beklemeye ne zaman katlanmalı, ne zaman katlanmamalı
Görev iki kez çalıştırmak istemeyeceğiniz türdense maksimum akıl yürütme ayarını kullanın: bir migrasyon, kesişen bir refaktör, yanlış bir yanıtın doksan saniyeden pahalıya mal olduğu her şey. OpenAI, Sol'un xhigh ayarında AutomationBench 1.0.6'da görev başına 0,27 dolara %33,2 puan aldığını bildiriyor; ödünleşimin şekli bu. Doğruluk artık para açısından ucuz, duvar saati açısından pahalı.
Bir kişi orada oturmuş yanıtı bekliyorsa daha düşük bir efor ayarı kullanın. Etkileşimli işler, bir dosyayla ilgili hızlı bir soru, küçük kapsamlı bir düzeltme: düşük eforda sessizlik sorunu büyük ölçüde kaybolur, çünkü ilk token siz ne sorduğunuzu hâlâ hatırlarken ortaya çıkar.
Ve dürüst sınır: tek bir Görev üzerinde tek bir ajan çalıştırıyorsanız bunun için bir panoya ihtiyacınız yok. Logu takip edin. Durum sorunu, çalıştırma sayısının anlamlı biçimde izleyebileceğiniz terminal sayısını aştığı noktada başlar; çoğu insan için bu yaklaşık üçtür.
Bunun çözmediği şey
Bir durum bilgisi size bir çalıştırmanın Çalışıyor olduğunu söyler. Çalıştırmanın faydalı bir şey yaptığını söylemez ve kendinden emin biçimde yanılan bir ajan, çalıştırma sürdüğü sürece iyi bir ajanla aynı yeşil durumu gösterir; Opus 5.5'te bu 18 saat veya daha fazla olabilir. "Çalışıyor" ile "iyi çalışıyor"u ayırt etmek hâlâ bir inceleme sorunu ve inceleme hâlâ bir insanın işi. Otomasyon, ekip muhakemesinin gerektiği yerde durur.
Zaten aynı anda birkaç ajan çalıştırıyorsanız, bu hafta yapabileceğiniz en küçük faydalı değişiklik yeni bir model değil. Her çalıştırmanın durumunu terminal açmadan okunur kılmaktır; böylece sonraki doksan saniyelik sessizlik bir soru değil, bir bilgi olur.
