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. Kami membangun TokenLab Request Console untuk menutup celah tersebut dengan menyatukan detail tingkat permintaan ke dalam satu tampilan dashboard. Konsol ini menampilkan model, key, status cache, status penagihan, waktu, dan pratinjau payload yang telah disunting. Dalam pipeline kami, kami memperlakukan ID permintaan sebagai kunci pencarian utama.

Poin Penting

• TokenLab Request Console adalah antarmuka debugging tingkat permintaan di dalam dashboard API TokenLab, bukan laporan penagihan.
• Setiap permintaan memiliki ID yang dapat Anda cari secara langsung. Anda dapat melakukan deep-link ke permintaan tertentu dengan requestId di URL.
• Konsol ini menampilkan routing, status penagihan, status cache, konteks model/key, dan pratinjau payload yang disunting untuk permintaan terbaru.
• Akses dibatasi pada organisasi Anda dan diatur oleh izin keanggotaan dashboard — 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 TokenLab Request Console

Anda dapat mengaksesnya di /dashboard/api?tab=requestConsole, di dalam bagian API dari dashboard TokenLab. Dashboard API itu sendiri berada di /dashboard/api. Konsol ini dibangun berdasarkan satu premis: ketika sebuah permintaan gagal, perbaikan tercepat datang dari memiliki konteks lengkap di depan Anda, bukan dari menebak-nebak berdasarkan pesan error saja.

Deskripsi dashboard menyebut konsol ini sebagai inspektur untuk permintaan terbaru, yang mencakup routing, penagihan, body permintaan/respons, dan konteks vendor model. Kami membaginya 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 terkait dengan panggilan spesifik tersebut. Anda tidak perlu melakukan referensi silang dengan log error terpisah.

Status rute dan penagihan. Menunjukkan bagaimana permintaan dirutekan dan apakah permintaan tersebut ditagih, tertunda, dikembalikan dananya, atau gagal. Keempat status ini paling penting ketika pelanggan bertanya 'apakah saya dikenakan biaya untuk error itu?'

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

Konteks vendor model dan kunci model. Penyedia mana dan model spesifik mana yang menangani panggilan tersebut. Ini berguna ketika Anda menjalankan beberapa model di balik satu integrasi dan perlu memastikan 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 dashboard, sehingga rekan tim dengan akses yang sesuai melihat data permintaan yang sama dengan Anda.

Apa yang Harus Diperiksa Terlebih Dahulu

Ketika panggilan API gagal, ada urutan alami untuk memeriksa berbagai hal. Langsung melompat ke 'apakah modelnya down' sebelum memastikan permintaan benar-benar mencapai endpoint yang tepat hanya akan membuang waktu.

Triage lima bidang

Cek	Apa yang diberitahukannya kepada Anda
Request ID	Mengonfirmasi bahwa Anda melihat panggilan yang tepat, bukan yang serupa
Status	Ditagih, tertunda, dikembalikan dananya, 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)
Cache state	Apakah hit atau miss cache prompt mengubah biaya atau latensi
Key source	API key mana yang digunakan, berguna ketika beberapa kunci atau lingkungan berbagi integrasi

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

/dashboard/api?tab=requestConsole&requestId=%3Crequest_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 berdasarkan model, rentang waktu, status cache prompt, sumber kunci, dan status. Misalnya, ketika permintaan gagal, filter berdasarkan status 'failed' dalam satu jam terakhir, lalu pindai daftar untuk mencari panggilan spesifik yang ditanyakan pengguna.

Membaca bidang status dengan benar

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

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

Mengetahui status mana yang berlaku sebelum Anda melakukan eskalasi akan menghemat waktu 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, konfirmasikan bahwa konsol menampilkan model yang Anda harapkan. Klien yang salah dikonfigurasi, variabel lingkungan yang kedaluwarsa, atau penggantian routing 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 mana Anda mengharapkan hit biasanya berarti awalan prompt berubah, bahkan secara halus. Cari stempel waktu, bidang yang diurutkan ulang, atau karakter spasi tambahan. Filter status cache konsol memungkinkan Anda membandingkan permintaan hit dan miss secara berdampingan.

Bagaimana TokenLab Request Console Bekerja dengan Ekspor Penggunaan

Request Console dan ekspor penggunaan menyelesaikan masalah yang berbeda, jadi ada baiknya untuk memperjelas batasannya. Konsol dibangun untuk investigasi permintaan tunggal: satu panggilan, satu error, satu pertanyaan penagihan, dijawab di panel inspektur. Ini adalah apa 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, rincian berdasarkan model atau kunci, dan jenis pelaporan yang akan Anda berikan kepada pemangku kepentingan keuangan atau digunakan untuk rekonsiliasi bulanan. Jika Anda ingin menjawab 'berapa banyak yang kami habiskan untuk DeepSeek V4 Pro minggu lalu,' itu adalah pertanyaan ekspor, bukan pertanyaan konsol. Lihat panduan ekspor penggunaan dashboard TokenLab untuk alur kerja tersebut.

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

Rutinitas Debugging Praktis

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

Daftar periksa: ketika permintaan gagal

1. Dapatkan ID permintaan. Dari log klien, respons error, atau laporan pengguna Anda. Jika Anda tidak mencatat ID permintaan di sisi Anda hari ini, mulailah sekarang. Ini 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 dananya, atau gagal. Ini membingkai sisa investigasi.
4. Konfirmasikan model yang benar-benar melayani permintaan. Bandingkan dengan apa yang Anda harapkan untuk dikirim.
5. Periksa status cache. Cache miss di mana Anda mengharapkan hit dapat menjelaskan latensi atau biaya yang tidak terduga.
6. Periksa sumber kunci. Konfirmasikan API key dan lingkungan yang tepat sedang digunakan, terutama dalam pengaturan staging-vs-production.
7. Baca konteks error dan informasi rute. Di sinilah penyebab utama biasanya menjadi terlihat.
8. Tinjau pratinjau payload yang disunting. Konfirmasikan bentuk permintaan sesuai 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 di https://docs.tokenlab.sh/api-reference/chat/create-completion mendokumentasikan bentuk permintaan dan respons yang diharapkan. Gunakan untuk mengonfirmasi apakah payload salah bentuk di sisi klien.
10. Jika ini adalah pola, bukan kejadian satu kali, beralihlah ke ekspor penggunaan. Satu permintaan yang gagal adalah masalah konsol. Sepuluh permintaan yang gagal selama satu jam adalah pola yang layak diekspor dan ditinjau secara agregat.

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

FAQ

Bagaimana cara menemukan permintaan yang gagal tanpa ID permintaan?

Gunakan filter tampilan daftar di TokenLab Request Console. Persempit berdasarkan model, rentang waktu, status cache prompt, sumber kunci, dan status. Misalnya, filter berdasarkan status 'failed' dalam satu jam terakhir, lalu pindai panggilan yang ditanyakan pengguna. Setelah menemukannya, buka inspektur dan salin ID permintaan untuk log di masa mendatang.

Mengapa permintaan menunjukkan status ditagih ketika klien melaporkan error?

Ditagih berarti panggilan selesai dan menghabiskan kredit. Jika pengguna melaporkan error tetapi permintaan menunjukkan status ditagih, kegagalan kemungkinan besar terjadi di sisi klien setelah respons yang berhasil. Tandai kasus tersebut secara terpisah karena itu mengarah ke jalur perbaikan yang berbeda daripada permintaan yang gagal atau dikembalikan dananya.

Apa yang diberitahukan oleh cache miss kepada saya di inspektur?

Cache miss berarti permintaan tidak mencapai cache prompt. Itu penting untuk biaya dan latensi. Miss di mana Anda mengharapkan hit biasanya berarti awalan prompt berubah, bahkan secara halus. Periksa stempel waktu, bidang yang diurutkan ulang, atau karakter spasi tambahan.

Bisakah saya membagikan tautan permintaan dengan rekan tim?

Ya, jika izin keanggotaan dashboard mereka mengizinkannya. Data permintaan dibatasi pada organisasi Anda. Gunakan format deep-link /dashboard/api?tab=requestConsole&requestId=<request_id> untuk membuka inspektur secara langsung. Rekan tim melihat apa yang diizinkan oleh peran mereka.

Kapan saya harus beralih dari konsol ke ekspor penggunaan?

Beralihlah ketika masalahnya adalah pola, bukan kejadian satu kali. Satu permintaan yang gagal adalah masalah konsol. Sepuluh permintaan yang gagal selama satu jam adalah pola yang layak diekspor dan ditinjau secara agregat. Gunakan ekspor untuk pengeluaran dalam rentang waktu tertentu, rincian berdasarkan model atau kunci, dan rekonsiliasi bulanan.

Sumber dan Kebaruan

• TokenLab Request Console — /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 Dashboard TokenLab — /blog/tokenlab-dashboard-usage-exports — diamati 2026-07-09
• Direktori model publik TokenLab — /models — diamati 2026-07-09
• Dashboard API key TokenLab — /dashboard/api — diamati 2026-07-09

Contoh model yang dirujuk (Claude Sonnet 5, DeepSeek V4 Pro, Gemini 3.5 Flash) mencerminkan SSOT model saat ini per 2026-09-19. Snapshot sumber untuk catatan konsol ini diamati pada 2026-07-09; tanggal SSOT model asli dalam sumber adalah 2026-07-07.

Langkah Selanjutnya

Jika Anda saat ini melakukan debugging kegagalan AI API dengan melakukan grep melalui log sisi klien dan melakukan referensi silang dengan dashboard penagihan terpisah, Request Console menghapus satu langkah dari loop tersebut. Konsol berada di /dashboard/api?tab=requestConsole. Dashboard API key ada di tokenlab.sh/dashboard/api. Bentuk permintaan/respons chat completions didokumentasikan di https://docs.tokenlab.sh/api-reference/chat/create-completion. Untuk tinjauan pengeluaran agregat, gunakan ekspor penggunaan. Untuk detail harga model dan jendela konteks, lihat direktori model. Buka konsol dan cari permintaan gagal terbaru berdasarkan ID.