TokenLab Request Console: AI API Çağrılarını Tek Bir Dashboard'dan Hata Ayıklayın

Başarısız bir AI API çağrısı nadiren kendini açıkça belli eder. Bir durum kodu, belki bir hata dizisi ve birinin "request ID neydi?" diye sorduğu bir destek kanalıyla karşılaşırsınız. Eğer elinizin altında yoksa, inceleme daha başlamadan tıkanır.

TokenLab Request Console, bu boşluğu doldurmak için var. İstek düzeyindeki detayları (model, anahtar, önbellek durumu, faturalandırma durumu, zamanlama ve maskelenmiş payload önizlemesi) tek bir pano görünümüne getirir; böylece üç farklı yerden günlükleri birleştirmek zorunda kalmadan "bu çağrı başarısız oldu" noktasından "nedeni bu" noktasına ulaşabilirsiniz.

Bu makale, konsolun neler gösterdiğini, bir şeyler bozulduğunda ilk olarak nelerin kontrol edilmesi gerektiğini ve maliyet düzeyi raporlamasına ihtiyaç duyan ekipler için kullanım dışa aktarımlarıyla (usage exports) nasıl bir arada çalıştığını ele almaktadır.

Öne Çıkanlar

• Request Console, bir faturalandırma raporu değil, TokenLab API panosu içindeki istek düzeyinde bir hata ayıklama arayüzüdür.
• Her isteğin doğrudan arayabileceğiniz bir ID'si vardır ve URL'deki requestId ile belirli bir isteğe doğrudan bağlantı (deep-link) verebilirsiniz.
• Konsol; yönlendirme, faturalandırma durumu, önbellek durumu, model/anahtar bağlamı ve son istekler için maskelenmiş payload önizlemelerini gösterir.
• Erişim, organizasyonunuzla sınırlıdır ve pano üyelik izinleri tarafından yönetilir; ekip arkadaşlarınız rollerinin izin verdiği kadarını görür.
• Tekil olaylarda hata ayıklamak için konsolu, zaman aralıkları genelinde toplu maliyet incelemesi için ise kullanım dışa aktarımlarını kullanın.

Request Console Nedir?

Buna, TokenLab panosunun API bölümü içindeki https://tokenlab.sh/en/dashboard/api?tab=requestConsole adresinden ulaşabilirsiniz. Tek bir önerme üzerine inşa edilmiştir: bir istek başarısız olduğunda, en hızlı çözüm sadece hata mesajına dayanarak tahmin yürütmekten değil, tüm bağlamı önünüzde görmekten geçer.

Pano açıklaması, konsolu yönlendirme, faturalandırma, istek/yanıt gövdesi ve model sağlayıcı bağlamını kapsayan son istekler için bir denetçi olarak tanımlar. Uygulamada bu, birkaç çalışma bölümüne ayrılır.

Liste görünümü. Son isteklerin filtrelenebilir bir tablosu. Henüz belirli bir request ID'niz olmadığında buradan başlarsınız; başarısız veya sıra dışı çağrıyı tararsınız.

Denetçi paneli. Bir istek seçtiğinizde, denetçi tüm detaylarla açılır: hangi modelin hizmet verdiği, hangi API anahtarının kullanıldığı, önbelleğe isabet edip etmediği ve nihai durumun ne olduğu.

Hata bağlamı. İstek başarısız olursa konsol, o belirli çağrıyla ilişkili hata bilgilerini ortaya çıkarır, böylece ayrı bir hata günlüğünü çapraz referansla kontrol etmek zorunda kalmazsınız.

Rota ve faturalandırma durumu. İsteğin nasıl yönlendirildiğini ve faturalandırılıp faturalandırılmadığını, beklemede mi, iade mi edildiğini veya başarısız mı olduğunu gösterir; bir müşteri "bu hata için ücretlendirildim mi?" diye sorduğunda en önemli olan dört durum budur.

Payload önizlemesi. İstek ve yanıt gövdeleri, mevcut olduğunda maskelenmiş önizlemeler olarak gösterilir; bu da gövdedeki ham sırları açığa çıkarmadan size şekil ve yapı hakkında bilgi verir.

Model sağlayıcı ve model anahtar bağlamı. Çağrıyı hangi sağlayıcının ve hangi spesifik modelin yönettiği; tek bir entegrasyonun arkasında birden fazla model çalıştırıyorsanız ve doğru olanın çağrıldığını teyit etmeniz gerekiyorsa kullanışlıdır.

Bunların hiçbiri, API'nizin üzerinde kendi günlük kaydı hattınızı oluşturmanızı gerektirmez. Zaten organizasyon bazında sunulur ve pano üyelik izinlerine göre filtrelenir, böylece uygun erişime sahip ekip arkadaşlarınız sizinle aynı istek verilerini görür.

İlk Olarak Neler İncelenmeli?

Bir API çağrısı başarısız olduğunda, kontrol edilecek şeylerin doğal bir sırası vardır. İsteğin doğru uç noktaya ulaştığını bile doğrulamadan doğrudan "model mi çöktü" sorusuna atlamak zaman kaybıdır.

Beş alanlı triyaj

Kontrol	Size ne anlatır
Request ID	Benzer bir çağrıyı değil, tam olarak söz konusu çağrıyı incelediğinizi doğrular
Durum	Faturalandırıldı, beklemede, iade edildi veya başarısız — bunun bir maliyet sorunu mu yoksa teknik bir sorun mu olduğunu söyler
Model	İsteğe fiilen hangi model hizmet verdi (birden fazla model arasında yönlendirme yapıyorsanız kullanışlıdır)
Önbellek durumu	Bir prompt önbelleği isabetinin veya ıskalamasının maliyeti veya gecikmeyi değiştirip değiştirmediği
Anahtar kaynağı	Hangi API anahtarının kullanıldığı; birden fazla anahtar veya ortam bir entegrasyonu paylaştığında kullanışlıdır

Request ID ile başlayın. Eğer bunu bir istemci tarafı günlüğünden, destek biletinden veya hata raporundan aldıysanız, deep-link modelini kullanın:

https://tokenlab.sh/en/dashboard/api?tab=requestConsole&requestId=<request_id>

Bu, denetçiyi doğrudan söz konusu istek üzerinde açar ve liste görünümünü tamamen atlar. Birisi size bir ID verip "burada ne oldu" diye sorduğunda en hızlı yoldur.

Henüz bir request ID'niz yoksa, konsolun filtreleri model, zaman aralığı, prompt önbellek durumu, anahtar kaynağı ve duruma göre daraltmanıza olanak tanır. Yaygın bir yöntem: son bir saat içindeki "başarısız" durumuna göre filtreleyin, ardından bir kullanıcının sorduğu spesifik çağrıyı listede tarayın.

Durum alanını doğru okumak

Dört durum — faturalandırıldı, beklemede, iade edildi, başarısız — farklı soruları yanıtlar:

• Faturalandırıldı (Billed), çağrının tamamlandığını ve kredi tükettiğini gösterir. Bir kullanıcı hata bildiriyor ancak istek faturalandırılmış görünüyorsa, bu ayrı olarak işaretlenmelidir; çünkü başarısızlığın başarılı bir yanıttan sonra istemci tarafında gerçekleştiğini gösterir.
• Beklemede (Pending), isteğin hala iletimde olduğunu veya sonuçlanmayı beklediğini gösterir. Bunu vaktinden önce bir başarısızlık olarak değerlendirmeyin.
• İade edildi (Refunded), TokenLab'in ücreti geri aldığı anlamına gelir; genellikle sağlayıcı veya yönlendirme tarafındaki bir başarısızlıkla ilişkilidir.
• Başarısız (Failed), çağrının başarıyla tamamlanmadığı ve faturalandırılmadığı anlamına gelir.

Destek ekibiyle iletişime geçmeden önce bunlardan hangisinin geçerli olduğunu bilmek, bir dizi karşılıklı yazışmadan tasarruf etmenizi sağlar.

Modeli ve önbellek durumunu doğrulamak

Claude Sonnet 5, DeepSeek V4 Pro veya Gemini 3.5 Flash gibi modellere karşı paylaşılan bir entegrasyon üzerinden istek gönderiyorsanız, konsolun beklediğiniz modeli gösterdiğini doğrulamaya değer. Yanlış yapılandırılmış bir istemci, eski bir ortam değişkeni veya bir yönlendirme geçersiz kılma işlemi, istemci tarafında belirgin bir hata olmadan trafiği yanlış modele gönderebilir.

Önbellek durumu iki nedenden dolayı önemlidir: maliyet ve gecikme. Bir isabet beklerken gerçekleşen bir önbellek ıskalaması, genellikle prompt önekinin (prefix) değiştiği anlamına gelir; bir zaman damgası, yeniden sıralanmış bir alan veya fazladan bir boşluk karakteri bile buna neden olabilir. Konsolun önbellek durumu filtresi, isabet ve ıskalama isteklerini yan yana karşılaştırmanıza olanak tanır.

Kullanım Dışa Aktarımları (Usage Exports) ile Nasıl Çalışır?

Request Console ve kullanım dışa aktarımları farklı sorunları çözer; yanlış araca yönelmemeniz için aradaki sınırı netleştirmekte fayda var.

Konsol, tekil istek incelemesi için oluşturulmuştur: bir çağrı, bir hata, bir faturalandırma sorusu; hepsi denetçi panelinde yanıtlanır. Belirli bir istek başarısız olduğunda ve nedenini hemen bilmeniz gerektiğinde açacağınız yer burasıdır.

Kullanım dışa aktarımları ise toplu inceleme için oluşturulmuştur: bir zaman aralığındaki harcama, model veya anahtara göre dökümler ve finansal bir paydaşa sunacağınız veya aylık mutabakat için kullanacağınız türden raporlamalar. "Geçen hafta DeepSeek V4 Pro için ne kadar harcadık" sorusunu yanıtlamaya çalışıyorsanız, bu bir konsol sorusu değil, bir dışa aktarma sorusudur. Bu iş akışı için TokenLab panosu kullanım dışa aktarma kılavuzuna bakın.

Kısacası: olaylar için konsol, toplamlar için dışa aktarımlar. Bazı ekipler her ikisini de sırayla kullanır; bir dışa aktarım toplam harcamadaki bir anomaliyi ortaya çıkarır ve konsol, buna neden olan spesifik isteklerin derinlemesine incelendiği yerdir.

Pratik Bir Hata Ayıklama Rutini

Ad hoc hata ayıklama, baskı altında tahmin yürütmeye dönüşür. Tekrarlanabilir bir rutin, olayların gereğinden uzun sürmesini engeller.

Kontrol listesi: bir istek başarısız olduğunda

1. Request ID'yi alın. İstemci günlüklerinizden, hata yanıtından veya bir kullanıcı raporundan. Eğer bugün kendi tarafınızda request ID'leri günlüğe kaydetmiyorsanız, şimdi başlayın; elinizdeki en hızlı arama anahtarı budur.
2. Konsolu deep link ile açın. Doğrudan denetçiye atlamak için requestId sorgu parametresini kullanın.
3. Önce durum alanını kontrol edin. Faturalandırıldı, beklemede, iade edildi veya başarısız — bu, incelemenin geri kalanını çerçeveler.
4. İsteğe fiilen hizmet veren modeli doğrulayın. Göndermeyi beklediğiniz modelle karşılaştırın.
5. Önbellek durumunu kontrol edin. Beklediğiniz bir isabet yerine gerçekleşen bir önbellek ıskalaması, beklenmedik gecikmeyi veya maliyeti açıklayabilir.
6. Anahtar kaynağını kontrol edin. Özellikle staging-vs-production kurulumlarında doğru API anahtarının ve ortamın kullanımda olduğunu doğrulayın.
7. Hata bağlamını ve rota bilgilerini okuyun. Gerçek kök neden genellikle burada görünür hale gelir.
8. Maskelenmiş payload önizlemesini inceleyin. İstek şeklinin istemcinizin gönderdiğiyle eşleştiğini doğrulayın; hatalı biçimlendirilmiş parametreler genellikle başka hiçbir yerde görünmeden önce burada görünür.
9. Gerekirse API referansıyla çapraz referans yapın. TokenLab chat completions API referansı, beklenen istek ve yanıt şekillerini belgeler; bir payload'un istemci tarafında hatalı biçimlendirilip biçimlendirilmediğini doğrulamak için kullanışlıdır.
10. Eğer bu tek seferlik değil de bir kalıpsa, kullanım dışa aktarımlarına geçin. Tek bir başarısız istek bir konsol sorunudur. Bir saat içinde on başarısız istek, dışa aktarmaya ve toplu olarak incelemeye değer bir kalıptır.

Bu sırayı takip etmek — ID, durum, model, önbellek, anahtar, hata, payload — başarısızlığı açıklayan alanı atlamanızı engeller.

Sonraki Adımlar

Şu anda AI API başarısızlıklarında kendi istemci tarafı günlüklerinizi grep ile tarayarak ve ayrı bir faturalandırma panosunu çapraz referansla kontrol ederek hata ayıklıyorsanız, Request Console bu döngüden bir adımı kaldırır. Yakın zamanda başarısız olan bir isteği bularak ve doğrudan açarak başlayın.

• Konsolu açın ve bir isteği ID ile bulun: https://tokenlab.sh/en/dashboard/api?tab=requestConsole
• Kendi konsolunuzdan veya betiklerinizden istek yapmaya başlamak için tokenlab.sh/en/dashboard/api adresinden bir TokenLab API anahtarı oluşturun.
• Hatalı bir payload'dan şüpheleniyorsanız chat completions istek/yanıt şeklini kontrol edin: https://docs.tokenlab.sh/api-reference/chat/create-completion
• Toplam harcama incelemesi için konsol yerine kullanım dışa aktarımlarını kullanın: https://tokenlab.sh/en/blog/tokenlab-dashboard-usage-exports
• Geçiş yapmadan önce modelleri maliyet veya yetenek açısından karşılaştırıyorsanız, model dizininde güncel fiyatlandırma ve bağlam penceresi detayları bulunur: https://tokenlab.sh/en/models

SSS

TokenLab Request Console nedir? TokenLab API panosu içinde istek düzeyinde bir hata ayıklama görünümüdür. Organizasyonunuzla sınırlı olarak son istekler için yönlendirme, faturalandırma durumu, önbellek durumu, model ve anahtar bağlamı ile maskelenmiş payload önizlemelerini gösterir.

Bir isteği request ID ile inceleyebilir miyim? Evet. Denetçiyi doğrudan belirli bir istek üzerinde açmak için /dashboard/api?tab=requestConsole&requestId=<request_id> deep-link formatını kullanın veya liste görünümünden request ID ile arama yapın.

Konsol, kullanım dışa aktarımlarının yerini alır mı? Hayır. Konsol, bireysel istekleri incelemek içindir; bir başarısızlık, bir faturalandırma sorusu. Kullanım dışa aktarımları, bir zaman aralığı genelinde toplam harcama incelemesi içindir. Bir dışa aktarım, derinlemesine incelemeniz gereken bir kalıbı ortaya çıkardığında her ikisini birlikte kullanın.

Bir AI API isteği başarısız olduğunda ilk olarak neyi kontrol etmeliyim? Doğru çağrıya baktığınızı doğrulamak için request ID ile başlayın, ardından durum alanını (faturalandırıldı, beklemede, iade edildi, başarısız), ona fiilen hizmet veren modeli ve önbellek durumunu kontrol edin. Oradan itibaren hata bağlamı ve payload önizlemesi genellikle kök nedeni görünür kılar.

Kaynaklar ve Güncellik

• TokenLab Request Console — https://tokenlab.sh/en/dashboard/api?tab=requestConsole — gözlemlenme tarihi 2026-07-09
• TokenLab Chat Completions API referansı — https://docs.tokenlab.sh/api-reference/chat/create-completion — gözlemlenme tarihi 2026-07-09
• TokenLab Pano Kullanım Dışa Aktarımları — https://tokenlab.sh/en/blog/tokenlab-dashboard-usage-exports — gözlemlenme tarihi 2026-07-09
• TokenLab genel model dizini — https://tokenlab.sh/en/models — gözlemlenme tarihi 2026-07-09

Referans verilen model örnekleri (Claude Sonnet 5, DeepSeek V4 Pro, Gemini 3.5 Flash), 2026-07-07 itibarıyla güncel model SSOT'unu yansıtmaktadır. Kesin güncel fiyatlandırma ve kullanılabilirlik için yönlendirme kararları almadan önce yukarıdaki model dizini bağlantısını doğrulayın.