RLCD Dijelaskan: Mengapa TypeSafe Melatih Jev agar Jujur Tentang Keyakinan, Bukan Agar Disukai

Jev 1.13 (typesafe/jev-1.13) dilatih dengan metode yang oleh pembuatnya disebut Reinforcement Learning for Calibrated Decisions — RLCD — dan akronim itu adalah istilah ciptaan TypeSafe sendiri, bukan istilah industri yang seharusnya sudah Anda ketahui. Pos peluncurannya mengatakan hal itu secara gamblang: perusahaan membangun "arsitektur model baru, sampler paralel untuk efisiensi maksimum, dan metode pelatihan yang kami sebut Reinforcement Learning for Calibrated Decisions (RLCD)". Ini adalah jawaban ketiga untuk pertanyaan yang dulu punya dua jawaban, dan alasan keberadaannya adalah ketidakcocokan yang sering dialami banyak tim saat pertama kali mencoba menempatkan model bahasa di dalam sebuah keputusan. Sebelum membahasnya, dua tanggal itu penting, karena halaman ini bukan tulisan peluncuran. TypeSafe merilis model itu sendiri pada 2026-09-15, yang berada di luar jendela tujuh hari yang menjadi cakupan blog ini, dan tidak ada apa pun di sini yang boleh dibaca sebagai membingkai Jev sebagai hal baru. Peristiwa bertanggalnya adalah 2026-09-24, ketika OrcaRouter menambahkan typesafe/jev-1.13 ke katalognya sendiri dan membuka kartu model untuknya — pertama kalinya Jev dapat dipanggil melalui gateway pihak ketiga, bukan hanya melalui endpoint milik TypeSafe sendiri. Itulah perubahan yang menjadi dasar halaman ini, dan konsekuensi praktisnya adalah teknik di bawah ini kini menjadi sesuatu yang dapat Anda coba dalam kode dengan kunci yang mungkin sudah Anda miliki, bukan sekadar gagasan riset yang Anda baca.

Yang berikut adalah konsep, bukan model. Sepertiga pertama halaman ini membahas dua metode pelatihan yang menjadi sasaran rancangan RLCD, karena RLCD hanya dapat dipahami sebagai perbaikan atas apa yang dilakukan kedua metode itu ketika tugas berhenti menjadi percakapan dan berubah menjadi penilaian. Jika Anda sudah tahu apa yang dioptimalkan RLHF dan RLVR, bagian yang Anda cari adalah bagian ketiga, tempat tabel tiga arah milik TypeSafe sendiri yang melakukan tugasnya.

RLHF mengoptimalkan untuk jawaban yang disukai seseorang

Pembelajaran penguatan dari umpan balik manusia adalah metode yang mengubah model bahasa yang telah dilatih sebelumnya menjadi asisten. Dokumen pengantar milik TypeSafe sendiri menyatakan objektifnya secara gamblang, dalam kartu berjudul RLHF: metode itu "mengubah model yang telah dilatih sebelumnya menjadi chatbot. Metode ini melatih model untuk menghasilkan respons yang disukai orang." InstructGPT dan ... dilatih dengannya, dan dokumen pengantar itu menambahkan detail yang relevan di sini karena alasan yang berbeda — pendekatan ini ikut diciptakan oleh Diogo Almeida, yang merupakan salah satu pendiri TypeSafe dan penulis postingan peluncuran Jev. Perusahaan ini tidak mengabaikan metode itu. Perusahaan ini didirikan oleh seseorang yang membantu membangunnya. Perusahaan ini berargumen bahwa objektifnya salah untuk pekerjaan tertentu.

Cara yang jelas untuk melihat ketidakcocokan itu adalah dengan bertanya apa yang sebenarnya diukur oleh sinyal imbalan. Dalam RLHF, sinyal itu mengukur preferensi seorang penilai antara dua respons kandidat. Itu adalah proksi yang sangat baik ketika produknya adalah percakapan, karena kriteria keberhasilan sebuah percakapan memang adalah apakah seseorang menilai balasan itu bagus. Itu adalah proksi yang rusak ketika produknya adalah keputusan, karena kriteria keberhasilan di sana adalah apakah keyakinan yang dinyatakan sesuai dengan kenyataan, dan seorang penilai yang membandingkan dua paragraf yang masuk akal tidak punya cara untuk melihat perbedaan antara 0,6 yang terkalibrasi baik dan 0,95 yang terdengar yakin. Dua jawaban bisa sama-sama disukai namun sangat berbeda dalam seberapa besar sebuah perangkat lunak harus mempercayainya.

Mode kegagalan yang disebut TypeSafe dalam primer itu mengikuti langsung dari hal tersebut:

• Sikofansi — model belajar menghasilkan apa yang ingin didengar oleh penilai, yang merupakan sasaran berbeda dari apa yang benar.

• Halusinasi yang terdengar percaya diri — kelancaran dan kepastian diberi imbalan oleh preferensi bahkan ketika keduanya tidak didukung oleh apa pun.

• Mode dropping — optimasi preferensi mempersempit distribusi keluaran, "mengutamakan gaya tertentu, seperti mengikuti instruksi, sekaligus menurunkan probabilitas keluaran lain yang mungkin." Mode dropping adalah versi ringan dari kegagalan mode-collapse klasik yang menghantui jaringan adversarial generatif, di mana generator konvergen pada satu keluaran yang terus menipu diskriminator.

Paragraf peringatan dari buku pengantar itu sendiri adalah kalimat yang layak dipertahankan: "Sebuah keluaran bisa sangat menarik bagi seseorang tanpa cukup andal untuk otomatisasi tanpa pengawasan. Preferensi manusia dan keterpercayaan mesin adalah target optimisasi yang berbeda." Itu bukan kritik terhadap RLHF sebagai metode. Itu adalah pengamatan bahwa model yang dilatih dengan preferensi belum pernah ditanyai pertanyaan yang perlu dijawab oleh otomatisasi — seberapa sering, tepatnya, hal ini benar ketika ia mengatakan dirinya yakin.

RLVR mengoptimalkan keluaran yang dapat diperiksa oleh program — dan keputusan jarang memilikinya

Pembelajaran penguatan dengan imbalan yang dapat diverifikasi adalah adaptasi kedua, dan itulah yang berada di balik model-model penalaran. Panduan dasar TypeSafe menjelaskan apa yang dihasilkannya: model yang "kuat dalam tugas-tugas seperti matematika, tetapi lebih lambat dan lebih mahal." Mekanismenya adalah sebuah pemeriksa. Jika suatu tugas memiliki jawaban yang dapat diuji oleh program — uji unit, pemeriksa bukti, jawaban numerik — maka imbalan dapat dihitung tanpa menanyakan apa pun kepada manusia, dan model dapat dilatih terhadap sinyal itu dalam skala besar. Ini berhasil, dan inilah sebabnya model penalaran menjadi baik tepat pada domain tempat verifikasi otomatis yang murah tersedia.

Keterbatasannya adalah bentuk dari kata "verifiable" itu. Imbalan yang dapat diverifikasi memerlukan verifikator, dan verifikator memerlukan bahwa tugas tersebut memiliki jawaban benar yang dapat dihitung oleh seseorang. Pertimbangkan pertanyaan-pertanyaan yang benar-benar diajukan oleh sistem produksi. Haruskah tiket dukungan ini masuk ke bagian penagihan atau ke bagian teknis? Apakah permintaan pengembalian dana ini sesuai kebijakan? Apakah transaksi ini tampak seperti penipuan? Masing-masing memiliki jawaban yang dapat dipertahankan sebagian besar waktu, tidak ada yang memiliki jawaban yang dapat diperiksa oleh program, dan kasus-kasus yang paling penting justru adalah kasus ketika manusia berpengalaman tidak sepakat. Tidak ada fungsi yang bisa dijalankan. RLVR tidak memiliki apa pun untuk diberi imbalan, jadi ia tidak memberikan kontribusi apa pun.

Solusi sementara yang menggoda adalah membuat pemverifikasi dengan memberi label pada kumpulan data dan melatih model terhadap label tersebut. Itu memberi metode ini sesuatu untuk diolah, tetapi mengubah fungsi objektifnya dengan cara yang penting. Label menyandikan sebuah keputusan, bukan ketidakpastian di sekitarnya. Model yang dilatih untuk mereproduksi penilaian satu tim pada kasus-kasus sulit akan belajar untuk memiliki tingkat keyakinan yang sama seperti label-label itu — yang berarti, sama terlalu percaya dirinya dengan manusia yang menulisnya. Dan bahkan ketika pemverifikasi yang sebenarnya memang ada, masih ada celah kedua. Pemverifikasi menilai jawabannya. Ia tidak menilai tingkat keyakinan yang dinyatakan. Model yang benar pada 95% kasus dan melaporkan kepastian pada semuanya memperoleh imbalan sempurna dan, sebagai komponen dalam pipeline otomatis, tidak berguna — karena 5% itulah satu-satunya bagian yang perlu diberitahukan kepada pipeline. Materi peluncuran TypeSafe menyampaikan poin yang sama dari arah sebaliknya: "Jika sebuah model dapat mengerjakan suatu tugas 95% dari waktu tetapi tidak memberi tahu kapan ia berada di 5%, model itu tidak dapat mengotomatiskan tugas tersebut."

Apa yang dilakukan RLCD, dalam kerangka TypeSafe sendiri

RLCD mengubah kontrak keluaran, bukan kualitas jawaban. Kartu primer berbunyi: "Pembelajaran penguatan untuk keputusan terkalibrasi melatih TypeSafe untuk mengembalikan keputusan dan probabilitas terkalibrasi alih-alih teks yang dihasilkan." Versi ringkas dari pos peluncuran adalah "keputusan terkalibrasi: jawaban dengan probabilitas yang jujur secara epistemik pada tugas System One." Keduanya menjelaskan satu langkah: melatih model berdasarkan apakah probabilitas yang dinyatakannya cocok dengan frekuensi jawaban itu ternyata benar, bukan berdasarkan apakah seseorang atau pemeriksa menyukai jawaban itu.

Postingan peluncuran menempatkan ketiga metode secara berdampingan, dan kontrasnya adalah pernyataan gagasan yang paling jelas yang ada. Bacalah sebagai rangkaian kontras, bukan sebagai tabel:

• Apa yang dioptimalkannya — RLHF mengoptimalkan preferensi manusia, "tulisan dan respons obrolan yang disukai penilai manusia"; RLVR mengoptimalkan "output yang dapat diverifikasi secara terprogram"; RLCD mengoptimalkan kalibrasi, "jawaban dengan probabilitas yang jujur secara epistemis pada tugas System One."

• Apa yang masuk — dua yang lebih lama menerima data tidak terstruktur "dengan penekanan pada pesan berurutan"; model keputusan yang terkalibrasi menerima data tidak terstruktur "dengan penekanan pada status program yang terstruktur."

• Apa yang dihasilkan — string yang dihasilkan yang "perlu diurai + divalidasi," dengan "selalu ada risiko bahwa AI keluar jalur," dibandingkan nilai terstruktur yang type-safe di mana "kemungkinan output dan strukturnya ditentukan sebelumnya," model "tidak pernah membuat kesalahan tipe," dan "semua jawaban disertai probabilitas terkalibrasi dan skor keyakinan."

• Bagaimana ia disampel — satu token pada satu waktu, masing-masing dikondisikan pada token sebelumnya, dibandingkan dengan semua keluaran yang dihasilkan dalam satu kueri. Inilah alasan mekanis mengapa metode ketiga murah: tidak ada loop dekode yang harus dibayar.

• Berapa biayanya — token masukan dari $0,20 hingga $10 per juta untuk model pembanding, dengan keluaran sekitar lima kali harga masukan, dibandingkan dengan $0,042 per juta token masukan dengan biaya keluaran nol untuk Jev.

• Seberapa cepat ia menjawab — 3 hingga 329 detik secara end-to-end untuk model frontier, dibandingkan dengan 70ms hingga 500ms, yang oleh vendor digambarkan sebagai 40x hingga 200x lebih cepat pada kueri berbentuk System One.

• Apa yang dikatakannya tentang keyakinannya sendiri — dua yang lebih tua "cenderung terlalu percaya diri dan tidak konsisten" bahkan saat diminta memberikan perkiraan keyakinan; RLCD "selalu mengomunikasikan keyakinan dan ketidakpastian pada setiap keluaran," di mana "keyakinan yang lebih tinggi berarti akurasi yang lebih tinggi."

Baris terakhir adalah klaim produk yang sebenarnya, dan klaim itu dapat difalsifikasi dengan cara yang tidak dimiliki klaim-klaim lainnya. "Keyakinan yang lebih tinggi berarti akurasi yang lebih tinggi" adalah pernyataan tentang sebuah kurva: kelompokkan jawaban model berdasarkan probabilitas yang disertainya, dan kelompok-kelompok itu seharusnya benar pada tingkat yang kira-kira sesuai dengan yang diklaim oleh probabilitas tersebut. Dokumentasi keyakinan TypeSafe menjabarkan kontrak itu dengan angka-angka yang luar biasa konkret:

• Hasil yang diberi probabilitas 0,2 seharusnya terjadi sekitar 20% dari waktu.

• Hasil yang diberi probabilitas 0,8 seharusnya terjadi sekitar 80% dari waktu.

• Hasil yang diberi probabilitas 1,0 harus terjadi 100% dari waktu.

Dan kemudian kalimat yang menjaga klaim itu tetap jujur, dengan kata-kata vendor sendiri: "Tingkat-tingkat ini menggambarkan kelompok prediksi, bukan jaminan tentang jawaban tunggal mana pun." Itu bukan pernyataan berhati-hati yang ditempel karena alasan hukum. Itulah keseluruhan makna kalibrasi. Model yang terkalibrasi baik yang mengatakan 0,8 tidak menjanjikan akan benar kali ini; ia menjanjikan bahwa di antara setiap jawaban yang dilabelinya 0,8, sekitar empat dari lima benar. Satu jawaban tidak memberi tahu Anda apa pun. Seribu jawaban selama sepekan memberi tahu Anda apakah kurvanya nyata.

Kontras tiga kartu yang sama terdapat pada dokumentasi TypeSafe sendiri, yang menjadi sumber perbandingan di atas dan tempat paling jelas untuk memeriksa penulisannya daripada hanya memercayai ringkasan. Tangkapan layar di bawah adalah halaman itu sebagaimana adanya saat ini: tiga kartu untuk tiga pendekatan pasca-pelatihan, dengan kartu ketiga menyebutkan RLCD secara lengkap.

Dua detail lebih lanjut dalam dokumentasi vendor menunjukkan seberapa jauh metode ini menjangkau ke dalam produk. Yang pertama adalah bahwa keyakinan diturunkan, bukan dihasilkan: model mengembalikan distribusi probabilitas penuh di seluruh opsi atau level yang Anda berikan, dan nilai keyakinan adalah statistik yang dihitung dari bentuk distribusi tersebut. Itulah sebabnya dokumentasi dapat memberi tahu Anda bahwa definisi itu tidak menjadi penentu — Anda mendapatkan distribusi mentahnya dalam kedua kasus dan dapat menghitung statistik Anda sendiri jika milik Anda lebih cocok. Yang kedua adalah bahwa RLCD adalah satu-satunya hal yang membentuk bobot. Halaman model TypeSafe menyatakan: "Jev tidak di-fine-tune atau diadaptasi dengan LoRA menggunakan data pelanggan. Jev dilatih dengan RLCD untuk mengembalikan keputusan yang terkalibrasi, dan bobot yang sama melayani setiap akun." Adaptasi domain terjadi dalam permintaan — keadaan Anda, kriteria Anda — bukan dalam checkpoint per pelanggan. Kalibrasi apa pun yang dihasilkan metode tersebut adalah kalibrasi yang didapat setiap pelanggan.

Mengapa kalibrasi adalah hal yang membuat model keputusan murah dapat digunakan

Probabilitas terkalibrasi tidak menarik dengan sendirinya. Ia menjadi arsitektur pada saat kode Anda bercabang berdasarkan probabilitas itu, dan dokumentasi confidence TypeSafe menjelaskan persis pola tersebut sebagai tiga rentang, yang masing-masing menghasilkan perilaku sistem yang berbeda.

• Keyakinan tinggi — bertindak secara otomatis. Model memiliki pemahaman yang jelas dan Anda dapat melanjutkan tanpa keterlibatan manusia.

• Keyakinan sedang — lanjutkan dengan hati-hati. Model memiliki jawaban yang wajar tetapi tidak yakin, jadi Anda mengonfirmasi dengan pengguna, menandai untuk ditinjau, atau mengumpulkan lebih banyak informasi sebelum bertindak.

• Keyakinan rendah — jangan bertindak. Alihkan ke manusia, minta klarifikasi, atau gunakan sistem lain sebagai cadangan, karena model memberi tahu Anda bahwa ia tidak memiliki cukup informasi untuk melanjutkan.

Dokumentasi tersebut secara eksplisit menyatakan bahwa batas-batasnya adalah milik Anda untuk ditentukan dan harus berbeda menurut konsekuensinya: "Ambang keyakinan bukanlah satu angka. Tindakan yang berbeda dalam sistem yang sama harus dibatasi pada tingkat yang berbeda bergantung pada konsekuensi jika salah." Contoh terperinci mereka menetapkan batas bawah yang keras pada 0,5 — apa pun yang dilaporkan model di bawah itu dialihkan ke manusia tanpa pemeriksaan lebih lanjut — lalu menerapkan standar yang lebih tinggi untuk tindakan destruktif daripada untuk tindakan hanya-baca. Kode Anda mengodekan toleransi risiko; model memasok input yang jujur untuknya.

Pola itu adalah keseluruhan argumen untuk alur kerja dua model, dan layak dinyatakan sebagai argumen, bukan sebagai daftar fitur. Misalkan Anda ingin membangun pipeline otomatis yang menangani mayoritas kasus yang penuh keyakinan dan mengeskalasi sisanya ke model yang lebih besar atau ke manusia. Keputusan eskalasi harus berasal dari suatu tempat. Jika model murah melaporkan 0,98 untuk semuanya, termasuk kasus-kasus yang sebenarnya hanya diterka, maka percabangan itu tidak punya apa pun untuk diuji, dan Anda hanya punya dua pilihan: mengotomatiskan semuanya — termasuk panggilan yang seharusnya dieskalasi — atau tidak mengotomatiskan apa pun. Model yang tingkat keyakinannya informatif adalah satu-satunya jenis model yang memungkinkan Anda mengotomatiskan sebagian kasus dengan aman, karena hanya model seperti itulah yang dapat memberi tahu Anda pada bagian mana model itu tidak aman. Dokumentasinya merangkum poin yang sama dalam satu baris yang layak dikutip karena kelugasannya: "Jika sebuah sistem cerdas, baik manusia maupun mesin, tidak dapat menyatakan ketidakpastian secara jujur, sistem itu tidak dapat dipercaya."

Ada alasan kedua mengapa hal ini lebih penting bagi model murah daripada model mahal, dan itulah alasan cerita routing dan cerita RLCD adalah cerita yang sama. Model dengan harga $0,042 per juta token masukan tanpa biaya keluaran cukup murah untuk terus-menerus dikonsultasikan — pada setiap giliran loop agen, pada setiap catatan dalam batch, pada setiap tiket saat tiba. Dikonsultasikan terus-menerus justru merupakan situasi ketika kesalahan sebuah model menumpuk, karena tidak ada yang membaca keluarannya sebelum ditindaklanjuti. Keyakinanlah yang membuat hal itu aman. Murahnya adalah yang membuat cabang eskalasi terjangkau, karena jalur mahal hanya berjalan pada sebagian kasus yang ditolak model murah. Tak satu pun dari kedua bagian itu berfungsi tanpa yang lain, dan keputusan routing yang menyatukan keduanya adalah ambang batas pada sebuah angka yang RLCD menjadi alasan untuk mempercayainya.

Batas yang jujur: terkalibrasi bukan berarti benar

Hal terpenting yang harus dipahami dengan benar tentang RLCD adalah apa yang tidak diklaimnya. Kalibrasi adalah sifat dari tingkat keyakinan, bukan jaminan tentang jawaban, dan vendor mengatakannya dalam dokumentasinya sendiri alih-alih membiarkannya kepada para kritikus. Halaman System One: "Model System One dilatih untuk keputusan yang terkalibrasi: probabilitasnya dioptimalkan terhadap hasil untuk mencerminkan ketidakpastian. Kalibrasi diukur lintas kelompok prediksi; ini tidak menjamin bahwa jawaban individu itu benar." Sebuah model dapat terkalibrasi dengan sempurna dan tetap membuat keputusan yang salah atas tiket Anda, karena 0,9 berarti sembilan dari sepuluh, dan ini bisa jadi yang kesepuluh.

Angka serving kami sendiri adalah penyeimbang yang berguna di sini, justru karena angka-angka itu adalah pengukuran model di produksi, bukan klaim tentang apa yang dicapai metode tersebut. Selama tujuh hari yang berakhir pada 2026-09-30, pada lalu lintas melalui playground OrcaRouter sejak model ditambahkan ke katalog, kartu Jev 1.13 melaporkan tingkat kesalahan 0,49% pada 76,2 juta token, bersama dengan p50 waktu ke token pertama 151 ms, p95 247 ms, dan sekitar 349 token keluaran per detik. Ada dua hal tentang angka itu yang perlu dikatakan secara terang-terangan. Itu milik kami, bukan milik vendor, dan itu adalah jendela bergulir, bukan set uji tetap — bidang yang sama terbaca 0,57% lebih awal dalam jendela tersebut, karena dihitung ulang selama tujuh hari terakhir lalu lintas langsung dan panggilan kemarin keluar dari perhitungan. Ini juga bukan pengukuran kalibrasi. Tingkat kesalahan memberi tahu Anda seberapa sering sesuatu gagal pada lalu lintas kami; itu tidak memberi tahu Anda apakah nilai keyakinannya jujur, yang merupakan pertanyaan berbeda dan memerlukan data berlabel untuk menjawabnya.

Yang juga merupakan instruksi praktis yang diberikan vendor, dalam catatan yang dilampirkan pada panduan ambang batasnya: "Nilai ambang batas yang benar bergantung pada domain Anda dan performa model untuk kasus penggunaan Anda. Mulailah dengan ambang batas yang konservatif, uji dengan data Anda sendiri, dan sesuaikan saat Anda mengamati hasilnya." RLCD adalah klaim tentang bagaimana model dilatih. Apakah klaim tersebut berlaku pada input Anda adalah pertanyaan empiris, dan ini adalah salah satu dari sedikit properti model yang dapat Anda uji tanpa infrastruktur pembelajaran mesin apa pun — ambil beberapa ratus kasus yang sudah Anda miliki labelnya, kelompokkan jawaban berdasarkan keyakinan yang dilaporkan model, dan periksa apakah kelompok-kelompok tersebut benar pada tingkat yang mereka klaim. Jika kelompok 0,9 benar sekitar 90% dari waktu pada lalu lintas Anda, ambang batas itu nyata dan Anda dapat mengotomatiskan di atasnya. Jika semuanya mengelompok di atas 0,9 dan akurasinya tidak mengikuti, Anda telah mempelajari sesuatu yang lebih berguna daripada angka utama apa pun.

Ada dua batasan lain yang perlu disebut sekaligus. Pertama, tidak ada kartu benchmark publik untuk model ini yang bisa dijadikan acuan untuk memeriksa semua itu — vendor belum menerbitkannya, dan tidak ada papan peringkat pihak ketiga yang memuat model ini; halaman model Artificial Analysis untuknya mengembalikan 404 per 2026-09-30. Jadi argumen kalibrasinya bertumpu pada deskripsi pelatihan, kontrak yang didokumentasikan, dan apa pun yang Anda ukur sendiri, bukan pada kurva yang diterbitkan. Kedua, klaim performa vendor itu milik vendor sendiri: postingan peluncurannya secara terbuka mencatat bahwa evaluasi alur kerja di balik angka utama kecepatan dan biaya dibuat oleh tim kapabilitas model mereka, bahwa jawaban referensi yang dijadikan pembanding adalah rata-rata dari dua model eksternal, dan bahwa angkanya "di ujung atas dari peningkatan dunia nyata." Postingan itu juga menyatakan bahwa penetapan harganya tidak dapat dibuktikan bebas subsidi. Tidak ada satu pun dari itu yang meruntuhkan metode pelatihannya, yang merupakan klaim terpisah dari klaim kecepatan, tetapi itu berarti argumen untuk RLCD adalah argumen tentang desain objektif, bukan hasil empiris yang sudah mapan. Perlakukan ini sebagai hipotesis yang bisa Anda uji dengan murah, posisi yang lebih baik daripada yang ditinggalkan oleh sebagian besar klaim metode pelatihan.

Apa yang dapat Anda lakukan dengan ini hari ini

Kedua sisi argumen ini bertemu di satu titik. RLCD adalah alasan mengapa keyakinan sebuah model keputusan layak dijadikan dasar percabangan; ambang batas di dalam kode Anda adalah tempat percabangan itu berada; dan eskalasi hanya terjangkau jika jalur umum cukup murah untuk dijalankan di mana-mana. Jev 1.13 dapat dipanggil sebagai typesafe/jev-1.13 di OrcaRouter — satu API untuk 200+ model, markup 0%, harga daftar penyedia diteruskan apa adanya, sehingga pemotongan harga vendor langsung berlaku di sini pada hari yang sama — yang berarti jalur mayoritas-yakin dan jalur eskalasi generatif ditagih pada kunci yang sama alih-alih dua kontrak vendor. Anda tetap memanggilnya dalam bentuknya sendiri, POST /v1/systemone, non-streaming, terhadap konteks 65.536 token, karena itu bukan rute chat-completions OpenAI dan tidak dilipat ke dalam endpoint chat. Dua catatan bertanggal dari rilis SDK vendor perlu diketahui jika Anda sedang memasangnya: versi 0.7.1, dirilis 2026-09-21, menambahkan contoh penggunaan dengan gateway AI, dan versi 0.7.2, dirilis 2026-09-26, menambahkan ekstra http2 ke paket Python. Yang kedua adalah jenis detail yang hanya muncul di catatan rilis — klien HTTP/2 layak dimiliki untuk model yang seluruh proposisi nilainya adalah round trip di bawah 200 milidetik.

Jika Anda mengambil satu hal dari halaman ini, ambil bentuk pertanyaan yang dijawab RLCD. Bukan "dapatkah sebuah model menjadi lebih pintar." Melainkan "dapatkah sebuah model memberi tahu saya ketika ia tidak cukup pintar, cukup sering dan cukup akurat sehingga saya dapat mengotomatiskan sisanya." Itu adalah target penelitian yang berbeda dari dua target yang menjadi fokus bidang ini selama beberapa tahun terakhir, dan itu satu-satunya yang menghasilkan angka yang dapat ditindaklanjuti oleh kode Anda. Nilai keyakinan adalah angka itu. Ujilah pada label Anda sendiri sebelum Anda mempercayainya, dan mulailah dengan ambang batas yang akan membuat Anda malu jika salah, bukan ambang batas yang Anda ingin benar.

Satu bagian terakhir dari gambaran ini layak dibawa bersama semua itu, karena inilah angka yang menjadi sasaran seluruh argumen dan angka ini diukur, bukan diklaim. Kartu di bawah ini adalah catatan serving tujuh hari milik kami sendiri untuk typesafe/jev-1.13 — model yang berjalan di sistem, bukan metode pelatihan, dan bukan tolok ukur. Bacalah ini sebagai paruh kedua dari pertanyaan kalibrasi: tingkat keyakinan memberi tahu Anda panggilan mana yang perlu ditindaklanjuti, dan ini memberi tahu Anda seberapa dekat sisa keputusan perutean dengan sistem yang akan Anda biarkan tanpa pengawasan.