OpenRouter: Bagaimana cara menjadikan "stasiun transit model" menjadi perusahaan senilai $1 miliar?

Penulis: Zhang Aila

Hari ini kita bahas tentang stasiun perantara.

Sederhananya, stasiun perantara model adalah menghubungkan berbagai model seperti OpenAI, Claude, Gemini, DeepSeek, dll. ke dalam satu pintu masuk, sehingga pengembang dapat memanggil banyak model dengan satu antarmuka, satu akun, dan satu tagihan, serta memilih, beralih, dan membuat cadangan di antara model atau penyedia yang berbeda.

Tentu saja, bagi pengguna domestik, alasan utama menggunakan stasiun perantara adalah untuk mengakses model luar negeri dan juga lebih murah.

Ini sudah dipahami semua orang, stasiun perantara domestik tidak perlu kita bahas panjang lebar, hari ini kita fokus memperkenalkan OpenRouter.

Pada tahun 2026, OpenRouter telah mengumpulkan dana Seri B sebesar $113 juta, dengan valuasi mendekati $1,3 miliar.

Artinya, ia sudah menjadi perusahaan unicorn.

Mari kita analisis, mengapa stasiun perantara model yang "tidak membuat model" bisa bernilai sebanyak ini?

Apa sebenarnya yang dilakukan OpenRouter?

OpenRouter secara resmi memposisikan dirinya sebagai: antarmuka terpadu untuk model besar.

OpenRouter sekarang mendukung lebih dari 400 model dan lebih dari 70 penyedia model.

Situs web resmi juga mengungkapkan bahwa platform telah memproses 100 triliun token per bulan, dengan lebih dari 10 juta pengguna global.

Dalam pengumuman pendanaan Seri B bulan Mei 2026, disebutkan juga bahwa dalam 6 bulan terakhir, volume pemrosesan mingguan OpenRouter tumbuh dari 5 triliun token menjadi 25 triliun token, dan melayani lebih dari 8 juta pengembang.

Angka-angka ini menunjukkan satu hal:

OpenRouter bukan lagi alat pengembang niche, tetapi pintu masuk panggilan AI yang sangat besar.

Cara pengembang menggunakannya juga sangat sederhana.

Dulu Anda harus menghubungkan model OpenAI, Anthropic, Google, DeepSeek, Mistral, xAI, dll. secara terpisah.

Setiap kali menghubungkan satu, Anda harus membaca dokumentasi, meminta API key, mengikat tagihan, menangani perbedaan antarmuka, memeriksa aturan pembatasan, dan melakukan penanganan pengecualian.

Setelah menggunakan OpenRouter, pengembang dapat memanggil model yang berbeda melalui antarmuka yang sama.

Seringkali, kode yang awalnya menggunakan antarmuka OpenAI hanya perlu mengubah base URL, mengganti API key, dan menentukan nama model, maka dapat memanggil model lain melalui OpenRouter.

Ini juga salah satu alasan pertumbuhan awalnya yang cepat: biaya migrasi rendah.

Mengapa pengembang tidak langsung menghubungi perusahaan model?

Tampaknya, pengembang bisa melewati OpenRouter dan langsung membuka API di situs web perusahaan model.

Namun dalam pengembangan nyata, hal ini tidak sesederhana itu.

Jika produk AI hanya demo, menggunakan satu model saja sudah cukup. Tapi begitu masuk ke bisnis nyata, sulit untuk hanya mengandalkan satu model.

Misalnya, alat penulisan AI mungkin memiliki beberapa jenis tugas berbeda:

Membuat judul, cukup dengan model murah;

Menulis artikel panjang, butuh kemampuan teks yang lebih kuat;

Menganalisis data, butuh model konteks panjang;

Melakukan moderasi konten, butuh kemampuan klasifikasi biaya rendah dan stabilitas tinggi;

Klien perusahaan meminta data tidak disimpan, maka harus memilih penyedia yang sesuai kebijakan data;

Saat puncak, model dibatasi, harus otomatis beralih ke model cadangan.

Pada saat ini, masalahnya bukan hanya "menghubungkan satu API".

Tim harus memelihara sistem panggilan model yang lengkap:

Model mana yang bertanggung jawab untuk tugas apa, model mana yang lebih murah, penyedia mana yang lebih cepat, penyedia mana yang tingkat kegagalannya lebih rendah, bagaimana beralih jika ada masalah, bagaimana mengalokasikan tagihan, bagaimana mengisolasi data klien perusahaan.

Yang lebih merepotkan, pasar model berubah sangat cepat.

Hari ini Claude cocok untuk coding, besok Gemini unggul dalam konteks panjang, lusa DeepSeek atau model open source tertentu menurunkan harga.

Kemampuan model, harga, panjang konteks, kebijakan penyedia, semuanya terus berubah.

Nilai OpenRouter ada di sini.

Ia tidak menulis aplikasi AI untuk pengembang, tetapi mengelola "model mana yang digunakan, bagaimana memanggil, bagaimana menangani kegagalan, bagaimana mengontrol biaya" untuk pengembang.

Bukan hanya supermarket model, tetapi lapisan penjadwalan model

Jika hanya memahami OpenRouter sebagai "supermarket model", maka akan meremehkannya.

Supermarket model memecahkan "ada banyak model di sini, Anda bisa memilih".

Tapi kemampuan penting OpenRouter adalah melakukan penjadwalan antara model dan penyedia.

Model yang sama mungkin disediakan oleh penyedia inferensi yang berbeda.

Misalnya, model open source dapat dihosting oleh beberapa penyedia layanan cloud atau penyedia inferensi. Harga, kecepatan, dan stabilitas dari penyedia yang berbeda tidak sama.

Dokumentasi OpenRouter memiliki fitur yang disebut provider routing, yaitu routing penyedia.

Pengembang dapat mengatur permintaan agar otomatis pergi ke penyedia yang berbeda berdasarkan harga, latensi, throughput, urutan penyedia, dll.

Ia juga mendukung fallback, yaitu ketika model atau penyedia gagal, sistem otomatis beralih ke opsi cadangan.

Bagi pengembang, OpenRouter setara dengan memisahkan "pemilihan model" dan "penanganan kegagalan" dari kode bisnis dan menyerahkannya ke platform khusus.

Mengapa perusahaan membutuhkan lapisan ini?

Ketika perusahaan mengadopsi AI, masalah awal biasanya "apakah bisa digunakan", tetapi dengan cepat berubah menjadi "bagaimana mengelolanya".

Di dalam perusahaan, mungkin ada banyak tim yang menggunakan AI.

Tim pemasaran untuk menulis konten, tim layanan pelanggan untuk membalas pengguna, tim R&D untuk menulis kode, tim operasi untuk menganalisis data, tim hukum untuk menangani kontrak.

Jika setiap tim menghubungkan model sendiri, masalah akan semakin banyak:

Tagihan tidak jelas; pemilihan model tidak seragam;

Kebijakan data tidak transparan; tim yang berbeda mengakses secara duplikat;

Jika ada masalah, tidak ada yang tahu panggilan mana yang bermasalah;

Penyedia model berubah, sistem sulit disesuaikan secara seragam.

Workspace, kontrol anggaran, log panggilan, kebijakan penyedia, routing tanpa penyimpanan data yang disediakan OpenRouter, semuanya untuk memecahkan masalah ini.

Misalnya, tanpa penyimpanan data (zero data retention).

Bagi banyak perusahaan, tidak semua permintaan bisa dikirim sembarangan ke penyedia model mana pun. Informasi pelanggan, konten kontrak, data medis, data keuangan, semuanya mungkin memiliki persyaratan ketat.

Dokumentasi OpenRouter mendukung Zero Data Retention, yaitu tanpa penyimpanan data.

Pengembang dapat mengatur agar permintaan hanya dikirim ke penyedia yang tidak menyimpan data. Kebijakan ini dapat dijalankan secara global, per grup model, aturan keamanan, atau per permintaan tunggal.

Contoh lain, prompt caching, yaitu penyimpanan sementara prompt.

Banyak aplikasi AI terus-menerus menggunakan prompt sistem yang panjang, basis pengetahuan, atau konteks. Jika dihitung ulang setiap kali, biayanya akan tinggi.

OpenRouter mendukung peningkatan rasio hit cache melalui sticky provider routing, sehingga permintaan berikutnya sedapat mungkin pergi ke endpoint penyedia yang sama, mengurangi biaya konteks berulang.

Fitur-fitur seperti ini terdengar tidak menarik, tetapi sangat praktis, dan semakin besar skala aplikasi AI, semakin terlihat penghematan biayanya.

Bagaimana OpenRouter menghasilkan uang?

Model bisnis OpenRouter sangat jelas: menghasilkan uang dari penggunaan.

Pengembang membeli kuota platform terlebih dahulu, lalu membayar berdasarkan model dan token yang benar-benar dipanggil.

OpenRouter secara resmi menjelaskan dengan jelas:

Platform mengenakan biaya 5,5% saat pembelian kuota, minimum $0,8; harga penyedia model dasar diteruskan ke pengguna dengan harga asli, tanpa markup tambahan pada harga inferensi model.

Ini adalah bisnis "biaya lalu lintas" yang sangat khas.

Keuntungan model ini adalah pendapatan terikat dengan penggunaan.

Semakin banyak pengembang memanggil, semakin tinggi pendapatan platform; semakin banyak aplikasi AI, semakin besar konsumsi token, semakin besar bisnis OpenRouter.

Tapi ia juga memiliki satu karakteristik: komisi per panggilan tidak tinggi, sehingga harus mengandalkan skala.

Ini juga mengapa volume pemrosesan token sangat penting bagi OpenRouter.

Indikator intinya bukan jumlah pengguna terdaftar, tetapi berapa banyak token yang mengalir melaluinya setiap minggu dan bulan.

Pada tahun 2025, volume pemrosesan tahunan OpenRouter tumbuh dari sekitar 10 triliun token menjadi lebih dari 100 triliun token.

Pada tahun 2026, OpenRouter telah mencapai volume pemrosesan tahunan sekitar 1,5 kuadriliun token.

Ini adalah logika dasar bisnis ini.

Selama semakin banyak aplikasi AI berjalan pada sistem multi-model, OpenRouter dapat terus memungut biaya layanan dari panggilan-panggilan ini.

Mengapa pertumbuhannya begitu cepat akhir-akhir ini?

Pertumbuhan OpenRouter, secara ringkas, adalah menikmati tiga perubahan.

Perubahan pertama, semakin banyak model.

Dulu saat membuat aplikasi AI, banyak tim secara default menggunakan OpenAI dulu. Sekarang berbeda.

Claude, Gemini, DeepSeek, Qwen, Mistral, Llama, Grok, dan masih banyak model open source serta open-weight, semuanya memiliki keunggulan di berbagai skenario.

Ini bukan pasar "siapa yang sepenuhnya menggantikan siapa".

Beberapa model bagus untuk coding, beberapa murah, beberapa kuat dalam teks panjang, beberapa cepat, beberapa cocok untuk role-play, beberapa cocok untuk dokumen perusahaan, beberapa cocok untuk multimodal.

Semakin banyak model, semakin tinggi biaya pemilihan; semakin tinggi biaya pemilihan, semakin berharga lapisan perantara.

Perubahan kedua, aplikasi AI mulai memperhatikan biaya.

Banyak produk awal menggunakan model terkuat karena harus menunjukkan hasil terlebih dahulu.

Tapi begitu produk memiliki pengguna, biaya model dengan cepat menjadi masalah.

Sebuah chatbot layanan pelanggan, produk pencarian AI, asisten kode, alat pembuatan konten, jika semua permintaan menggunakan model termahal, margin laba kotor akan mudah tergerus.

Pendekatan yang lebih matang adalah memecah tugas:

Tugas sederhana menggunakan model murah;

Tugas kompleks menggunakan model kuat;

Tugas frekuensi tinggi prioritaskan model latensi rendah;

Setelah gagal, beralih ke model cadangan;

Saat melibatkan data sensitif, hanya gunakan penyedia yang sesuai kebijakan data.

Inilah skenario penggunaan OpenRouter.

Ia tidak selalu membantu Anda menemukan "model terkuat", tetapi dapat membantu Anda menyeimbangkan antara efek, harga, kecepatan, dan stabilitas.

Perubahan ketiga, aplikasi AI beralih dari kotak obrolan ke agen.

Agen akan memanggil alat, membaca file, mencari web, menjalankan tugas, dan juga memanggil model secara multi-ronde berkelanjutan.

Dibandingkan obrolan biasa, agen mengonsumsi lebih banyak token, dan lebih bergantung pada stabilitas.

Ini menguntungkan OpenRouter.

Karena semakin banyak panggilan, semakin panjang rantai, semakin pengembang membutuhkan routing, cadangan, log, kontrol biaya, dan manajemen penyedia.

Ini juga mengapa dalam pengumuman pendanaan OpenRouter ditekankan bahwa AI sedang bergerak dari eksperimen menuju aplikasi produksi kritis dan skenario agen.

Pertumbuhannya, pada dasarnya berasal dari peningkatan volume panggilan AI.

Bisnis ini juga memiliki risiko

Posisi OpenRouter bagus, tetapi tidak aman.

Ia terjepit di antara perusahaan model, penyedia cloud, dan pengembang aplikasi. Posisi ini memiliki nilai, tetapi juga rentan terdesak.

Risiko pertama, perusahaan besar mungkin membangun sendiri.

Bagi tim kecil, OpenRouter sangat praktis.

Tapi bagi perusahaan besar, routing model, izin, log, manajemen biaya, bisa dilakukan sendiri, atau diserahkan ke penyedia cloud.

Terutama klien keuangan, medis, pemerintahan, mungkin lebih peduli pada kontrol data dan penerapan privat.

OpenRouter harus masuk ke klien ini, tidak bisa hanya mengandalkan "banyak model". Ia harus membuat izin, audit, kebijakan data, manajemen penyedia, dan dukungan perusahaan cukup dalam.

Risiko kedua, penyedia cloud juga akan membuat gateway model.

Platform cloud seperti AWS, Google Cloud, Azure, sudah memiliki klien perusahaan, sistem tagihan, sistem izin, dan kemampuan kepatuhan.

Mereka sepenuhnya dapat menjadikan panggilan multi-model, routing, pemantauan, dan manajemen biaya sebagai bagian dari layanan cloud.

Keunggulan OpenRouter adalah keterbukaan dan netralitas, cakupan model lebih luas, akses lebih cepat.

Tapi keunggulan penyedia cloud adalah hubungan klien dan proses pengadaan perusahaan, ini adalah persaingan jangka panjang.

Risiko ketiga, hubungan dengan penyedia model.

OpenRouter membawa lalu lintas ke perusahaan model, tetapi juga membuat perusahaan model lebih jauh dari pengembang akhir.

Ketika platform semakin besar, ia akan menguasai lebih banyak hubungan pengguna dan data penggunaan model.

Penyedia model berharap mendapatkan distribusi, tetapi juga khawatir kekuatan tawar mereka melemah.

Platform lapisan perantara semacam ini, awalnya biasanya disambut oleh pihak penyedia; setelah skala membesar, hubungan menjadi lebih rumit.

Risiko keempat, biaya platform mungkin ditekan.

OpenRouter mengenakan biaya platform 5,5%, sekarang terlihat tidak tinggi.

Tapi jika layanan serupa semakin banyak, pengembang akan membandingkan harga, stabilitas, cakupan model, dan fitur perusahaan.

Jika beberapa pesaing bersedia dengan biaya lebih rendah, atau penyedia cloud mengemas kemampuan ini ke dalam layanan yang sudah ada, OpenRouter perlu membuktikan bahwa ia bukan sekadar "penerus permintaan".

Ia harus terus menyediakan routing yang lebih baik, cakupan model yang lebih kuat, harga yang lebih transparan, layanan yang lebih stabil, dan kontrol perusahaan yang lebih lengkap.