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

Başarısız bir AI API çağrısı nadiren kendini net bir şekilde belli eder. Bir durum kodu, belki bir hata dizesi ve birinin "request ID neydi?" diye sorduğu bir destek kanalıyla karşılaşırsınız. Elinizde hazır bir bilgi yoksa, inceleme daha başlamadan tıkanır. TokenLab Request Console'u, istek düzeyindeki ayrıntıları tek bir pano görünümüne getirerek bu boşluğu doldurmak için oluşturduk. Bu konsol; model, anahtar, önbellek durumu, faturalandırma durumu, zamanlama ve maskelenmiş bir payload önizlemesini gösterir. İş akışımızda, request ID'yi ilk arama anahtarı olarak kabul ediyoruz.

Önemli Çıkarımlar

• TokenLab Request Console, bir faturalandırma raporu değil, TokenLab API panosu içindeki istek düzeyinde bir hata ayıklama yüzeyidir.
• Her isteğin doğrudan arayabileceğiniz bir ID'si vardır. URL'deki requestId ile belirli bir isteğe doğrudan bağlantı 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, kuruluşunuzla 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ıklama için konsolu, zaman aralıkları genelinde toplu maliyet incelemesi için ise kullanım dışa aktarma (usage exports) özelliklerini kullanın.

TokenLab Request Console Nedir?

Bu konsola, TokenLab panosunun API bölümü içindeki /dashboard/api?tab=requestConsole adresinden ulaşabilirsiniz. API panosunun kendisi /dashboard/api adresinde bulunur. Konsol tek bir önerme üzerine kuruludur: Bir istek başarısız olduğunda, en hızlı çözüm, yalnızca bir hata mesajına dayanarak tahminde bulunmak yerine, isteğin tüm bağlamını önünüzde görmektir.

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 denetleyici olarak tanımlar. Konsolun birkaç çalışma bölümüne ayrıldığını görüyoruz.

Liste görünümü. Son isteklerin filtrelenebilir bir tablosu. Belirli bir request ID'niz henüz yoksa başlangıç noktanız burasıdır. Başarısız veya olağandışı çağrıyı ararsınız.

Denetleyici paneli. Bir istek seçtiğinizde, denetleyici tüm ayrıntılarla açılır: isteğe hangi modelin hizmet verdiği, hangi API anahtarının kullanıldığı, önbelleğe alınıp alınmadığı 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. Ayrı bir hata günlüğünü çapraz referanslamanız gerekmez.

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 bu dört durum en önemli olanlardır.

Payload önizlemesi. İstek ve yanıt gövdeleri, mevcut olduklarında maskelenmiş önizlemeler olarak gösterilir; bu da gövdedeki ham gizli bilgileri 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 özel modelin yönettiği. Bu, tek bir entegrasyonun arkasında birden fazla model çalıştırdığınızda ve doğru olanın çağrıldığını doğrulamanız gerektiğinde kullanışlıdır.

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

İlk Olarak Neyi İncelemeli?

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

Beş alanlı triyaj

Kontrol	Size ne anlatır
Request ID	Benzer bir isteği 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 sorusu mu yoksa teknik bir soru mu olduğunu belirtir
Model	İsteğe fiilen hangi modelin hizmet verdiği (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. İstemci tarafı günlüğünden, bir destek biletinden veya bir hata raporundan elinizde varsa, derin bağlantı (deep-link) modelini kullanın:

/dashboard/api?tab=requestConsole&requestId=%3Crequest_id>

Bu, liste görünümünü tamamen atlayarak denetleyiciyi doğrudan söz konusu istek üzerinde açar. Birisi size bir ID verip "burada ne oldu?" diye sorduğunda en hızlı yol budur.

Henüz bir request ID'niz yoksa, konsolun filtreleri; model, zaman aralığı, prompt önbellek durumu, anahtar kaynağı ve duruma göre daraltma yapmanızı sağlar. Örneğin, bir istek başarısız olduğunda, son bir saat içindeki 'başarısız' durumuna göre filtreleyin, ardından kullanıcının sorduğu belirli ç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ı, çağrının tamamlandığı ve kredi tükettiği anlamına gelir. Bir kullanıcı bir hata bildirirse ancak istek faturalandırılmış görünüyorsa, bunu ayrıca işaretlemeye değer. Bu, hatanın başarılı bir yanıttan sonra istemci tarafında gerçekleştiğini gösterir.
• Beklemede, isteğin hala iletimde olduğu veya sonuçlanmayı beklediği anlamına gelir. Bunu erkenden bir başarısızlık olarak değerlendirmeyin.
• İade edildi, TokenLab'in ücreti geri aldığı anlamına gelir; genellikle sağlayıcı veya yönlendirme tarafındaki bir hatayla ilişkilidir.
• Başarısız, ç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, karşılıklı zaman kaybını önler.

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ğrulayın. Yanlış yapılandırılmış bir istemci, eski bir ortam değişkeni veya bir yönlendirme geçersiz kılma işlemi, trafiği istemci tarafında belirgin bir hata olmadan 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) küçük de olsa değiştiği anlamına gelir. Bir zaman damgası, yeniden sıralanmış bir alan veya fazladan bir boşluk karakteri olup olmadığına bakın. Konsolun önbellek durumu filtresi, isabet eden ve ıskalayan istekleri yan yana karşılaştırmanıza olanak tanır.

TokenLab Request Console, Kullanım Dışa Aktarma (Usage Exports) ile Nasıl Çalışır?

Request Console ve kullanım dışa aktarma işlemleri farklı sorunları çözer, bu nedenle sınır konusunda net olmakta fayda var. Konsol, tekil istek incelemesi için oluşturulmuştur: bir çağrı, bir hata, bir faturalandırma sorusu; denetleyici panelinde yanıtlanır. Belirli bir istek başarısız olduğunda ve nedenini hemen bilmeniz gerektiğinde açtığınız yerdir.

Kullanım dışa aktarma işlemleri ise toplu inceleme için oluşturulmuştur: bir zaman aralığındaki harcama, model veya anahtara göre dökümler ve bir finans paydaşına sunacağınız veya aylık mutabakat için kullanacağınız türden raporlama. "Geçen hafta DeepSeek V4 Pro için ne kadar harcadık?" sorusunu yanıtlamak istiyorsanız, bu bir dışa aktarma sorusudur, konsol sorusu değil. 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 aktarma. Bazı ekipler her ikisini de sırayla kullanır. Bir dışa aktarma, toplam harcamadaki bir anormalliği ortaya çıkarır ve konsol, buna neden olan belirli isteklerin derinlemesine incelendiği yerdir.

Pratik Bir Hata Ayıklama Rutini

Ad hoc hata ayıklama, baskı altında tahmine dayalı bir sürece 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. Bugün kendi tarafınızda request ID'leri günlüğe kaydetmiyorsanız, hemen başlayın. Elinizdeki en hızlı arama anahtarıdır.
2. Konsolu derin bağlantı ile açın. Denetleyiciye doğrudan 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. Bir isabet beklerken 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. https://docs.tokenlab.sh/api-reference/chat/create-completion adresindeki 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 bunu kullanın.
10. Eğer bu tek seferlik değil de bir kalıpsa, kullanım dışa aktarmaya 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ığı gerçekten açıklayan alanı atlamanızı engeller.

SSS

Request ID olmadan başarısız bir isteği nasıl bulabilirim?

TokenLab Request Console'daki liste görünümü filtrelerini kullanın. Model, zaman aralığı, prompt önbellek durumu, anahtar kaynağı ve duruma göre daraltın. Örneğin, son bir saat içindeki 'başarısız' durumuna göre filtreleyin, ardından kullanıcının sorduğu çağrıyı tarayın. Bulduğunuzda, denetleyiciyi açın ve gelecekteki günlükler için request ID'yi kopyalayın.

İstemci bir hata bildirdiğinde istek neden faturalandırılmış görünebilir?

Faturalandırıldı, çağrının tamamlandığı ve kredi tükettiği anlamına gelir. Bir kullanıcı bir hata bildirirse ancak istek faturalandırılmış görünüyorsa, hata muhtemelen başarılı bir yanıttan sonra istemci tarafında gerçekleşmiştir. Bu durumu ayrıca işaretleyin çünkü başarısız veya iade edilen bir isteğe göre farklı bir çözüm yolu gerektirir.

Denetleyicideki bir önbellek ıskalaması bana ne anlatır?

Önbellek ıskalaması, isteğin prompt önbelleğine isabet etmediği anlamına gelir. Bu, maliyet ve gecikme için önemlidir. Bir isabet beklerken gerçekleşen bir ıskalama, genellikle prompt önekinin küçük de olsa değiştiği anlamına gelir. Bir zaman damgası, yeniden sıralanmış bir alan veya fazladan bir boşluk karakteri olup olmadığını kontrol edin.

Bir istek bağlantısını ekip arkadaşımla paylaşabilir miyim?

Evet, pano üyelik izinleri izin veriyorsa. İstek verileri kuruluşunuzla sınırlıdır. Denetleyiciyi doğrudan açmak için /dashboard/api?tab=requestConsole&requestId=<request_id> derin bağlantı biçimini kullanın. Ekip arkadaşlarınız rollerinin izin verdiği kadarını görür.

Konsoldan kullanım dışa aktarmaya ne zaman geçmeliyim?

Sorun tek seferlik değil de bir kalıp olduğunda 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. Bir zaman aralığındaki harcama, model veya anahtara göre dökümler ve aylık mutabakat için dışa aktarma işlemlerini kullanın.

Kaynaklar ve Güncellik

• TokenLab Request Console — /dashboard/api?tab=requestConsole — gözlemlenen 2026-07-09
• TokenLab Chat Completions API referansı — https://docs.tokenlab.sh/api-reference/chat/create-completion — gözlemlenen 2026-07-09
• TokenLab Dashboard Usage Exports — /blog/tokenlab-dashboard-usage-exports — gözlemlenen 2026-07-09
• TokenLab genel model dizini — /models — gözlemlenen 2026-07-09
• TokenLab API anahtar panosu — /dashboard/api — gözlemlenen 2026-07-09

Referans verilen model örnekleri (Claude Sonnet 5, DeepSeek V4 Pro, Gemini 3.5 Flash), 2026-09-19 itibarıyla güncel model SSOT'unu yansıtmaktadır. Bu konsol notu için kaynak anlık görüntüsü 2026-07-09 tarihinde gözlemlenmiştir; kaynaktaki orijinal model SSOT tarihi 2026-07-07'dir.

Sonraki Adımlar

AI API hatalarında hata ayıklamak için istemci tarafı günlüklerini grep ile tarayıp ayrı bir faturalandırma panosunu çapraz referanslıyorsanız, Request Console bu döngüden bir adımı kaldırır. Konsol /dashboard/api?tab=requestConsole adresinde bulunur. API anahtar panosu tokenlab.sh/dashboard/api adresindedir. Chat completions istek/yanıt şekli https://docs.tokenlab.sh/api-reference/chat/create-completion adresinde belgelenmiştir. Toplam harcama incelemesi için kullanım dışa aktarma özelliklerini kullanın. Model fiyatlandırması ve bağlam penceresi ayrıntıları için model dizinine bakın. Konsolu açın ve ID ile yakın zamanda başarısız olan bir isteği bulun.