TokenLab Request Console: Debug Panggilan API AI dari Satu Dasbor

Kegagalan panggilan AI API jarang sekali memberikan pemberitahuan yang jelas. Anda mendapatkan kode status, mungkin string error, dan saluran dukungan di mana seseorang bertanya "apa ID permintaannya?". Jika Anda tidak memilikinya, investigasi akan terhenti bahkan sebelum dimulai.

TokenLab Request Console hadir untuk menutup celah tersebut. Konsol ini menyajikan detail tingkat permintaan — model, key, status cache, status penagihan, waktu, dan pratinjau payload yang disensor — ke dalam satu tampilan dasbor, sehingga Anda dapat beralih dari "panggilan ini gagal" menjadi "ini alasannya" tanpa harus menyatukan log dari tiga tempat berbeda.

Artikel ini membahas apa saja yang ditampilkan konsol, apa yang harus diperiksa terlebih dahulu saat terjadi masalah, dan bagaimana konsol ini melengkapi ekspor penggunaan bagi tim yang juga memerlukan laporan tingkat biaya.

Poin Penting

• Request Console adalah antarmuka debugging tingkat permintaan di dalam dasbor API TokenLab, bukan laporan penagihan.
• Setiap permintaan memiliki ID yang dapat Anda cari secara langsung, dan Anda dapat melakukan deep-link ke permintaan tertentu dengan requestId di URL.
• Konsol menampilkan perutean, status penagihan, status cache, konteks model/key, dan pratinjau payload yang disensor untuk permintaan terbaru.
• Akses dibatasi untuk organisasi Anda dan diatur oleh izin keanggotaan dasbor — rekan tim melihat apa yang diizinkan oleh peran mereka.
• Untuk debugging insiden tunggal, gunakan konsol. Untuk tinjauan biaya batch dalam rentang waktu tertentu, gunakan ekspor penggunaan sebagai gantinya.

Apa Itu Request Console

Anda dapat mengaksesnya di https://tokenlab.sh/en/dashboard/api?tab=requestConsole, di dalam bagian API pada dasbor TokenLab. Konsol ini dibangun berdasarkan satu premis: ketika permintaan gagal, perbaikan tercepat datang dari memiliki konteks lengkap di depan Anda, bukan dari menebak-nebak berdasarkan pesan error saja.

Deskripsi dasbor menyebut konsol ini sebagai inspektur untuk permintaan terbaru, yang mencakup perutean, penagihan, body permintaan/respons, dan konteks vendor model. Dalam praktiknya, ini terbagi menjadi beberapa bagian kerja.

Tampilan daftar. Tabel permintaan terbaru yang dapat difilter. Di sinilah Anda memulai ketika Anda belum memiliki ID permintaan tertentu — Anda memindai panggilan yang gagal atau tidak biasa.

Panel inspektur. Setelah Anda memilih permintaan, inspektur akan terbuka dengan detail lengkap: model mana yang melayaninya, API key mana yang digunakan, apakah permintaan tersebut mencapai cache, dan apa status akhirnya.

Konteks error. Jika permintaan gagal, konsol akan menampilkan informasi error yang terikat pada panggilan spesifik tersebut, sehingga Anda tidak perlu melakukan referensi silang dengan log error terpisah.

Status rute dan penagihan. Menunjukkan bagaimana permintaan dirutekan dan apakah permintaan tersebut ditagih, tertunda (pending), dikembalikan (refunded), atau gagal — empat status yang paling penting ketika pelanggan bertanya "apakah saya dikenakan biaya untuk error itu?".

Pratinjau payload. Body permintaan dan respons ditampilkan sebagai pratinjau yang disensor jika tersedia, memberikan Anda bentuk dan struktur tanpa mengekspos rahasia mentah di dalam body.

Konteks vendor model dan key model. Vendor mana dan model spesifik mana yang menangani panggilan tersebut — berguna ketika Anda menjalankan beberapa model di balik satu integrasi dan perlu mengonfirmasi bahwa model yang tepat telah dipanggil.

Semua ini tidak mengharuskan Anda membangun pipeline logging sendiri di atas API. Semuanya sudah ditampilkan per organisasi, difilter berdasarkan izin keanggotaan dasbor, sehingga rekan tim dengan akses yang sesuai akan melihat data permintaan yang sama dengan Anda.

Apa yang Harus Diperiksa Terlebih Dahulu

Ketika panggilan API gagal, ada urutan alami untuk memeriksa berbagai hal. Melompat langsung ke "apakah model sedang down" sebelum mengonfirmasi bahwa permintaan telah mencapai endpoint yang tepat hanya akan membuang waktu.

Triage lima bidang

Pemeriksaan	Apa yang diberitahukan kepada Anda
Request ID	Mengonfirmasi bahwa Anda melihat panggilan yang tepat, bukan panggilan yang serupa
Status	Ditagih, tertunda, dikembalikan, atau gagal — memberi tahu Anda apakah ini masalah biaya atau masalah teknis
Model	Model mana yang benar-benar melayani permintaan (berguna jika Anda merutekan ke beberapa model)
Status cache	Apakah hit atau miss pada cache prompt mengubah biaya atau latensi
Sumber key	API key mana yang digunakan, berguna ketika beberapa key atau lingkungan berbagi satu integrasi

Mulailah dengan ID permintaan. Jika Anda memilikinya dari log sisi klien, tiket dukungan, atau laporan error, gunakan pola deep-link:

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

Itu akan membuka inspektur langsung pada permintaan yang dimaksud, melewati tampilan daftar sepenuhnya. Ini adalah jalur tercepat ketika seseorang memberikan ID kepada Anda dan bertanya "apa yang terjadi di sini."

Jika Anda belum memiliki ID permintaan, filter konsol memungkinkan Anda mempersempit pencarian berdasarkan model, rentang waktu, status cache prompt, sumber key, dan status. Pola umum: filter berdasarkan status "gagal" dalam satu jam terakhir, lalu pindai daftar untuk mencari panggilan spesifik yang ditanyakan pengguna.

Membaca bidang status dengan benar

Empat status — ditagih, tertunda, dikembalikan, gagal — menjawab pertanyaan yang berbeda:

• Ditagih (Billed) berarti panggilan selesai dan menghabiskan kredit. Jika pengguna melaporkan error tetapi permintaan menunjukkan status ditagih, itu perlu ditandai secara terpisah, karena menunjukkan bahwa kegagalan terjadi di sisi klien setelah respons yang berhasil.
• Tertunda (Pending) berarti permintaan masih dalam proses atau menunggu penyelesaian. Jangan menganggap ini sebagai kegagalan sebelum waktunya.
• Dikembalikan (Refunded) berarti TokenLab membatalkan tagihan, biasanya terkait dengan kegagalan di sisi penyedia atau perutean.
• Gagal (Failed) berarti panggilan tidak selesai dengan sukses dan tidak ditagih.

Mengetahui status mana yang berlaku sebelum Anda melakukan eskalasi akan menghemat waktu komunikasi bolak-balik dengan dukungan.

Mengonfirmasi model dan status cache

Jika Anda menjalankan permintaan terhadap model seperti Claude Sonnet 5, DeepSeek V4 Pro, atau Gemini 3.5 Flash melalui integrasi bersama, ada baiknya untuk mengonfirmasi bahwa konsol menampilkan model yang Anda harapkan. Klien yang salah konfigurasi, variabel lingkungan yang kedaluwarsa, atau penggantian perutean dapat mengirim lalu lintas ke model yang salah tanpa error yang jelas di sisi klien.

Status cache penting karena dua alasan: biaya dan latensi. Cache miss di tempat yang Anda harapkan hit biasanya berarti awalan prompt berubah, meskipun secara halus — stempel waktu, bidang yang diurutkan ulang, atau karakter spasi tambahan. Filter status cache konsol memungkinkan Anda membandingkan permintaan hit dan miss secara berdampingan.

Cara Kerjanya dengan Ekspor Penggunaan

Request Console dan ekspor penggunaan menyelesaikan masalah yang berbeda, dan penting untuk memperjelas batasannya agar Anda tidak menggunakan alat yang salah.

Konsol dibangun untuk investigasi permintaan tunggal: satu panggilan, satu error, satu pertanyaan penagihan, dijawab di panel inspektur. Inilah yang Anda buka ketika permintaan tertentu gagal dan Anda perlu tahu alasannya, saat itu juga.

Ekspor penggunaan dibangun untuk tinjauan agregat: pengeluaran dalam rentang waktu tertentu, perincian berdasarkan model atau key, dan jenis laporan yang akan Anda berikan kepada pemangku kepentingan keuangan atau digunakan untuk rekonsiliasi bulanan. Jika Anda mencoba menjawab "berapa banyak yang kita habiskan untuk DeepSeek V4 Pro minggu lalu", itu adalah pertanyaan ekspor, bukan pertanyaan konsol. Lihat panduan ekspor penggunaan dasbor TokenLab untuk alur kerja tersebut.

Singkatnya: konsol untuk insiden, ekspor untuk total. Beberapa tim menggunakan keduanya secara berurutan — ekspor mengungkap anomali dalam pengeluaran agregat, dan konsol adalah tempat Anda menelusuri permintaan spesifik yang menyebabkannya.

Rutinitas Debugging Praktis

Debugging ad hoc berubah menjadi tebak-tebakan di bawah tekanan. Rutinitas yang dapat diulang mencegah insiden berlangsung lebih lama dari yang seharusnya.

Daftar periksa: ketika permintaan gagal

1. Dapatkan ID permintaan. Dari log klien, respons error, atau laporan pengguna. Jika Anda tidak mencatat ID permintaan di sisi Anda hari ini, mulailah sekarang — itu adalah kunci pencarian tercepat yang Anda miliki.
2. Buka konsol dengan deep link. Gunakan parameter kueri requestId untuk langsung melompat ke inspektur.
3. Periksa bidang status terlebih dahulu. Ditagih, tertunda, dikembalikan, atau gagal — ini membingkai sisa investigasi.
4. Konfirmasi model yang benar-benar melayani permintaan. Bandingkan dengan apa yang Anda harapkan untuk dikirim.
5. Periksa status cache. Cache miss di tempat yang Anda harapkan hit dapat menjelaskan latensi atau biaya yang tidak terduga.
6. Periksa sumber key. Konfirmasi API key dan lingkungan yang tepat sedang digunakan, terutama dalam pengaturan staging-vs-production.
7. Baca konteks error dan informasi rute. Di sinilah biasanya akar penyebab yang sebenarnya terlihat.
8. Tinjau pratinjau payload yang disensor. Konfirmasi bentuk permintaan cocok dengan apa yang dikirim klien Anda — parameter yang salah bentuk sering muncul di sini sebelum muncul di tempat lain.
9. Referensi silang dengan referensi API jika diperlukan. Referensi API chat completions TokenLab mendokumentasikan bentuk permintaan dan respons yang diharapkan, berguna untuk mengonfirmasi apakah payload salah bentuk di sisi klien.
10. Jika itu adalah pola, bukan kejadian satu kali, beralihlah ke ekspor penggunaan. Satu permintaan yang gagal adalah masalah konsol. Sepuluh permintaan yang gagal dalam satu jam adalah pola yang layak untuk diekspor dan ditinjau secara agregat.

Mengikuti urutan ini — ID, status, model, cache, key, error, payload — mencegah Anda melewatkan bidang yang sebenarnya menjelaskan kegagalan tersebut.

Langkah Selanjutnya

Jika Anda saat ini melakukan debugging kegagalan AI API dengan melakukan grep melalui log sisi klien Anda sendiri dan melakukan referensi silang dengan dasbor penagihan terpisah, Request Console menghapus satu langkah dari loop tersebut. Mulailah dengan menemukan permintaan gagal terbaru dan membukanya secara langsung.

• Buka konsol dan cari permintaan berdasarkan ID: https://tokenlab.sh/en/dashboard/api?tab=requestConsole
• Buat API key TokenLab di tokenlab.sh/en/dashboard/api untuk mulai membuat permintaan dari konsol atau skrip Anda sendiri.
• Periksa bentuk permintaan/respons chat completions jika Anda mencurigai payload salah bentuk: https://docs.tokenlab.sh/api-reference/chat/create-completion
• Untuk tinjauan pengeluaran agregat, gunakan ekspor penggunaan daripada konsol: https://tokenlab.sh/en/blog/tokenlab-dashboard-usage-exports
• Jika Anda membandingkan model untuk biaya atau kemampuan sebelum beralih, direktori model memiliki detail harga dan context window saat ini: https://tokenlab.sh/en/models

FAQ

Apa itu TokenLab Request Console? Ini adalah tampilan debugging tingkat permintaan di dalam dasbor API TokenLab. Konsol ini menampilkan perutean, status penagihan, status cache, konteks model dan key, serta pratinjau payload yang disensor untuk permintaan terbaru, yang dibatasi untuk organisasi Anda.

Bisakah saya memeriksa permintaan berdasarkan ID permintaan? Ya. Gunakan format deep-link /dashboard/api?tab=requestConsole&requestId=<request_id> untuk membuka inspektur langsung pada permintaan tertentu, atau cari berdasarkan ID permintaan dari tampilan daftar.

Apakah konsol menggantikan ekspor penggunaan? Tidak. Konsol adalah untuk menyelidiki permintaan individu — satu kegagalan, satu pertanyaan penagihan. Ekspor penggunaan adalah untuk tinjauan pengeluaran agregat dalam rentang waktu tertentu. Gunakan keduanya bersama-sama ketika ekspor mengungkap pola yang perlu Anda telusuri.

Apa yang harus saya periksa terlebih dahulu ketika permintaan AI API gagal? Mulailah dengan ID permintaan untuk mengonfirmasi bahwa Anda melihat panggilan yang tepat, lalu periksa bidang status (ditagih, tertunda, dikembalikan, gagal), model yang benar-benar melayaninya, dan status cache. Dari sana, konteks error dan pratinjau payload biasanya membuat akar penyebab terlihat.

Sumber dan Kesegaran

• TokenLab Request Console — https://tokenlab.sh/en/dashboard/api?tab=requestConsole — diamati 2026-07-09
• Referensi API Chat Completions TokenLab — https://docs.tokenlab.sh/api-reference/chat/create-completion — diamati 2026-07-09
• Ekspor Penggunaan Dasbor TokenLab — https://tokenlab.sh/en/blog/tokenlab-dashboard-usage-exports — diamati 2026-07-09
• Direktori model publik TokenLab — https://tokenlab.sh/en/models — diamati 2026-07-09

Contoh model yang direferensikan (Claude Sonnet 5, DeepSeek V4 Pro, Gemini 3.5 Flash) mencerminkan SSOT model saat ini per 2026-07-07. Untuk harga dan ketersediaan terkini yang tepat, verifikasi terhadap tautan direktori model di atas sebelum membuat keputusan perutean.