Gemini Decision vs Gemini Decision 1: Yang Satu Nama, yang Lain ID Model

Cari Gemini Decision dan Anda akan menemukan liputan peluncuran, entri papan peringkat, baris harga, dan referensi API, semuanya menggunakan kata yang sedikit berbeda untuk hal yang sama. Cari Gemini Decision 1 dan Anda akan menemukan id model yang benar-benar berfungsi. Kedua string tersebut berbeda satu karakter dan berperilaku sangat berbeda dalam kode: yang satu adalah sebutan orang untuk produk tersebut, dan yang lainnya adalah satu-satunya nilai yang akan diterima POST /v1beta/decisions. Jika Anda pernah menghabiskan sepanjang sore dengan 404 dan bertanya-tanya mengapa model yang jelas ada tidak dapat ditemukan, inilah artikel yang bisa menyelamatkan Anda.

Kebingungan ini bukan kesalahan siapa pun secara khusus. G​oogle merilis sebuah model, sebuah endpoint, dan sebuah nama keluarga dalam rilis yang sama pada 11 November 2026, dan cara alami untuk menulis tentang ketiganya adalah menyingkatnya. Penyingkatan itu berhasil dalam prosa dan gagal dalam body permintaan, dan celah antara kedua fakta tersebut adalah dari mana sebagian besar tiket dukungan dalam kategori ini akan berasal selama bulan depan.

Apa hasil resolusi kedua nama tersebut

Mulailah dengan pemetaan, karena segala hal lainnya mengikuti darinya.

• Gemini Decision — nama produk. Ini merujuk pada lini model keputusan, dan dalam dokumentasi Google sendiri nama ini muncul sebagai label keluarga dalam prosa, pada judul kartu model, dan dalam kalimat seperti "hanya tersedia dengan Gemini Decision". Ini bukan ID model, tidak ada alias di baliknya, dan melewatkannya sebagai model akan mengembalikan error model tidak dikenal alih-alih beralih ke anggota terbaru dari keluarga tersebut.

• Gemini Decision 1 — modelnya, dan id gemini-decision-1. Inilah nilai yang berfungsi. Ini adalah satu-satunya model yang dilayani oleh Decisions API, dan dokumentasinya menyatakan hal itu secara eksplisit: endpoint tersebut hanya tersedia dengan Gemini Decision 1.

Dua nama, satu model, dan tidak ada alias di antara keduanya. Bagian terakhir itulah yang tidak biasa. Sebagian besar keluarga model G​oogle menawarkan alias bergerak dan id yang dipin — bentuk -latest untuk prototipe dan bentuk bertanggal atau bernomor untuk produksi. Yang ini hanya menawarkan bentuk yang dipin, jadi jalur kode apa pun yang dibangun dengan asumsi bahwa keluarga memiliki kepala mengambang akan gagal di sini, bukan diam-diam melacak versi baru.

Di mana nama kedua terus muncul

Alasan ambiguitas ini tetap bertahan adalah karena tiga sistem terpisah mendeskripsikan model ini, dan tidak satu pun dari sistem tersebut menggunakan konvensi penamaan yang sama.

Halaman harga mencantumkannya dengan nama model itu sendiri, bersama tarif dan catatan bahwa output tidak berlaku. Referensi API menjelaskan endpoint dan menyebutkan nama model dalam kalimat ketersediaan, bukan dalam tabel model. Papan peringkat independen yang melakukan benchmark terhadapnya menggunakan nama yang mudah dibaca di baris dan grafiknya. Tidak satu pun dari ini salah, dan tidak satu pun dari ini adalah ID model, jadi menyalin dari salah satunya ke dalam body permintaan menghasilkan kegagalan yang sama.

Ada sumber variasi keempat yang akan semakin penting seiring waktu: tulisan orang lain. Liputan peluncuran, tutorial, dan jawaban forum semuanya memendekkan nama itu, dan sebagian memendekkannya menjadi sesuatu yang tampak seperti id — huruf kecil, bertanda hubung, masuk akal. Solusinya adalah jangan memercayai salah satunya. Tanyakan pada endpoint.

Cara memeriksa apa yang sebenarnya dapat dipanggil oleh kunci tertentu

Sebelum menulis permintaan, daftarkan model yang berhak diakses oleh kunci tersebut. Panggilan list-models standar pada Generative Language API mengembalikan model yang tersedia untuk proyek Anda beserta ID-nya, dan menjalankannya sekali akan menyelesaikan pertanyaan itu secara permanen untuk kunci tersebut.

Jika gemini-decision-1 muncul, Anda memiliki akses, dan string persis itulah yang dimasukkan ke dalam permintaan. Jika tidak muncul, masalahnya adalah hak akses atau region, bukan ejaan, dan mengganti nama sebanyak apa pun tidak akan membantu. Yang tidak akan Anda temukan dalam daftar itu adalah entri bernama gemini-decision, karena model tersebut tidak ada.

Pemeriksaan kedua adalah pada respons. Respons keputusan yang berhasil mengidentifikasi model yang melayaninya, sehingga pipeline yang mencatat bidang model bersama id permintaannya sendiri dapat menjawab "model mana yang menghasilkan jawaban ini" berbulan-bulan kemudian tanpa membaca ulang konfigurasi. Itu terdengar seperti pekerjaan rutin sampai pertama kali seseorang bertanya mengapa sebuah keputusan berubah dan jawaban jujurnya adalah bahwa sebuah alias telah berpindah.

Tiga kesalahan yang sebenarnya ditimbulkan oleh ambiguitas ini

• 404 model tidak dikenal. Yang jelas. gemini-decision di body permintaan mengembalikan error yang terdengar seperti masalah izin padahal bukan. Jika error menyebut model, bukan project, periksa string sebelum memeriksa akun penagihan.

• Asumsi alias yang senyap. Lebih sulit dikenali. Tim yang telah menginternalisasi konvensi -latest menulis konfigurasi dengan nama famili dan langkah resolusi, lalu langkah resolusi itu diam-diam mengembalikan nama famili literal saat tidak ada alias. Kegagalan kemudian baru muncul pada permintaan nyata pertama, bukan saat deploy — waktu terburuk yang mungkin untuk itu.

• Asumsi endpoint yang keliru. Bahkan lebih halus lagi, karena modelnya memang ada dan namanya benar: gemini-decision-1 yang dikirim ke endpoint generate-content biasa tetap gagal. Model tersebut sama sekali tidak dapat dipanggil dengan cara itu. Ia adalah target yang hanya menghasilkan probabilitas pada endpoint decisions, dan permintaan yang memintanya menulis prosa berarti meminta sesuatu yang tidak dihasilkannya. Pustaka klien apa pun yang secara default menggunakan chat completions perlu jalur eksplisit.

Apa yang dikatakan ini tentang model tersebut, bukan sekadar namanya

Penamaan ini adalah gejala dari keputusan desain yang sebenarnya, yaitu bahwa ini bukan model chat dengan format keluaran yang berbeda. Model chat mengembalikan teks, sehingga id-nya dapat ditukar secara bebas di antara penyedia, proxy, dan gateway yang semuanya menggunakan skema yang sama. Model yang mengembalikan probabilitas terkalibrasi atas pertanyaan bertipe milik Anda sendiri tidak memiliki skema umum semacam itu, dan id-nya terikat pada satu endpoint dengan satu bentuk permintaan.

Itulah sebabnya keluarga ini belum memiliki alias mengambang dan belum memiliki anggota kedua: belum ada yang bisa menjadi acuan kompatibilitas. Ini juga menjelaskan mengapa model tersebut tidak bisa begitu saja ditambahkan ke router serbaguna. OrcaRouter tidak membawa gemini-decision-1, karena endpoint yang hanya menyediakan probabilitas bukanlah target chat-completions, dan menempatkannya di balik key yang berbicara dengan skema tersebut akan menjadi janji yang tidak dapat ditepati oleh lapisan routing. Yang kami bawa di ruang keputusan adalah typesafe/jev-1.14 milik TypeSafe, sebuah model keputusan yang dapat dipanggil melalui antarmuka yang sama dengan semua hal lain di katalog.

Bagian dari pipeline keputusan yang memang dilayani oleh router adalah separuh penyusunan draf — panggilan generatif yang menghasilkan jawaban kandidat atau rubrik yang kemudian dievaluasi oleh penilai. Panggilan itu berjalan pada lebih dari 200 model di satu endpoint dengan harga daftar penyedia diteruskan tanpa markup 0%, dan di sinilah mengganti vendor cukup menjadi perubahan konfigurasi, bukan penulisan ulang. Sebaliknya, panggilan penilaian terikat pada satu endpoint secara desain, dan arsitektur yang jujur memperlakukannya sebagai dependensi tetap, bukan sesuatu yang perlu dialihkan.

Jika Anda memilih antara kedua string pada formulir

Ada versi pertanyaan ini yang sama sekali bukan tentang pengenal, dan layak dijawab secara langsung karena frasa itulah yang mengundangnya: seseorang yang membandingkan "G​emini Decision" dengan "G​emini Decision 1" mungkin mengira sedang melihat dua produk, yang lama dan yang baru, dan ingin tahu mana yang harus diadopsi. Hanya ada satu. Tidak ada yang bernama G​emini Decision yang dirilis sebelum G​emini Decision 1, dan nama yang lebih pendek itu adalah label keluarga untuk keluarga yang saat ini memiliki satu anggota.

Konsekuensi praktisnya adalah bahwa tabel perbandingan, ulasan, atau benchmark apa pun yang Anda temukan yang mencantumkan keduanya sebagai entri terpisah sebenarnya sedang menjelaskan model yang sama dua kali. Dua baris, satu model, satu harga. Jika kedua baris itu berbeda pada suatu angka, salah satunya sudah kedaluwarsa, bukan karena mengukur sesuatu yang berbeda.

Intinya

Gunakan gemini-decision-1 di setiap body permintaan, path endpoint, dan nilai konfigurasi, dan gunakan "G​emini Decision" hanya di tempat yang dibaca manusia. Tidak ada alias yang bisa dijadikan fallback, tidak ada model kedua yang bersembunyi di balik nama yang lebih pendek, dan tidak ada path chat-completions menuju nama yang lebih panjang. Biaya jika salah dalam hal ini kecil — satu 404, satu sore yang membingungkan — tetapi biaya jika mengasumsikan alias itu ada lebih besar, karena kesalahan itu lolos review dan gagal di produksi. Sematkan id-nya, catat model yang disebutkan respons, dan perlakukan nama keluarga model sebagai prosa.