MiniMax M3 API: Harga, Konteks 1M & Penggunaan Produksi

API MiniMax M3 resmi diluncurkan pada 1 Juni. Saya mulai mengujinya minggu itu juga. Dua minggu adalah waktu paling awal saya mau menuliskan sesuatu — sebelum itu, kamu masih terkesima oleh demo.

Ini adalah catatan kerja, bukan ulasan model. Benchmark sudah ada di mana-mana. Yang saya pedulikan lebih spesifik: di mana model minimax m3 ini benar-benar cocok dalam produksi, berapa biaya konteks 1M token dalam praktiknya, dan mana yang lebih baik — API langsung atau agregator, serta kapan masing-masing tepat digunakan.

Beberapa hal yang perlu disampaikan di awal.

Sebagian besar angka headline (59,0% SWE-Bench Pro, peningkatan kecepatan >9× / 15×, 83,5 di BrowseComp) dilaporkan oleh vendor. Saya menyarankan untuk memperlakukannya sebagai batas atas dalam kondisi menguntungkan, bukan batas bawah pada codebase Anda.

Konteks 1M itu nyata. Harganya terbagi dalam dua tingkatan. Hal ini lebih penting dari yang banyak orang kira.

Bobot terbuka sudah mendarat di Hugging Face sekitar hari kesepuluh. Jika kamu membaca artikel peluncuran yang mengatakan “bobot akan segera tersedia,” itu sudah basi.

Apa Itu MiniMax M3 (untuk para pengembang)

Ketersediaan API & jalur akses

Ada tiga cara masuk. Langsung melalui platform terbuka MiniMax. Melalui agregator — OpenRouter, Fireworks, dan lainnya. Atau self-host dari Hugging Face.

Saya mencoba dua cara pertama. Self-hosting saya serahkan kepada mereka yang memiliki GPU yang memadai — jumlah parameter minimax m3 adalah ~428B total dengan ~23B yang diaktifkan per token (MoE), jadi ini bukan urusan GPU konsumen tunggal.

Dua jalur yang saya uji terasa berbeda dengan cara yang tidak jelas dari dokumentasi. Jalur langsung lebih murah per token. Agregator memberi satu permukaan penagihan untuk banyak model. Mana yang lebih penting tergantung pada pertanyaan yang belum dijawab oleh sebagian besar tim — dan saya akan kembali ke sini nanti karena di sinilah saya melihat orang-orang mandek.

Konteks 1M dengan minimum terjamin 512K

Ini adalah baris yang perlu dibaca dengan seksama. API MiniMax M3 mendukung hingga 1 juta token konteks. Angka yang perlu direncanakan adalah 512K — minimum yang terjamin. Batas atas 1M bersifat kondisional.

Saya menjalankan tes pada ~480K (repo yang digabungkan + dokumen desain + thread yang panjang). Hasilnya konsisten di tiga percobaan, latensi dalam kisaran yang saya perkirakan.

Saat didorong ke ~700K (menambahkan riwayat isu lengkap proyek), variasi latensi melebar secara nyata. Dan tingkatan penagihan pun berubah.

Jadi dalam praktiknya: 512K adalah angka kerja yang andal. Separuh atas jendela itu ada, tetapi itu adalah item anggaran, bukan kapasitas gratis.

Arsitektur di baliknya adalah MSA — MiniMax Sparse Attention — yang didokumentasikan dalam postingan peluncuran. Detail yang relevan untuk perencanaan biaya adalah bahwa komputasi per token pada konteks 1M turun hingga sekitar 1/20 dari M2. Tanpa rasio itu, tingkatan konteks panjang tidak akan mungkin secara ekonomis.

Untuk Apa M3 Dirancang

Beban kerja coding & agentic

Model minimax m3 diposisikan untuk coding jangka panjang dan pekerjaan agen. Dari dua minggu menggunakannya, framing tersebut cukup jujur.

Pertanyaan-jawaban satu giliran tidak masalah. Tidak mengagumkan, tapi baik-baik saja. Perbedaannya muncul dalam sesi panjang — membaca repo, merencanakan, mengeksekusi, beritari, dan pulih dari sesuatu yang rusak di tengah jalan. Demo MiniMax sendiri menjalankan M3 selama 12 jam, 18 commit, mereproduksi makalah ICLR. Itulah beban kerja yang tampaknya menjadi dasar arsitektur ini.

Angka benchmark minimax m3 yang relevan — semuanya dilaporkan vendor — adalah 59,0% SWE-Bench Pro, 66,0% Terminal Bench 2.1, 74,2% MCP Atlas. Liputan VentureBeat membandingkannya dengan GPT-5.5 dan Gemini 3.1 Pro. Framing (“eclipsing”) perlu saya dinginkan 30%. Angkanya nyata. Kondisinya adalah lab MiniMax dengan scaffolding MiniMax.

Artinya bagi para pengembang: jika Anda membangun asisten coding, agen desktop, atau apa pun yang menangani rencana multi-langkah, M3 masuk daftar pendek. Jika beban kerja Anda adalah prompt pendek dengan konkurensi tinggi, Anda membayar untuk konteks yang tidak digunakan.

Input multimodal native (gambar, video)

Multimodal bersifat native, bukan tambahan. Teks, gambar, dan video masuk ke dalam konteks yang sama. Output-nya adalah teks.

Saya memberikannya screenshot UI + rekaman layar 30 detik + sebagian kode backend terkait dan memintanya untuk mencari tahu apa yang sebenarnya ingin dilakukan pengguna. Berhasil. Tidak dalam satu langkah — saya harus mendorongnya di giliran kedua. (Tebakan pertama masuk akal tapi salah.) Itu sudah cukup berhasil menurut standar saya.

Detail yang ingin saya tandai, karena hal ini menjadi masalah dalam tes lain: token gambar dan video berbagi pool yang sama dengan teks. Klip pendek bisa memakan sebagian besar jendela 512K Anda sebelum ada teks prompt. Saya memeriksa jumlah token pada klip 720p 15 detik — lebih tinggi dari perkiraan mental saya. Layak diukur sebelum membuat ekstrapolasi.

Biaya & Batas Produksi

Saya tidak menyertakan angka spesifik per juta token di sini. Tarif provider berubah, dan ada artikel terpisah tentang mekanisme harga minimax m3 yang menangani matematikanya dengan benar. Yang Anda butuhkan pada tahap perencanaan adalah bentuknya.

Tarif standar vs konteks panjang (>512K)

Dua tingkatan pada API MiniMax M3:

≤512K token input — tarif standar. Mencakup sebagian besar chat, coding, dan loop agen.
>512K token input — tarif konteks panjang yang lebih tinggi. Ditujukan untuk penalaran repo lengkap, dokumen sangat panjang, sesi agen berjam-jam.

Pembagian ini adalah satu hal yang akan saya rancang. Sistem yang berada di kisaran 100K–300K memiliki ekonomi unit yang berbeda dari yang secara rutin menyentuh 700K. Saya menemukan hal ini dengan cara yang sama yang saya duga akan ditemukan kebanyakan tim: dengan melihat tagihan.

Yang berhasil bagi saya: batasi routing default di 512K, wajibkan flag eksplisit untuk melewatinya. Maka biayanya muncul di situs panggilan, bukan di akhir bulan.

Pool token bersama lintas modalitas

Sudah disebutkan, tapi layak mendapat baris sendiri. Tidak ada tunjangan multimodal terpisah. Gambar adalah token. Frame adalah token. Keduanya menggunakan jendela yang sama seperti teks, dan keduanya melewati 512K dengan cara yang sama seperti teks.

Untuk loop agen yang mengambil screenshot setiap giliran, ini bertambah lebih cepat dari perkiraan kasar. Audit jumlah token sesi nyata. Jangan percayai benchmark sintetis.

API Langsung vs Lapisan Agregasi

Keputusan yang saya lihat tim-tim tersangkut. Kebanyakan dari mereka mandek lebih lama dari seharusnya.

Kapan masing-masing masuk akal

Gunakan langsung jika:

M3 ditetapkan sebagai model utama dan Anda tidak berencana menggantinya.
Biaya per token lebih penting daripada permukaan integrasi.
Anda membutuhkan 1M penuh (beberapa agregator membatasi lebih rendah — Fireworks diluncurkan dengan batas 500K dan sedang menaikkannya secara bertahap).
Mempertahankan integrasi khusus model tidak menjadi masalah bagi Anda.

Gunakan agregator jika:

Anda sudah menjalankan lebih dari satu model dalam produksi, atau akan perlu melakukannya.
Anda ingin A/B M3 melawan, misalnya, Claude Opus atau DeepSeek V4 tanpa membangun ulang jalur permintaan.
Penagihan terpadu, percobaan ulang, routing fallback, dan observabilitas penting.
Anda belum tahu model mana yang cocok untuk beban kerja Anda.

Alasan jujur untuk agregasi bukanlah biaya per token yang lebih rendah. Biasanya sedikit lebih tinggi. Alasannya adalah bahwa kebebasan beralih model memiliki nilai ekonomi, dan nilai itu berlipat ganda semakin banyak produk Anda menyentuh generasi lintas provider. WaveSpeedAI berada di lapisan itu, begitu pula OpenRouter dan Fireworks — masing-masing membuat trade-off berbeda pada routing, latensi, dan cakupan.

Aturan kasar saya, sekadar referensi: agen coding model tunggal → langsung. Campuran teks + gambar + video lintas provider → agregator. Bukan aturan baku. Titik awal saja.

Batasan & Trade-off

Bobot terbuka, laporan teknis, dan apa yang masih kurang

Bobotnya ada di Hugging Face. Kuantisasi GGUF komunitas sudah tersedia. Dua hal yang perlu diketahui:

Ketentuan lisensi belum sepenuhnya final. Jangan asumsikan Apache 2.0 atau MIT — periksa sebelum membangun produk komersial di jalur deployment lokal.

Dan tidak semua inference engine mendukung MSA. Yang tidak mendukung akan mundur ke dense attention, yang mengorbankan sebagian besar keunggulan kecepatan. Jika Anda self-host, verifikasi dukungan engine sebelum melakukan benchmark — jika tidak, angka Anda akan terlihat lebih buruk dari seharusnya.

Kesenjangan ARC-AGI

Satu hal yang cenderung dilewati oleh liputan peluncuran. Angka coding dan agentic M3 tidak diterjemahkan secara bersih ke benchmark penalaran abstrak umum seperti ARC-AGI. Model ini dirancang untuk apa yang diiklankan — coding, penggunaan alat, agen jangka panjang, grounding multimodal — bukan teka-teki abstrak.

Itu bukan kritik. Itulah bentuk modelnya. Mengetahuinya menghindarkan Anda dari taruhan yang salah.

FAQ

Apakah API MiniMax M3 sudah aktif dan stabil untuk penggunaan produksi?

Ya. Aktif sejak 1 Juni 2026. Cukup stabil sehingga beberapa agregator sudah merutekan traffic nyata. Seperti model mana pun yang belum berumur tiga bulan, harapkan perubahan perilaku sesekali saat provider menyempurnakan — pin prompt Anda, pertahankan suite evaluasi.

Berapa panjang konteks yang benar-benar terjamin di MiniMax M3 (512K atau 1M)?

512K terjamin, 1M adalah batas atas. Di bawah 512K berperilaku konsisten. Di atas itu, Anda masuk ke harga yang lebih tinggi dan variasi latensi yang lebih besar. Beberapa agregator membatasi di bawah 1M saat peluncuran. Rencanakan dengan 512K.

Apakah MiniMax M3 secara native multimodal untuk input gambar dan video?

Ya. Native, bukan adapter. Teks, gambar, dan video berbagi pool token dan jendela konteks yang sama. Output hanya teks.

Apakah bobot terbuka untuk MiniMax M3 sudah tersedia?

Ya. Mendarat di Hugging Face sekitar hari kesepuluh setelah peluncuran. ~428B total parameter, ~23B yang diaktifkan per token (MoE). GPU konsumen tunggal tidak akan bisa menjalankannya — perkirakan inferensi multi-GPU atau terkuantisasi. Ketentuan lisensi — verifikasi sebelum penggunaan komersial.

Haruskah saya mengakses MiniMax M3 langsung atau melalui agregator?

Langsung jika Anda berkomitmen pada satu model dan ingin biaya per token terendah. Agregator jika Anda menjalankan lebih dari satu model atau berencana untuk beralih. Jawabannya tergantung pada beban kerja Anda, bukan pada mana yang “lebih baik.”

Kesimpulan

API MiniMax M3 menarik bukan karena unggul pada satu axis tertentu, melainkan karena kombinasinya — coding tingkat frontier, multimodal native, konteks 1M yang nyata (meski bertingkat), bobot terbuka, semua dalam satu model. Kombinasi itu menyederhanakan permukaan integrasi yang sebelumnya memerlukan penggabungan beberapa provider.

Yang akan saya lakukan sebelum berkomitmen ke produksi:

Jalankan beban kerja Anda yang sebenarnya, bukan benchmark. Ukur di mana prompt mendarat relatif terhadap 512K. Tentukan kebijakan routing sebelum peluncuran. Pilih langsung atau agregator berdasarkan berapa banyak model yang akan Anda jalankan, bukan hanya berdasarkan harga stiker. Jika Anda self-host, periksa dukungan MSA di engine Anda.

Dua minggu itu tidak lama. Model akan terus berkembang begitu pula harganya. Itulah tanggal kedaluwarsa artikel ini.

Untuk diverifikasi, seperti biasa, terhadap apa yang dikatakan dokumentasi pada hari Anda benar-benar membangun.

Postingan sebelumnya: