Satu Konsol untuk Coding dan Aplikasi AI: Apa yang Berubah dan Cara Menggunakannya

TokenLab Console tidak lagi terasa seperti dasbor bagi kami setelah mode asisten coding dan mode aplikasi AI digabungkan menjadi satu antarmuka kerja. Dalam pipeline kami, permintaan, balasan, dan status akun di sekitarnya kini berada di tempat yang sama. Hal ini menghilangkan perpindahan konteks dari setiap sesi, dan mengubah cara kami membaca balasan yang lambat.

Poin Utama

• Mode asisten coding dan mode aplikasi AI kini keduanya ada di TokenLab Console; dua titik masuk lama telah digabungkan ke dalamnya.
• Tautan yang ada masih berfungsi, dan percakapan sebelumnya masih tersimpan. Tidak ada yang perlu dimigrasikan secara manual.
• Balasan melakukan streaming saat model menghasilkannya, alih-alih muncul hanya di akhir. Antarmuka menampilkan waktu token pertama.
• Latensi token pertama adalah sinyal permintaan yang dicatat (ttft_ms di log permintaan), bukan sekadar dekorasi antarmuka.
• Saat saldo menipis di tengah percakapan, entri pengisian saldo tersedia di sebelah percakapan, bukan di halaman penagihan terpisah.
• Pilihan model di Konsol mengikuti katalog publik; periksa direktori model untuk opsi saat ini. Contoh katalog saat ini mencakup Claude Sonnet 5 dan DeepSeek V4 Pro.

Apa yang berubah di TokenLab Console, dan apa yang tidak

Perubahan ini dirilis sebagai dua entri log perubahan. Konvergensi Konsol (2026-08-04) memindahkan dua titik masuk lama menjadi satu Konsol. Streaming obrolan Konsol (2026-08-18) menambahkan streaming ke obrolan. Kedua perubahan tersebut hadir berselang satu bulan, sehingga tim yang melewatkan entri pertama tetap mendapatkan entri kedua secara gratis.

Ini adalah perubahan antarmuka, bukan perubahan perilaku. Panggilan model, kunci, dan penagihan tidak berubah. Tautan lama tetap berfungsi, dan percakapan yang ada dipertahankan selama penggabungan. Tidak ada langkah migrasi manual.

Langkah konvergensi berkaitan dengan titik masuk, bukan akses model. Langkah streaming berkaitan dengan bagaimana balasan muncul, bukan token apa yang ditagih. Hal ini penting karena perubahan antarmuka produk bisa menyembunyikan perubahan perilaku, dan yang satu ini tidak melakukannya. Mode asisten coding dan mode aplikasi AI kini berbagi satu tempat, sehingga keputusan pertama dalam sebuah sesi tidak lagi tentang titik masuk mana yang harus dibuka.

Jika tim Anda memiliki runbook yang mengarah ke titik masuk lama, perbarui labelnya jika memungkinkan. Tautan lama masih berfungsi, jadi runbook tidak akan rusak. Konsol adalah tempat untuk ditandai (bookmark) untuk pekerjaan baru. Saat Anda memilih model dalam mode apa pun, pilihan tersebut mengikuti katalog publik, jadi periksa direktori model. Contoh katalog saat ini mencakup Claude Sonnet 5 dan DeepSeek V4 Pro.

Streaming di TokenLab Console mengubah cara Anda membaca sesi

Streaming mengubah momen saat Anda mengetahui sesuatu sedang terjadi. Dalam pipeline kami, klien gateway Konsol membangun permintaan obrolan streaming, dan balasan dirender secara bertahap. Antarmuka menampilkan waktu token pertama, sehingga Anda dapat melihat kapan model mulai menjawab. Konsol juga mencatat sinyal tersebut sebagai ttft_ms, kolom opsional di log permintaan.

Waktu token pertama memberi tahu Anda kapan token pertama tiba, sementara latensi total memberi tahu Anda kapan seluruh balasan selesai. Itu adalah pertanyaan yang berbeda, jadi jika balasan terasa lambat, periksa ttft_ms terlebih dahulu. Jika token pertama lambat, penantian terjadi sebelum pembuatan. Jika token pertama cepat dan balasan terasa lambat, penantian terjadi di sisa streaming.

Saat kami memantau sesi yang lambat, kami membandingkan ttft_ms dengan bukti permintaan lainnya alih-alih menebak dari indikator pemuatan (spinner). Bukti tingkat permintaan dicakup ke organisasi dan mencakup perutean, status penagihan, status cache, serta konteks model dan kunci di balik permintaan. Konsol menampilkan catatan permintaan yang sama yang biasanya Anda cari di log.

Contoh cara membaca sinyal token pertama:

# Log permintaan Konsol menampilkan `ttft_ms` sebagai kolom opsional.
# 1. Filter log permintaan ke permintaan yang sedang Anda periksa.
# 2. Baca `ttft_ms`.
# 3. Bandingkan `ttft_ms` dengan latensi total permintaan di baris yang sama.

Untuk bentuk permintaan streaming yang tepat, gunakan dokumen API TokenLab saat ini. Contoh permintaan yang disalin dengan kolom buatan akan kurang berguna dibandingkan halaman dokumen yang memiliki nama-nama tersebut.

Streaming tidak mengubah apa yang Anda bayar, karena token yang sama diproduksi tetapi terlihat saat tiba. Karena balasan kini melakukan streaming, sesi yang terputus tetap menampilkan balasan parsial alih-alih tidak ada sama sekali. Hal itu mengubah cara Anda mendiagnosis kegagalan di tengah sesi. Untuk pekerjaan yang berjalan lama yang tidak dicakup oleh streaming obrolan, lihat panduan tugas pembuatan gambar asinkron.

Cara memverifikasi sesi yang lambat tanpa menebak-nebak

Mulailah dengan log permintaan, bukan spinner, karena kolom ttft_ms memberi tahu Anda kapan token pertama tiba. Jika angka tersebut tinggi, model belum mulai menjawab. Jika angka tersebut rendah, model mulai lebih awal dan sisa streaming memakan waktu. Pemisahan itu mencegah Anda menyalahkan bagian jalur yang salah.

Catatan permintaan dicakup ke organisasi Anda. Ini mencakup rute yang melayani permintaan, status penagihan, status cache, serta konteks model dan kunci. Bidang-bidang tersebut berada di tempat yang sama, sehingga Anda dapat membaca sesi sebagai satu peristiwa alih-alih menyatukan halaman yang terpisah. Catatan permintaan yang sama tersedia di dasbor, yang membantu saat membandingkan tampilan Konsol dengan data tingkat akun. Panduan Request Console menjelaskan di mana bukti tersebut berada.

Misalnya, jika token pertama cepat dan balasan terasa lambat, ttft_ms bukanlah sinyal utama, karena sisa streaming-lah penyebabnya. Anda dapat melihat rute dan status cache dalam catatan permintaan yang sama. Anda dapat memeriksa apakah permintaan mencapai cache atau masuk ke model. Anda dapat melihat kunci dan konteks model mana yang dilampirkan.

Tidak satu pun dari hal tersebut menceritakan keseluruhan cerita dengan sendirinya, tetapi bersama-sama mereka memberi Anda tempat untuk mencari. Saat kami memantau sesi yang lambat, log permintaan memiliki detail yang kami butuhkan. Kami membandingkan ttft_ms dengan bukti tingkat permintaan lainnya sebelum menarik kesimpulan.

Alur kerja yang sama membantu saat permintaan gagal atau berhenti karena saldo. Catatan permintaan mencakup status penagihan, sehingga kegagalan bukanlah misteri. Entri pengisian saldo ada di sebelah percakapan, sehingga perbaikan tetap berada di jendela yang sama. Anda tidak perlu meninggalkan sesi untuk menemukan langkah selanjutnya, sehingga Anda dapat mengisi saldo lalu melanjutkan.

Jika saldo baik-baik saja, Anda dapat beralih ke perutean, status cache, atau pilihan model. Intinya adalah membaca bukti tingkat permintaan secara berurutan. Pertama, tanyakan kapan token pertama tiba, lalu tanyakan rute mana yang melayaninya, dan kemudian tanyakan apa lagi yang dikatakan catatan tentang penagihan, cache, model, dan konteks kunci. Urutan itu sederhana, dan cocok dengan cara Konsol menyajikan data.

Batasan

Streaming menunjukkan kemajuan, bukan throughput, karena streaming dapat dimulai dengan cepat namun tetap membutuhkan waktu lama untuk selesai. Token pertama yang cepat tidak membuktikan bahwa seluruh permintaan cepat. Waktu token pertama juga bergantung pada model dan rute. Bandingkan dalam model yang sama, bukan lintas model.

Perubahan pada ttft_ms mungkin mencerminkan perutean, status cache, atau pilihan model, bukan hanya prompt. Perlakukan ttft_ms sebagai satu sinyal di log permintaan. Pasangkan dengan bukti tingkat permintaan lainnya sebelum Anda menarik kesimpulan. Ini adalah antarmuka untuk membaca sesi, bukan tolok ukur untuk memeringkat model.

Konsol tidak mengubah streaming obrolan menjadi penjalan tugas (job runner). Jika Anda memiliki tugas gambar yang berjalan lama, gunakan panduan tugas pembuatan gambar asinkron alih-alih membiarkan streaming obrolan terbuka. Antarmuka streaming ditujukan untuk balasan yang tiba token demi token. Panduan asinkron ditujukan untuk pekerjaan yang berjalan di luar balasan obrolan.

Ingat juga bahwa bukti tingkat permintaan dicakup ke organisasi, yang mengaitkan permintaan dengan konteks akun di sekitarnya. Ini juga berarti Anda tidak boleh memperlakukan satu permintaan sebagai tolok ukur global. Catatan tersebut mencakup perutean, status penagihan, status cache, serta konteks model dan kunci untuk permintaan tersebut. Ini adalah tempat yang kuat untuk memulai diagnosis. Ini bukan peringkat penyedia atau model. Saat kami membandingkan sesi, kami membandingkan dalam model yang sama dan keluarga rute yang sama, yang menjaga perbandingan tetap jujur.

FAQ

Apakah tautan Konsol lama saya masih berfungsi?

Ya. Tautan lama tetap berfungsi, dan percakapan yang ada dipertahankan selama penggabungan. Tidak ada yang perlu dimigrasikan secara manual. Jika Anda menandai halaman Konsol, tautan tersebut masih berfungsi.

Apa yang sebenarnya diukur oleh waktu token pertama?

Ini mengukur kapan token pertama tiba dalam balasan streaming, dan Konsol menampilkannya di antarmuka serta mencatatnya sebagai ttft_ms, kolom opsional di log permintaan. Ini tidak mengukur latensi total atau throughput.

Di mana saya mengisi saldo saat percakapan kehabisan saldo?

Gunakan entri pengisian saldo di sebelah percakapan, yang muncul saat saldo menipis di tengah percakapan, sehingga Anda dapat menangani saldo tanpa meninggalkan sesi. Halaman penagihan di dasbor tetap menjadi tempat untuk pekerjaan akun yang lebih luas.

Bisakah saya membandingkan waktu token pertama di berbagai model?

Tidak, bukan sebagai perbandingan yang bersih. Waktu token pertama bergantung pada model dan rute, jadi bandingkan dalam model yang sama, bukan lintas model. Gunakan ttft_ms sebagai satu sinyal tingkat permintaan, bukan peringkat model.

Buat kunci API dan jalankan satu sesi di Konsol baru di dasbor.