Sebuah teks yang sama, diberikan ke dua model, satu memotongnya menjadi 766 token, yang lain menjadi 1170 token.
Angka-angka ini dikeluarkan oleh Tibo, kepala OpenAI Codex.
Katanya: Satu token OpenAI, tidak sama dengan token model lain. Harga per token yang lebih rendah, belum tentu berarti tagihan yang lebih murah.
Semua orang membandingkan harga dengan 'berapa dolar per juta token', seolah-olah token adalah satuan standar seperti gram atau kilowatt-jam. Padahal tidak.
Agar lebih mudah dipahami, dia menceritakan kisah tentang pizza.
Dua pizza yang sama persis.
Toko pertama memotongnya menjadi 8 potong, masing-masing Rp 28 ribu. Toko kedua memotongnya menjadi 16 potong, masing-masing Rp 18 ribu. Toko kedua memasang spanduk 'lebih murah', tapi jika memakan seluruh pizza, harganya Rp 280 ribu, sedangkan toko pertama hanya Rp 224 ribu.
Dia menambahkan: Perutmu tidak peduli berapa potong yang baru saja kamu makan.
Setiap potong lebih murah, seluruh pizza justru lebih mahal. Cara memotong berbeda, harga per unit menjadi tidak bisa dibandingkan.
Token adalah unit terkecil untuk penagihan model, bisa dipahami sebagai 'teknik memotong' teks oleh model.
Kalimat yang sama, teknik memotong berbeda, jumlah potongannya pun berbeda. Berapa potong yang dihasilkan, bayar sebanyak itu. Semakin banyak potongan, semakin mahal tagihannya.
Perbandingan ini mencakup teks bahasa Inggris, teks teknis, multibahasa, dan konten numerik.
Tokenizer GPT-5.6 Sol menggunakan 766 token, perkiraan Claude Opus 5 adalah 1170 token.
Teks yang sama, teknik memotong GPT-5.6 Sol menghasilkan 34,5% lebih sedikit potongan.
Sedangkan harga input kedua model sama, yaitu Rp 75 ribu per juta token.
Harga per unit persis sama, jumlah potongan berkurang 30%, biaya input pun turun 30%.
Di sinilah masalahnya.
Jika bahkan 'seberapa besar satu token' saja tidak bisa disamakan antar vendor, apakah tabel perbandingan harga API yang beredar setiap hari masih bisa diandalkan?
Teks yang sama, mengapa menghitung dua angka berbeda?
Ini karena unit token pada dasarnya tidak memiliki satuan ukur yang seragam.
Setiap vendor melatih tokenizer sendiri, menentukan sendiri seberapa besar teks akan dipecah.
Kata umum, tokenizer menelannya utuh; kata langka, satu kata bisa dipecah menjadi tiga empat bagian.
Contoh bahasa Inggris paling jelas. Kata-kata seperti the, and, is sering muncul, tokenizer memberi masing-masing kode unik, satu kata adalah satu token.
Untuk kata panjang seperti unbelievable, harus dipecah menjadi un, believ, able, satu kata sudah memakan tiga token.
Logikanya sederhana: tokenizer dihitung dari korpus pelatihan, kombinasi apa yang sering muncul, kombinasi itu yang dapat posisi sendiri. Sisanya, harus disusun dari pecahan.
Jadi, 'berapa banyak token dalam sebuah paragraf' pada dasarnya bertanya: 'Seberapa umum hal-hal dalam paragraf ini di korpus vendor ini?'
Dan prosa bahasa Inggris, justru adalah jenis konten dengan perbedaan terkecil. Kode, JSON, rangkaian angka panjang, hasil pemotongan kedua model akan semakin jauh berbeda.
Bahkan hitungan model lama dan baru dari vendor yang sama pun tidak universal
Ini bukan masalah satu vendor saja.
Dokumentasi Anthropic sendiri menulis dengan jelas: Penghitungan token adalah perkiraan, jumlah token input yang sebenarnya digunakan saat membuat pesan mungkin sedikit berbeda.
Mereka juga memberikan angka konkret.
Model Claude 4.7 dan yang lebih baru menggunakan tokenizer baru, teks input yang sama menghasilkan jumlah token sekitar 30% lebih banyak dibandingkan model awal, peningkatan spesifik tergantung pada konten dan bentuk beban kerja.
Dokumentasi resmi Anthropic: Model Claude 4.7 dan yang lebih baru berganti tokenizer baru, jumlah token untuk teks yang sama bertambah sekitar 30%, jangan gunakan kembali penghitungan dari model lama.
Perusahaan yang sama, teks yang sama, setelah pergantian generasi bertambah 30%.
Jadi saran resmi mereka adalah, jika ingin tahu perbedaan beban kerja Anda, hitung permintaan yang sama dengan kedua model, bandingkan input_tokens yang dikembalikan.
Jangan gunakan angka yang dihitung pada model awal untuk memperkirakan biaya.
Antar dua generasi model dari vendor yang sama saja, hitungannya tidak bisa digunakan kembali. Membandingkan langsung 'harga per juta token' antar vendor, apalagi, semakin tidak terstandarisasi.
Sama-sama Rp 75 ribu, tagihan berbeda di empat tempat
Harga per unit sama, input sama, di mana perbedaan tagihannya?
Pertama, efisiensi tokenizer yang tadi dibahas. Teks yang sama, jumlah token yang dipotong berbeda, dikalikan harga per unit yang sama, uang yang dibayarkan tentu berbeda.
Kedua, cache.
Harga input cache GPT-5.6 Sol adalah Rp 7,5 ribu per juta token, hanya sepersepuluh dari harga input standar. Untuk beban kerja dengan banyak awalan berulang, item ini saja bisa mengubah struktur tagihan.
Ketiga, output.
Output GPT-5.6 Sol Rp 450 ribu/juta token, Claude Opus 5 mulai dari Rp 375 ribu.
Dan dalam alur kerja agen cerdas yang nyata, bobot token output seringkali lebih signifikan daripada input.
Artinya, penghematan 34,5% tadi, bisa jadi dikembalikan di sini.
Keempat, paling mudah diabaikan, tertulis di halaman model OpenAI sendiri. Jika input GPT-5.6 Sol melebihi 272K token, input untuk seluruh permintaan dihitung dengan kelipatan 2x, output dengan kelipatan 1,5x.
Halaman model resmi GPT-5.6 Sol: Input Rp 75 ribu, input cache Rp 7,5 ribu, output Rp 450 ribu, baris kecil di bawahnya berisi aturan kenaikan harga untuk lebih dari 272K.
Bukan bagian yang melebihi yang dikenakan harga lebih tinggi, seluruh permintaan dikenakan kelipatan yang lebih tinggi.
Kode yang sama, kamu tanyakan dalam konteks 270 ribu token, dan dalam konteks 280 ribu token, harga per unit sudah berbeda tingkat.
Batasan ini berasal dari halaman harga resmi mereka sendiri, semakin panjang konteksnya, biaya perhatian dan memori meningkat semakin cepat, jendela panjang tidak pernah gratis.
Jendela sejuta dibuka, uang mengalir perlahan
Tibo kemudian memposting pesan kedua, mengajarkan cara membuka jendela konteks penuh di Codex secara manual.
Buka ~/.codex/config.toml, tambahkan tiga baris sebelum semua judul section:
model = "gpt-5.6-sol"
model_context_window = 1000000
model_auto_compact_token_limit = 900000
Baris pertama pilih model, baris kedua tarik anggaran konteks ke 1 juta token, baris ketiga memicu kompresi otomatis di sekitar 900 ribu token, menyisakan sedikit ruang.
Simpan, restart klien, buka sesi baru, konfigurasi baru berlaku.
Yang tidak ingin mengubah nilai default, juga bisa menimpanya sementara hanya dalam sesi CLI tunggal:
codex -m gpt-5.6-sol
-c model_context_window=1000000
-c model_auto_compact_token_limit=900000
Kedua kunci ini dapat ditemukan di referensi konfigurasi resmi Codex, fungsinya sesuai dengan yang dia tulis.
model_context_window, jumlah token jendela konteks yang tersedia untuk model saat ini.
model_auto_compact_token_limit, ambang batas untuk memicu kompresi riwayat otomatis.
Tapi dokumentasi hanya mendefinisikan arti kunci, tidak mencantumkan nilai '1 juta/900 ribu' ini sebagai nilai rekomendasi universal.
Tibo sendiri di akhir postingannya juga menambahkan: Nilai default adalah yang telah mereka atur dengan hati-hati.
Lalu mengapa banyak orang ingin mengubahnya secara manual?
Sebuah laporan uji coba pengguna di GitHub menjelaskan alasannya.
Laporan uji coba ini di repositori openai/codex: Direktori Codex membatasi jendela di 372K, efektif 353,4K, sedangkan spesifikasi model menulis 1,05M
Dalam versi klien Codex tertentu dan akun ChatGPT Pro, direktori model untuk gpt-5.6-sol memberi label jendela 372K, dikalikan 95%, tersedia 353,4K. Sedangkan halaman model resmi menyebut 1,05M.
Membeli jendela sejuta, saat digunakan hanya tersisa sepertiganya.
Laporan ini memiliki batasan versi dan akun yang jelas, tidak bisa dianggap sebagai situasi semua pengguna, dan postingan konfigurasi Tibo diterbitkan lebih baru.
Satu hal lagi yang perlu diklarifikasi: Mengubah konfigurasi ke 1 juta tidak akan langsung menghasilkan biaya 1 juta token. Yang ditagih selalu jumlah pemrosesan aktual.
Tapi dengan ambang batas kompresi didorong hingga 900 ribu, berarti sesi panjang akan membawa riwayat yang semakin panjang, setiap putaran permintaan harus memproses ulang riwayat ini.
Semakin besar jendela, semakin lambat kompresi, permintaan semakin mungkin menabrak ambang batas 272K tadi.
Dalam percakapan pendek, perbedaan tokenizer itu masalah di belakang koma. Saat sesi ditarik hingga ratusan ribu token, catatan riwayat berulang kali dibawa, dikalikan dengan kelipatan harga yang lebih tinggi, perbedaan di belakang koma berubah menjadi di depan koma.
Uang tidak habis sekaligus, tapi naik putaran demi putaran.
Satuan berikutnya, adalah 'per keberhasilan'
Ada satu kalimat lagi dalam postingan Tibo, tertutup angka: Yang benar-benar penting adalah biaya per hasil berhasil (price per successful outcome).
Dia juga memberi caranya. Tolok ukur bisa jadi titik awal, tapi untuk benar-benar tahu mahal atau tidak, harus menjalankan pekerjaanmu sendiri.
Kalimat ini mengganti titik acuan perbandingan harga. Dari 'berapa harga per juta token', ke 'total berapa biaya untuk menyelesaikan tugas yang sama'.
Ingin tahu mana yang lebih murah di tanganmu, coba sendiri saja.
Ambil teks mentah yang sama, komposisi bahasa yang sama, definisi alat yang sama, panggil antarmuka penghitungan resmi kedua vendor untuk mendapatkan jumlah token sebenarnya, lalu sertakan hit cache, panjang output, panjang inferensi, dan kelipatan konteks panjang, akhirnya bandingkan siapa yang menghabiskan lebih sedikit untuk menyelesaikan hal ini.
Efisiensi tokenisasi hanyalah mata rantai pertama. Model yang lebih hemat token, jika inferensinya bertele-tele, jumlah percobaan ulang banyak, tagihannya tetap bisa balik menyalip.
Ke depan, yang harus ditanyakan bukan berapa harga sejuta token, tapi berapa biaya untuk memperbaiki bug ini.
Referensi:
https://x.com/thsottiaux/status/2089082893804896524?s=20
https://x.com/thsottiaux/status/2088866513008873560?s=20 https://github.com/openai/codex/issues/31860
Artikel ini berasal dari akun WeChat publik "新智元", penulis: ASI启示录
