Kodlama ve AI Uygulamaları İçin Tek Bir Konsol: Neler Değişti ve Nasıl Kullanılır

Kodlama asistanı modu ve yapay zeka uygulama modu tek bir çalışma yüzeyinde birleştiğinden, TokenLab Console bizim için artık sadece bir kontrol paneli olmaktan çıktı. İş akışımızda; istek, yanıt ve bunların etrafındaki hesap durumu artık bir arada bulunuyor. Bu, her oturumda bağlam değiştirme ihtiyacını ortadan kaldırıyor ve yavaş bir yanıtı nasıl okuduğumuzu değiştiriyor.

Öne Çıkanlar

• Kodlama asistanı modu ve yapay zeka uygulama modu artık TokenLab Console içinde bir arada; eski iki giriş noktası burada birleştirildi.
• Mevcut bağlantılar hala çalışıyor ve önceki konuşmalar yerli yerinde duruyor. Manuel olarak taşımanız gereken hiçbir şey yok.
• Yanıtlar, model tarafından oluşturuldukça akış halinde gelir; sadece sonunda görünmez. Arayüz, ilk token süresini gösterir.
• İlk token gecikmesi (first-token latency), sadece arayüzde bir süsleme değil, kaydedilmiş bir istek sinyalidir (istek günlüğünde ttft_ms olarak görünür).
• Konuşma sırasında bakiye azaldığında, bakiye yükleme girişi ayrı bir faturalandırma sayfası yerine konuşmanın hemen yanında yer alır.
• Konsolun model seçimi genel kataloğu takip eder; güncel seçenekler için model dizinine göz atın. Mevcut katalog örnekleri arasında Claude Sonnet 5 ve DeepSeek V4 Pro bulunmaktadır.

TokenLab Console'da neler değişti, neler değişmedi?

Bu değişiklik iki ayrı sürüm notu girişiyle yayınlandı. Konsol birleşimi (2026-08-04), eski iki giriş noktasını tek bir Konsol altında topladı. Konsol sohbet akışı (2026-08-18) ise sohbetlere akış özelliğini ekledi. Bu iki değişiklik arasında bir ay olduğu için, ilk girişi kaçıran ekipler ikincisinden yine de yararlanabiliyor.

Bu, davranışsal değil, arayüzsel bir değişikliktir. Model çağrıları, anahtarlar ve faturalandırma değişmemiştir. Eski bağlantılar çalışmaya devam eder ve mevcut konuşmalar birleştirme boyunca korunmuştur. Manuel bir taşıma adımı yoktur.

Birleştirme adımı giriş noktalarıyla ilgilidir, model erişimiyle değil. Akış adımı ise bir yanıtın nasıl göründüğüyle ilgilidir, hangi tokenların faturalandırıldığıyla değil. Bu önemlidir çünkü bir ürün arayüzü değişikliği, davranışsal bir değişikliği gizleyebilir; ancak bu durumda böyle bir şey yaşanmadı. Kodlama asistanı modu ve yapay zeka uygulama modu artık tek bir yeri paylaştığı için, bir oturumdaki ilk karar artık hangi giriş noktasının açılacağı ile ilgili değil.

Ekibinizin eski giriş noktalarına işaret eden çalışma kitapları (runbook) varsa, bunları uygun olduğunda güncelleyin. Eski bağlantılar hala çalıştığı için çalışma kitabı bozulmayacaktır. Konsol, yeni çalışmalar için yer imlerine eklemeniz gereken yerdir. Her iki modda da bir model seçtiğinizde, seçim genel kataloğu takip eder, bu yüzden model dizinini kontrol edin. Mevcut katalog örnekleri arasında Claude Sonnet 5 ve DeepSeek V4 Pro bulunmaktadır.

TokenLab Console'da akış (streaming), bir oturumu okuma şeklinizi değiştirir

Akış, bir şeylerin gerçekleştiğini bildiğiniz anı değiştirir. İş akışımızda, Konsol ağ geçidi istemcisi akışlı sohbet istekleri oluşturur ve yanıt artımlı olarak işlenir. Arayüz, ilk token süresini gösterir, böylece modelin ne zaman yanıt vermeye başladığını görebilirsiniz. Konsol ayrıca bu sinyali, istek günlüğünde isteğe bağlı bir sütun olan ttft_ms olarak kaydeder.

İlk token süresi, ilk tokenın ne zaman ulaştığını söylerken, toplam gecikme tüm yanıtın ne zaman bittiğini söyler. Bunlar farklı sorulardır, bu yüzden bir yanıt yavaş hissettirdiğinde önce ttft_ms değerini kontrol edin. İlk token geç geliyorsa, bekleme süresi oluşturma öncesindedir. İlk token erken geliyor ancak yanıt uzuyorsa, bekleme süresi akışın geri kalanındadır.

Yavaş bir oturumu izlerken, yükleme simgesinden tahmin yürütmek yerine ttft_ms değerini diğer istek kanıtlarıyla karşılaştırırız. İstek düzeyindeki kanıtlar organizasyonla sınırlıdır ve yönlendirme, faturalandırma durumu, önbellek durumu ile bir isteğin arkasındaki model ve anahtar bağlamını kapsar. Konsol, günlüklerden çıkarabileceğiniz aynı istek kaydını sunar.

İlk token sinyalini okumaya dair bir örnek:

# Konsol istek günlüğü, `ttft_ms` değerini isteğe bağlı bir sütun olarak sunar.
# 1. İstek günlüğünü kontrol ettiğiniz isteğe göre filtreleyin.
# 2. `ttft_ms` değerini okuyun.
# 3. `ttft_ms` değerini aynı satırdaki isteğin toplam gecikmesiyle karşılaştırın.

Tam akış isteği yapısı için güncel TokenLab API dokümanlarını kullanın. Uydurma alanlara sahip kopyalanmış bir istek örneği, bu isimlerin sahibi olan doküman sayfasından daha az yararlı olacaktır.

Akış, ne için faturalandırıldığınızı değiştirmez, çünkü aynı tokenlar üretilir ancak geldikçe görünür hale gelirler. Yanıtlar artık aktığı için, kesintiye uğrayan bir oturum hiçbir şey göstermek yerine kısmi yanıtı gösterir. Bu, oturum ortası bir hatayı teşhis etme şeklinizi değiştirir. Bir sohbet akışının kapsamadığı uzun süreli işler için asenkron görüntü oluşturma görevleri kılavuzuna bakın.

Tahmin yürütmeden yavaş bir oturumu nasıl doğrularsınız?

Yükleme simgesiyle değil, istek günlüğüyle başlayın; çünkü ttft_ms sütunu size ilk tokenın ne zaman ulaştığını söyler. Eğer bu sayı yüksekse, model henüz yanıt vermeye başlamamıştır. Eğer bu sayı düşükse, model erken başlamış ve geri kalan akış zaman almıştır. Bu ayrım, yolun yanlış kısmını suçlamanızı engeller.

İstek kaydı organizasyonunuzla sınırlıdır. İsteği sunan rotayı, faturalandırma durumunu, önbellek durumunu ve model ile anahtar bağlamını içerir. Bu alanlar bir arada bulunur, böylece oturumu ayrı sayfaları birleştirmek yerine tek bir olay olarak okuyabilirsiniz. Aynı istek kaydı, Konsol görünümünü hesap düzeyindeki verilerle karşılaştırırken yardımcı olan kontrol panelinde de mevcuttur. Request Console kılavuzu, bu kanıtların nerede bulunduğunu açıklar.

Örneğin, ilk token erken geliyorsa ve yanıt uzuyorsa, ttft_ms ana sinyal değildir, çünkü akışın geri kalanı asıl sorundur. Aynı istek kaydındaki rota ve önbellek durumuna bakabilirsiniz. İsteğin bir önbelleğe mi çarptığını yoksa modele mi gittiğini kontrol edebilirsiniz. Hangi anahtarın ve model bağlamının eklendiğini görebilirsiniz.

Bunların hiçbiri tek başına tüm hikayeyi anlatmaz, ancak birlikte size bakacak bir yer sunar. Yavaş bir oturumu izlediğimizde, istek günlüğü ihtiyacımız olan detaylara sahiptir. Bir sonuca varmadan önce ttft_ms değerini diğer istek düzeyi kanıtlarıyla karşılaştırırız.

Aynı iş akışı, bir istek başarısız olduğunda veya bakiye nedeniyle durakladığında da yardımcı olur. İstek kaydı faturalandırma durumunu içerir, bu yüzden hata bir gizem değildir. Bakiye yükleme girişi konuşmanın yanındadır, bu yüzden düzeltme aynı pencerede kalır. Bir sonraki adımı bulmak için oturumdan ayrılmanıza gerek yoktur, böylece bakiye yükleyip devam edebilirsiniz.

Bakiye uygunsa, yönlendirme, önbellek durumu veya model seçimine geçebilirsiniz. Önemli olan, istek düzeyi kanıtlarını sırayla okumaktır. Önce ilk tokenın ne zaman ulaştığını sorun, sonra hangi rotanın sunduğunu sorun ve ardından kaydın faturalandırma, önbellek, model ve anahtar bağlamı hakkında başka neler söylediğini sorun. Bu sıra basittir ve Konsolun verileri sunma şekliyle eşleşir.

Sınırlamalar

Akış, verimi değil ilerlemeyi gösterir, çünkü bir akış hızlı başlayıp bitmesi uzun sürebilir. Hızlı bir ilk token, tüm isteğin hızlı olduğu anlamına gelmez. İlk token zamanlaması ayrıca modele ve rotaya bağlıdır. Modeller arasında değil, model içinde karşılaştırma yapın.

ttft_ms değerindeki bir değişiklik, sadece istemi değil; yönlendirmeyi, önbellek durumunu veya model seçimini yansıtabilir. ttft_ms değerini istek günlüğündeki bir sinyal olarak kabul edin. Bir sonuca varmadan önce onu diğer istek düzeyi kanıtlarıyla eşleştirin. Bu, bir oturumu okumak için bir yüzeydir, modelleri sıralamak için bir benchmark değildir.

Konsol, bir sohbet akışını bir iş çalıştırıcısına dönüştürmez. Uzun süren bir görüntü göreviniz varsa, sohbet akışını açık tutmak yerine asenkron görüntü oluşturma görevleri kılavuzunu kullanın. Akış yüzeyi, token token gelen yanıtlar içindir. Asenkron kılavuz ise bir sohbet yanıtı dışında çalışan işler içindir.

Ayrıca, istek düzeyi kanıtlarının organizasyonla sınırlı olduğunu ve bir isteği etrafındaki hesap bağlamına bağladığını unutmayın. Bu aynı zamanda bir isteği küresel bir benchmark olarak görmemeniz gerektiği anlamına gelir. Kayıt; yönlendirme, faturalandırma durumu, önbellek durumu ve o istek için model ve anahtar bağlamını kapsar. Teşhise başlamak için güçlü bir yerdir. Sağlayıcıların veya modellerin bir sıralaması değildir. Oturumları karşılaştırdığımızda, aynı model ve aynı rota ailesi içinde karşılaştırma yaparız, bu da karşılaştırmayı dürüst tutar.

SSS

Eski Konsol bağlantılarım hala çalışıyor mu?

Evet. Eski bağlantılar çalışmaya devam eder ve mevcut konuşmalar birleştirme boyunca korunmuştur. Manuel olarak taşımanız gereken hiçbir şey yok. Bir Konsol sayfasını yer imlerine eklediyseniz, hala çalışır.

İlk token zamanlaması aslında neyi ölçer?

Akışlı bir yanıtta ilk tokenın ne zaman ulaştığını ölçer; Konsol bunu arayüzde gösterir ve istek günlüğünde isteğe bağlı bir sütun olan ttft_ms olarak kaydeder. Toplam gecikmeyi veya verimi ölçmez.

Bir konuşmanın bakiyesi tükendiğinde nereden yükleme yaparım?

Konuşma sırasında bakiye azaldığında beliren, konuşmanın yanındaki bakiye yükleme girişini kullanın; böylece oturumdan ayrılmadan bakiyeyi yönetebilirsiniz. Kontrol panelindeki faturalandırma sayfası, daha geniş hesap işlemleri için yer olmaya devam eder.

İlk token zamanlamasını farklı modeller arasında karşılaştırabilir miyim?

Hayır, temiz bir karşılaştırma olarak değil. İlk token zamanlaması modele ve rotaya bağlıdır, bu yüzden modeller arasında değil, model içinde karşılaştırma yapın. ttft_ms değerini bir model sıralaması olarak değil, bir istek düzeyi sinyali olarak kullanın.

Bir API anahtarı oluşturun ve kontrol panelinde yeni Konsol ile bir oturum çalıştırın.