Auto, TokenLab Verified, atau Official: Memilih Tier Pengiriman

Saat kami melihat rute yang tidak terduga, nama model bukanlah petunjuk yang berguna; delivery tier-lah petunjuknya. Rute yang melayani suatu permintaan dapat mengubah kelayakan harga meskipun model logisnya tetap sama. Ketidaksesuaian itulah alasan kami memperlakukan delivery tier sebagai keputusan perutean, bukan sebagai lencana kualitas. Hal ini penting ketika kelayakan harga dan perutean perlu dinyatakan secara eksplisit. Hal ini jauh kurang penting jika kebijakan default Anda sudah sesuai dengan tujuan risiko dan biaya Anda.

Poin Penting

• Permintaan dapat dilayani melalui rute official atau rute verified. Pilihan tersebut dicatat per permintaan sebagai resolvedDeliveryTier (verified atau official, bernilai null jika catatan dibuat sebelum fitur ini ada).
• auto adalah kebijakan default, bukan tipe rute ketiga. Kebijakan ini menyimpan jalur yang dapat dijangkau dan memperkirakan jumlah biaya maksimum yang mungkin dikenakan untuk permintaan tersebut sebelum pengiriman (dispatch).
• Pewarisan kebijakan Workspace dan API-key adalah pengaturan yang normal. Pada pembacaan produksi tanggal 2026-09-11, 5.536 workspace memiliki kebijakan Auto eksplisit, 217 mewarisi default sistem, dan semua 4.134 API key mewarisi dari workspace mereka. Pembacaan di akhir minggu yang sama menunjukkan 219 yang mewarisi. Jumlah eksplisit tetap stabil karena workspace yang mewarisi tersebut adalah akun yang baru dibuat dan belum menetapkan kebijakan. Angka-angka ini berasal dari pembacaan peluncuran TokenLab 2.0 yang dicatat dalam catatan latihan rilis internal, yang diamati pada 2026-09-11; perlakukan ini sebagai pembacaan produksi internal, bukan tolok ukur publik.
• Kelayakan harga Official memerlukan kecocokan rute Official yang tepat. Delivery Verified tetap tersedia jika tidak ada rute Official yang cocok.
• Anda dapat mengganti pilihan delivery per permintaan dengan header X-TokenLab-Delivery-Policy. Default workspace mencakup kasus umum.

Apa sebenarnya tiga pilihan delivery tier tersebut

Channel menyatakan delivery tier sebagai VERIFIED dan OFFICIAL. Hanya channel dengan delivery tier publik aktif yang dapat diikat ke pengikatan model organisasi (organization model binding). Sebuah workspace dapat mengikat model logis ke channel tertentu. Pengikatan tersebut ditolak kecuali channel tersebut aktif, tidak dihapus, dan menyatakan delivery tier publik yang aktif. Rute untuk model pada channel tersebut juga harus diaktifkan.

Official berarti rute dilayani oleh jalur penyedia resmi, sedangkan Verified berarti jalur yang diverifikasi oleh TokenLab. Auto adalah kebijakan yang memungkinkan router memilih di antara rute yang dapat dijangkau; ketika kami memeriksa permintaan setelah pengiriman, resolvedDeliveryTier memberi tahu kami apakah verified atau official yang melayaninya. Bidang tersebut bernilai null jika catatan dibuat sebelum fitur ini ada.

Apa yang berubah saat Anda memilih delivery tier

Memilih tier akan mengubah kelayakan harga, catatan per permintaan, dan estimasi yang Anda lihat sebelum pengiriman. Harga dapat disesuaikan per delivery tier melalui aturan penyesuaian harga delivery tingkat organisasi, dan penyesuaian tersebut dinormalisasi serta divalidasi sebelum diterapkan. Setelah peluncuran, pilihan Verified atau Official yang eksplisit akan terus berlaku, sementara permintaan yang dibuat sebelum kebijakan ini akan menggunakan default Auto.

Auto memperkirakan jumlah maksimum untuk permintaan tersebut, bukan harga tunggal. Lebih dari satu rute mungkin dapat dijangkau, tetapi Auto menyimpan setiap rute yang dapat dijangkau dan tidak membuang rute yang lebih mahal agar estimasi terlihat lebih rendah. Dalam pipeline kami, kami memeriksa estimasi sebelum pengiriman dan resolvedDeliveryTier setelah selesai.

Opsi	Apa yang dioptimalkan	Kapan memilihnya	Apa yang dapat Anda verifikasi setelahnya
Auto	Rute yang dapat dijangkau dan estimasi biaya maksimum	Anda ingin kebijakan default memilih di antara rute yang dapat dijangkau	resolvedDeliveryTier menunjukkan rute yang melayani permintaan
TokenLab Verified	Akses ke jalur yang diverifikasi TokenLab saat Official tidak tersedia atau tidak diperlukan	Anda memerlukan rute terverifikasi, atau tidak ada rute Official yang cocok	resolvedDeliveryTier menunjukkan verified
Official	Kecocokan rute Official yang tepat untuk kelayakan harga official	Anda memerlukan kelayakan harga official	resolvedDeliveryTier menunjukkan official

Bagaimana tim biasanya mengonfigurasi kebijakan delivery tier

Angka pembacaan di bagian ini berasal dari pembacaan peluncuran TokenLab 2.0 yang dicatat dalam catatan latihan rilis internal, yang diamati pada 2026-09-11; perlakukan ini sebagai pembacaan produksi internal, bukan tolok ukur publik.

Pengaturan default adalah pewarisan, bukan prosedur per permintaan. Pada pembacaan produksi 2026-09-11, kami melihat 5.536 workspace dengan kebijakan Auto eksplisit, sementara 217 lainnya mewarisi default sistem. Semua 4.134 API key mewarisi dari workspace mereka, sehingga klien lama tidak memerlukan header baru. Pola tersebut masuk akal karena kebijakan workspace mencakup kasus umum, dan penggantian (override) per permintaan tetap menjadi pengecualian.

Pembacaan di akhir minggu yang sama menunjukkan 5.536 eksplisit dan 219 mewarisi, sementara jumlah eksplisit tetap stabil dan jumlah pewarisan berpindah dari 217 ke 219. Workspace yang mewarisi tersebut adalah akun yang baru dibuat yang belum menetapkan kebijakan, jadi jumlah ini berubah seiring dengan dibuatnya akun. Menetapkan kebijakan bukanlah sebuah migrasi, tidak ada pengisian ulang (backfill) massal kebijakan workspace atau kunci saat peluncuran, dan kunci yang mewarisi tidak memerlukan perubahan klien.

Aturan pengikatan tetap berlaku saat workspace mengikat model logis ke channel tertentu. Pengikatan ditolak kecuali channel tersebut aktif, tidak dihapus, dan menyatakan delivery tier publik yang aktif. Rute yang diaktifkan untuk model pada channel tersebut juga harus ada. Sebuah channel hanya dapat diikat ke pengikatan model organisasi selama deklarasi Registry-nya ACTIVE dan catatannya sendiri ACTIVE tanpa stempel waktu penghapusan, sehingga channel yang dijeda atau dipensiunkan tidak dapat disematkan (pinned).

Menyematkan model logis ke channel tertentu adalah cara workspace menyatakan selalu Official untuk model ini tanpa menyentuh permintaan individu. Permintaan yang dibuat sebelum kebijakan delivery menggunakan default Auto. Tidak ada perubahan klien yang diperlukan, dan tidak ada pengisian ulang massal kebijakan workspace atau kunci yang dilakukan saat peluncuran. Untuk konteks tingkat model, pasangkan ini dengan panduan pusat data model.

Cara memeriksa delivery tier mana yang melayani permintaan

Saat permintaan selesai, baca resolvedDeliveryTier dalam catatan permintaan; nilainya adalah verified atau official, dan nilai null berarti catatan dibuat sebelum bidang ini ada. Permintaan juga membawa requestedDeliveryPolicy, yang mencatat apa yang diminta oleh pemanggil dan dapat bernilai null saat default workspace diterapkan.

Untuk mengganti tier untuk satu permintaan, tambahkan header X-TokenLab-Delivery-Policy; nilai yang diterima adalah auto, verified, dan official. Berikut adalah header-nya:

# Tambahkan header ini ke permintaan Claude Sonnet 5
X-TokenLab-Delivery-Policy: verified

Sebagai contoh, panggilan cURL ini menargetkan Claude Sonnet 5 dan meminta official:

curl https://api.tokenlab.sh/v1/chat/completions -H "Authorization: Bearer $TOKENLAB_API_KEY" -H "Content-Type: application/json" -H "X-TokenLab-Delivery-Policy: official" -d '{"model":"Claude Sonnet 5","messages":[{"role":"user","content":"Hello"}]}'

Setelah panggilan, catatan permintaan untuk panggilan tersebut membawa:

{
  "requestedDeliveryPolicy": "official",
  "resolvedDeliveryTier": "official"
}

Catatan permintaan juga menyertakan bidang penggunaan, dan panduan Request Console menunjukkan di mana catatan tersebut berada dan nama bidang saat ini untuk penggunaan.

Jika tier yang diminta tidak memiliki rute yang diaktifkan, gateway menjawab dengan delivery_tier_unavailable dan tidak secara diam-diam beralih ke tier lain. Konsol permintaan menunjukkan di mana catatan tersebut berada, dan panduan Request Console menjelaskan cara menemukannya. Kami mulai dari sana ketika harga atau rute terlihat tidak terduga, karena konsol dan bukti permintaan dapat menunjukkan tier mana yang melayani lalu lintas tersebut.

Saat Auto memilih delivery tier yang tidak Anda duga

Saat Auto memilih tier yang tidak Anda duga, baca resolvedDeliveryTier pada permintaan dan bandingkan dengan channel yang telah diikat oleh organisasi Anda. Kemudian, ikat model ke channel yang Anda inginkan atau ganti tier untuk permintaan tersebut. Ini menjaga kebijakan default tetap sederhana sekaligus memberi Anda cara konkret untuk memperbaiki rute yang mengejutkan.

Batasan

Angka-angka di sini adalah pembacaan titik waktu dari 2026-09-11, dan angka tersebut akan berubah. Ketersediaan delivery tier bergantung pada rute mana yang aktif untuk model dan organisasi Anda. Pengikatan workspace dapat ditolak jika channel tidak aktif, dihapus, tidak memiliki delivery tier publik yang aktif, atau tidak memiliki rute yang diaktifkan untuk model tersebut. Penyesuaian harga per delivery tier bergantung pada aturan organisasi Anda sendiri. Kami tidak dapat memberikan perbandingan universal karena data sumber tidak menyediakannya. Keputusan delivery diselesaikan setelah pemilihan rute, jadi tier yang Anda dapatkan bergantung pada rute mana yang diaktifkan untuk organisasi Anda pada saat itu.

FAQ

Apa yang sebenarnya dipilih oleh Auto?

Auto adalah kebijakan default, bukan tipe rute ketiga. Kebijakan ini menyimpan jalur yang dapat dijangkau dan memperkirakan jumlah biaya maksimum yang mungkin dikenakan untuk permintaan tersebut sebelum pengiriman. Permintaan yang dibuat sebelum kebijakan ini menggunakan default Auto. Setelah pengiriman, resolvedDeliveryTier mencatat apakah permintaan dilayani melalui rute verified atau official.

Mengapa rute Verified bisa lebih mahal daripada rute Official?

Harga dapat disesuaikan per delivery tier melalui aturan penyesuaian harga delivery tingkat organisasi. Penyesuaian tersebut dinormalisasi dan divalidasi sebelum diterapkan. Jadi perbedaannya bergantung pada konfigurasi Anda, dan Anda harus memeriksa harga yang ditampilkan sebelum pengiriman.

Apakah saya harus menetapkan delivery tier pada setiap permintaan?

Tidak. Pewarisan kebijakan Workspace dan API-key adalah pengaturan yang normal. Pada pembacaan produksi 2026-09-11, 5.536 workspace memiliki kebijakan Auto eksplisit, 217 mewarisi default sistem, dan semua 4.134 API key mewarisi dari workspace mereka. Jumlah pewarisan berpindah ke 219 di akhir minggu tersebut seiring dengan dibuatnya akun baru. Angka-angka ini berasal dari pembacaan peluncuran TokenLab 2.0 yang dicatat dalam catatan latihan rilis internal, yang diamati pada 2026-09-11; perlakukan ini sebagai pembacaan produksi internal, bukan tolok ukur publik. Anda dapat mengganti pilihan delivery per permintaan, tetapi default workspace mencakup kasus umum.

Bagaimana saya tahu tier mana yang melayani permintaan yang sudah selesai?

Baca resolvedDeliveryTier dalam catatan permintaan. Nilainya adalah verified atau official, dan bernilai null jika catatan dibuat sebelum bidang ini ada. requestedDeliveryPolicy menunjukkan apa yang diminta oleh pemanggil, dan dapat bernilai null saat default workspace diterapkan. Konsol permintaan dan panduan Request Console menunjukkan di mana catatan tersebut berada.

Apa yang terjadi jika saya meminta tier tanpa rute yang diaktifkan?

Gateway menjawab dengan delivery_tier_unavailable. Gateway tidak secara diam-diam beralih ke tier lain. Baca catatan permintaan, lalu aktifkan rute yang cocok atau ubah kebijakan yang diminta.

Buat API key dan bandingkan tier yang Anda dapatkan dengan tier yang Anda harapkan; panduan Request Console menunjukkan di mana catatan tersebut berada.