⚡ Ringkasan

Moonshot/Kimi merilis Kimi K3-256K: kapabilitasnya identik dengan K3 versi penuh, input video dibuang, dan jendela konteks dipatok di 256K. Sekilas kelihatannya seperti "versi diskon", tapi setelah komunitas developer menghitung dulu, kesimpulan mereka nyaris satu suara — ini justru langkah yang masuk akal. Sebab biaya terbesar di coding bukan datang dari input atau output, melainkan dari konteks yang panjang.

Intinya dalam satu kalimat
Untuk mayoritas tugas coding, porsi biaya terbesar bukan input atau output, tapi konteks. Menggeser konteks dari 50 ribu ke jutaan token langsung melipatgandakan konsumsi token satu ordo — kecuali cache kamu sangat murah, ini adalah "token assassin" dalam arti sesungguhnya. Kimi memutuskan jalan keluar di level konfigurasi: mematikan saklar paling mahal itu atas nama kamu.

💸 Kenapa konteks panjang bikin kantong jebol

Satu hal yang sudah berkali-kali terbukti: di pekerjaan coding, selama harga cache belum turun, mayoritas biaya satu sesi numpuk di token konteks. Semakin lebar jendela yang kamu buka, setiap request berikutnya ikut mengangkut gunungan yang makin besar dan makin berat.

Tapi ada syaratnya — konteks panjang baru "relatif terjangkau" kalau harga cache hit benar-benar murah. Saat ini, yang berhasil menurunkan harga cache ke level masuk akal cuma DeepSeek dan MiMo. Itu sebabnya hanya dua nama ini yang punya konteks jutaan token "yg bisa dipakai". Selebihnya, skema harga konteks panjang benar-benar di luar nalar, dan pilihan rasional kamu selalu konteks pendek.

Hitungannya simpel: 1M konteks itu rata-rata di sekitar 500K, dan jika dibandingkan dengan sesi 50K, selisih biayanya bisa 10 kali lipat.

Variabel kunci: kapan kamu memutus kompres
Kebiasaan kompres di sekitar 100K bikin rata-rata konteks kamu sekitar 50K; sementara kebiasaan numpuk sampai 990K baru mau kompres, rata-ratanya jadi 500K. Model "konteks panjang" yang sama, biaya yang 10 kali lipat lebih mahal. Bahkan kalau cuma lihat rentang 256K: sekali sesi kamu menempel ke 200K, biayanya sudah jadi 4 kali baseline 50K.

Seluruh hitungan di atas batal berlaku hanya kalau harga cache hit murah. Sayangnya mayoritas model mainstream juga menjual cache dengan harga tidak murah, jadi porsi biaya terbesar tetap di konteks — dan konteks panjang hampir pasti menaikkan tagihan kamu. Dengan membatasi konteks secara aktif, software agent otomatis menjaga ukuran konteks tetap kecil, dan biaya kamu turun drastis.

🧠 Sebagian besar developer tidak punya konsep "manajemen konteks"

Akar masalahnya ada di kebiasaan pemakaian. Banyak developer memang tidak punya ide "manajemen konteks aktif" — mereka fully bergantung pada auto-compress milik Harness (layer software agent), dan kerap memilih model termahal lalu memakai satu thread percakapan sampai penuh 1M, baru kemudian terkena kompresi otomatis.

Dengan pola pakai seperti itu, "beberapa putaran langsung habis" hampir pasti. Di grup Feishu Kimi, keluhan "kuota kecil, beberapa putar habis" yang berakhir jadi bahan cemoohan sangat berkaitan dengan cara pakai semacam ini. Pengumuman resmi di grup itu sendiri menyebut "90% skenario pemakaian tidak melebihi 256K konteks" — kalau dibalik, masih ada sekitar 10% pengguna yang dengan santai membakar kuota di konteks super panjang.

Yang lebih menarik, dokumentasi K3 pernah menulis "disarankan mulai sesi baru sebelum switch ke K3". Itu sebenernya peringatan baik, tapi banyak yang tidak nangkap maksudnya. Mereka justru men-switch sesi lama yang sudah numpuk 200K+ langsung ke K3, lalu mendorongnya sampai batas 1M dan baru kompres otomatis — langganan paket apapun tidak akan kuat. Kalimat peringatan resmi itu, kalau dipikir, lebih mirip tameng sebelum krisis PR pecah.

Pelajaran dari GPT 5.6 Sol: default 272K naik ke 372K, lalu kacau
Waktu itu GPT 5.6 Sol di Codex menaikkan default Context Window dari 272K ke 372K, langsung dikeritik ramai-ramai dengan judul "token tidak awet". Tibo sampai harus posting penjelasan bahwa Auto Compact di dua tingkat itu sebenarnya bedanya tidak dramatis. Tapi akhirnya tim pun tidak tahan, dan diam-diam mengembalikan default ke semula. Default yang mengisi penuh konteks itu desain yang rugi — capek, tapi tidak dihargai.

🔍 "Cache hit 98%" sebenarnya tanda bahaya

Sering banget ada yang memamerkan cache hit 98% atau 99% di komunitas, lalu merasa dirinya sudah irit. Intuisi ini kemungkinan besar terbalik dari kenyataan.

Hit rate cache di lapisan Harness antar layanan sebenarnya tidak beda jauh. Angka yang abnormal tinggi justru menandakan kamu sedang berat sebelah ke konteks panjang — dan konteks panjang adalah bagian termahal. Jadi "hit rate tinggi" kalau diterjemahkan jadi: "aku paling banyak pakai di tempat yang paling mahal".

Pada akhirnya, tidak semua skenario butuh konteks panjang. Belajar mengelola konteks secara aktif adalah syarat supaya model-model mahal itu bisa dipakai dengan reasonable; kalau kamu tipe yang suka "satu thread jalan terus sampai penuh 1M dan kompres otomatis", maka selain DeepSeek dan MiMo, semua model lain kemungkinan bakal jebol dari budget kamu.

🏷️ Apakah versi 256K bakal lebih murah? Hampir pasti tidak

Banyak orang nebak model ID baru ini bakal dapat harga lebih murah. Hampir pasti tidak — harganya tetap sama. Pengali harga yang disebut resmi utamanya berasal dari biaya input konteks panjang dan cache hit, bukan dari diskon model itu sendiri.

Kalau dibandingkan rata-ratanya, selisih aslinya bisa tarik sampai 3 kali lipat. Hanya saja mayoritas sesi nyatanya tidak menyentuh 1M, jadi pihak resmi memberi angka konservatif "estimasi 2 kali".

Sekumpulan asumsi data
Di batas 256K, panjang Context rata-rata berkisar di 150K; di batas 1M, rata-ratanya sekitar 600K — hanya dari harga cache saja selisihnya sudah 4 kali lipat. Satu Prompt rata-rata berisi sekitar 8 message turn, dengan asumsi input 4K dan output 600 token per turn, sehingga porsi biaya input dan output sebenarnya tidak dominan.

Jadi kenaikan value-for-money datang dari aksi "memutus konteks panjang di level konfigurasi model", bukan dari penurunan harga.

Justru karena alasan inilah Kimi merilis versi terpisah — memutus konteks panjang langsung dari level konfigurasi, supaya cost-to-performance untuk tugas pengguna benar-benar naik.

📊 Hasil uji: kuota terkuras sekitar sepertiga dari versi penuh

Beberapa angka real dan fakta menarik dari kolom komentar:

  • Fakta unik: Codex dan Cursor terhubung dengan model 1M, tapi konteks yang benar-benar bisa dipakai cuma sekitar 2–3 ratus K.
  • Versi 256K rugi berapa: ada yang melakukan uji di tugas yang sama, versi 256K ini menghabiskan kuota sekitar 1/3 dari versi penuh — sebab konteks besar sendiri sudah menambah konsumsi token; jika dihitung dengan standar hasil yang setara, kuota yang terkuras untuk tugas yang sama sekitar 40% dari sebelumnya.
  • Tugas panjang: tugas yang berjalan satu sampai dua jam di kimi cli, konsumsi kuota mingguan cuma 5,53%; padahal sebelumnya hampir selalu di atas 10% per jam.
  • Apakah hasilnya terpengaruh: iya, setelah review perlu sedikit rework; versi penuh hampir tidak perlu rework.
  • Video dan 1M soal compute: dengan membuang input video dan konteks 1M, kebutuhan compute turun setidaknya setengah.

Buat pengguna paket 199 yang kuotanya memang sudah ketat, versi yang dipotong ini bikin kamu bisa bernapas sedikit lebih lega. Dan bagian pentingnya — versi 1M dari K3 MAX tetap tersedia, tidak seperti ChatGPT yang kalau mau pakai 1M harus lewat API billing.

Hasilnya: di samping opsi murah yang sudah ada, sekarang ada satu pilihan lagi (sekalian ngurangin beban compute di sisi resmi). Untuk pengguna, ini untung segala arah.

🎯 Kesimpulan

Buat mayoritas pengguna, konteks panjang itu adalah token assassin — kecuali model semacam DeepSeek dan MiMo yang cache-nya super murah, semua sisanya diam-diam menggerus saldo kamu.

Kimi K3-256K menaruh batas di level konfigurasi: mengatur gaya pengeluaran kamu dari sisi atas. Buat tim yang compute-nya memang selalu ketat, ini langkah yang patut diapresiasi. Hal yang benar-benar mahal bukanlah modelnya — melainkan "tak terhingga" yang selama ini kamu kira terjangkau.


Tulisan ini disusun berdasarkan diskusi publik dan hasil uji komunitas developer terhadap rilis Kimi K3-256K. Semua angka dan pendapat diambil dari umpan balik komunitas dan hanya sebagai referensi; untuk detail penagihan resmi, merujuk pada pengumuman Moonshot/Kimi.