Penulis: Zhang Aila
Hari ini kita bahas tentang pusat transit.
Secara sederhana, pusat transit model adalah menghubungkan model-model berbeda seperti OpenAI, Claude, Gemini, DeepSeek, dll ke belakang satu pintu masuk yang sama, memungkinkan pengembang menggunakan satu set antarmuka, satu akun, dan satu tagihan terpadu untuk memanggil berbagai model, serta memilih, beralih, dan menyiapkan cadangan di antara model atau penyedia yang berbeda.
Tentu saja, bagi pengguna di dalam negeri, alasan lebih besar menggunakan pusat transit adalah ingin menggunakan model luar negeri, dan yang lebih murah.
Ini sudah dipahami, tentang pusat transit dalam negeri kita tidak akan banyak membahas, hari ini terutama memperkenalkan OpenRouter.
Hingga tahun 2026, OpenRouter telah mengumpulkan pendanaan Seri B sebesar 113 juta dollar AS, valuasinya sudah mendekati 1,3 miliar dollar AS.
Artinya, ia sudah menjadi perusahaan unicorn.
Mari kita analisis, mengapa sebuah "pusat transit model" yang "tidak membuat model" bisa bernilai sebanyak itu?
Apa Sebenarnya yang Dilakukan OpenRouter?
OpenRouter secara resmi memposisikan dirinya sebagai: Antarmuka terpadu untuk model besar.
OpenRouter sekarang mendukung lebih dari 400 model, dari lebih dari 70 penyedia model.
Situs webnya juga mengungkapkan, volume pemrosesan platform telah mencapai 100 triliun token per bulan, dengan lebih dari 10 juta pengguna global.
Dalam pengumuman pendanaan Seri B Mei 2026 juga disebutkan, 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 yang niche, melainkan pintu masuk panggilan AI yang sangat besar.
Cara pengembang menggunakannya juga sangat sederhana.
Sebelumnya, Anda harus menghubungkan model OpenAI, Anthropic, Google, DeepSeek, Mistral, xAI, dll secara terpisah.
Setiap menghubungkan satu, Anda harus membaca dokumentasi, mengajukan API key, mengikat tagihan, menangani perbedaan antarmuka, melihat aturan pembatasan lalu lintas, dan menangani pengecualian.
Setelah menggunakan OpenRouter, pengembang dapat memanggil model yang berbeda melalui antarmuka yang sama.
Seringkali, kode yang sebelumnya menggunakan antarmuka OpenAI, hanya perlu mengubah base URL, mengganti API key, lalu menentukan nama model, 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?
Secara sekilas, pengembang sepenuhnya bisa melewati OpenRouter dan langsung membuka API di situs web perusahaan model.
Namun dalam pengembangan nyata, hal ini tidak sesederhana itu.
Jika sebuah produk AI hanya demo, satu model sudah cukup. Tetapi begitu masuk ke bisnis nyata, sangat sulit hanya mengandalkan satu model.
Misalnya, alat penulisan AI mungkin memiliki beberapa jenis tugas berbeda:
- Menghasilkan judul, model murah sudah cukup;
- Menulis artikel panjang, membutuhkan kemampuan teks yang lebih kuat;
- Menganalisis materi, membutuhkan model konteks panjang;
- Melakukan moderasi konten, membutuhkan kemampuan klasifikasi biaya rendah dan stabilitas tinggi;
- Klien perusahaan meminta data tidak disimpan, harus memilih penyedia yang memenuhi kebijakan data;
- Saat puncak model dibatasi lalu lintas, 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 mana, model mana yang lebih murah, penyedia mana yang lebih cepat, penyedia mana yang tingkat kegagalan lebih rendah, bagaimana beralih jika terjadi masalah, bagaimana atribusi tagihan, bagaimana mengisolasi data klien perusahaan.
Yang lebih merepotkan adalah, pasar model berubah terlalu cepat.
Hari ini Claude cocok untuk menulis kode, besok konteks panjang Gemini lebih unggul, lusa DeepSeek atau model open source tertentu menurunkan harga.
Kemampuan model, harga, panjang konteks, kebijakan penyedia, terus berubah.
Nilai OpenRouter juga ada di sini.
Ia tidak menggantikan pengembang dalam membuat aplikasi AI, tetapi membantu pengembang mengelola hal "model mana yang digunakan, bagaimana memanggil, bagaimana cadangan, bagaimana mengontrol biaya".
Bukan Hanya Supermarket Model, Melainkan Lapisan Penjadwalan Model
Jika hanya memahami OpenRouter sebagai "supermarket model", akan meremehkannya.
Supermarket model menyelesaikan "di sini ada banyak model, Anda bisa pilih".
Tetapi kemampuan yang benar-benar penting dari OpenRouter adalah melakukan penjadwalan di antara model dan penyedia.
Model yang sama, mungkin disediakan layanan inferensi oleh penyedia yang berbeda.
Misalnya, model open source, dapat dihosting oleh banyak penyedia layanan cloud atau inferensi. Harga, kecepatan, stabilitas penyedia yang berbeda tidak sama.
Dokumentasi OpenRouter memiliki kemampuan bernama provider routing, yaitu perutean penyedia.
Pengembang dapat berdasarkan kondisi seperti harga, latensi, throughput, urutan penyedia, dll, membuat permintaan otomatis melalui penyedia yang berbeda.
Ia juga mendukung fallback, yaitu saat model atau penyedia tertentu gagal, sistem otomatis beralih ke opsi cadangan.
Bagi pengembang, OpenRouter setara dengan memisahkan "pemilihan model" dan "penanganan kegagalan" dari kode bisnis, menyerahkannya ke platform khusus untuk diproses.
Mengapa Perusahaan Membutuhkan Lapisan Ini?
Saat perusahaan menerapkan AI, masalah awal biasanya "bisakah digunakan", tetapi dengan cepat berubah menjadi "bagaimana mengelolanya".
Sebuah perusahaan mungkin memiliki banyak tim yang menggunakan AI di dalamnya.
Tim pemasaran menggunakannya untuk menulis konten, tim layanan pelanggan untuk membalas pengguna, tim pengembangan untuk menulis kode, tim operasi untuk menganalisis data, tim hukum untuk memproses kontrak.
Jika setiap tim menghubungkan model sendiri, masalah akan semakin banyak:
- Tagihan tidak jelas; Pemilihan model tidak seragam;
- Kebijakan data tidak transparan; Tim berbeda menghubungkan berulang kali;
- Jika terjadi masalah, tidak ada yang tahu panggilan dari jalur mana;
- Penyedia model berubah, sistem sulit disesuaikan secara seragam.
Ruang kerja, kontrol anggaran, log panggilan, strategi penyedia, rute tanpa retensi data yang disediakan OpenRouter, semuanya untuk menyelesaikan masalah ini.
Misalnya, tanpa retensi data.
Bagi banyak perusahaan, tidak semua permintaan dapat dikirim sembarangan ke penyedia model mana pun. Informasi pelanggan, isi kontrak, data medis, data keuangan, semuanya mungkin memiliki persyaratan ketat.
Dokumentasi OpenRouter mendukung Zero Data Retention, yaitu tanpa retensi data.
Pengembang dapat mengatur agar permintaan hanya dikirim ke penyedia yang tidak menyimpan data. Strategi ini dapat dieksekusi secara global, grup model, aturan keamanan, atau permintaan tunggal.
Lalu ada prompt caching, yaitu penyimpanan sementara prompt.
Banyak aplikasi AI berulang kali menggunakan prompt sistem yang panjang, konten basis pengetahuan, atau konteks. Jika setiap kali dihitung ulang, biayanya akan sangat tinggi.
OpenRouter mendukung peningkatan tingkat pukulan cache melalui rute ketergantungan penyedia, sebisa mungkin membuat permintaan berikutnya melalui endpoint penyedia yang sama, sehingga mengurangi biaya konteks yang berulang.
Fitur seperti ini terdengar tidak seksi, tetapi sangat praktis, dan semakin besar skala aplikasi AI, semakin jelas penghematan biayanya.
Bagaimana OpenRouter Menghasilkan Uang?
Model bisnis OpenRouter sangat jelas: menghasilkan uang berdasarkan penggunaan.
Pengembang pertama-tama membeli kuota platform, lalu membayar berdasarkan model yang dipanggil dan token yang sebenarnya digunakan.
OpenRouter secara resmi menulis dengan sangat jelas:
Platform mengenakan biaya 5,5% saat membeli kuota, minimum 0,8 dollar AS; harga penyedia model dasar ditagihkan kepada pengguna dengan harga asli, tidak ada biaya tambahan pada harga inferensi model.
Ini adalah bisnis "biaya transit lalu lintas" yang sangat khas.
Kelebihan model ini adalah, pendapatan terikat dengan penggunaan.
Semakin banyak panggilan pengembang, semakin tinggi pendapatan platform; semakin banyak aplikasi AI, semakin besar konsumsi token, semakin besar bisnis OpenRouter.
Tetapi ia juga memiliki satu karakteristik: potongan sekali tidak tinggi, jadi harus mengandalkan skala.
Inilah mengapa volume pemrosesan token sangat penting bagi OpenRouter.
Indikator intinya bukan jumlah pengguna terdaftar, melainkan berapa banyak token yang mengalir melalui dirinya setiap minggu, setiap bulan.
Tahun 2025, volume pemrosesan tahunan OpenRouter tumbuh dari sekitar 10 triliun token menjadi lebih dari 100 triliun token.
Hingga tahun 2026, OpenRouter telah mencapai volume pemrosesan tahunan sekitar 1,5 kuadriliun token.
Inilah logika dasar bisnis ini.
Selama semakin banyak aplikasi AI berjalan pada sistem multi-model, OpenRouter dapat terus mengambil biaya layanan dari panggilan-panggilan ini.
Mengapa Pertumbuhan Terakhir Sangat Cepat?
Pertumbuhan OpenRouter, dapat disimpulkan dengan mendapatkan tiga perubahan.
Perubahan pertama, adalah model semakin banyak.
Dulu membuat aplikasi AI, banyak tim secara default menggunakan OpenAI terlebih dahulu. Sekarang berbeda.
Claude, Gemini, DeepSeek, Qwen, Mistral, Llama, Grok, serta sejumlah besar model open source dan open weight, semuanya memiliki keunggulan dalam skenario yang berbeda.
Ini bukan pasar "siapa sepenuhnya menggantikan siapa".
Ada model yang bagus menulis kode, ada model yang murah, ada model yang kuat dalam teks panjang, ada model yang cepat, ada model yang cocok untuk peran, ada model yang cocok untuk dokumen perusahaan, ada model yang cocok untuk multimodal.
Semakin banyak model, semakin tinggi biaya pemilihan; semakin tinggi biaya pemilihan, semakin berharga lapisan tengah.
Perubahan kedua, adalah aplikasi AI mulai memperhatikan biaya.
Banyak produk awal menggunakan model terkuat, karena pertama-tama harus membuat efeknya.
Tetapi begitu produk memiliki pengguna, biaya model dengan cepat menjadi masalah.
Sebuah bot layanan pelanggan, produk pencarian AI, asisten kode, alat pembuat konten, jika semua permintaan menggunakan model termahal, margin kotor mudah terkikis.
Cara yang lebih matang adalah, memecah tugas:
- Tugas sederhana menggunakan model murah;
- Tugas kompleks menggunakan model kuat;
- Tugas frekuensi tinggi mengutamakan model latensi rendah;
- Setelah gagal, beralih ke model cadangan;
- Saat melibatkan data sensitif, hanya melalui penyedia yang memenuhi kebijakan data.
Ini tepatnya skenario penggunaan OpenRouter.
Ia belum tentu membantu Anda menemukan "model terkuat", tetapi dapat membantu Anda menyeimbangkan efek, harga, kecepatan, dan stabilitas.
Perubahan ketiga, adalah aplikasi AI bergerak dari kotak obrolan ke agen cerdas.
Agen cerdas akan memanggil alat, membaca file, menjelajah web, menjalankan tugas, juga memanggil model secara berkelanjutan dalam beberapa putaran.
Dibandingkan dengan obrolan biasa, agen cerdas akan mengonsumsi lebih banyak token, dan lebih bergantung pada stabilitas.
Ini menguntungkan OpenRouter.
Karena semakin banyak panggilan, semakin panjang rantai, pengembang semakin membutuhkan perutean, cadangan, log, kontrol biaya, dan manajemen penyedia.
Ini juga mengapa pengumuman pendanaan OpenRouter menekankan, AI sedang bergerak dari eksperimen ke aplikasi produksi kunci dan skenario agen cerdas.
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 seperti ini memiliki nilai, tetapi juga mudah tertekan.
Risiko pertama, adalah perusahaan besar mungkin membangun sendiri.
Bagi tim kecil, OpenRouter sangat praktis.
Tetapi bagi perusahaan besar, perutean model, izin, log, manajemen biaya, juga dapat dilakukan sendiri, atau diserahkan ke penyedia cloud.
Terutama klien keuangan, medis, pemerintah dan perusahaan, mungkin lebih memperhatikan kendali data dan penyebaran privat.
OpenRouter untuk memasuki klien ini, tidak bisa hanya mengandalkan "banyak model". Ia harus membuat izin, audit, kebijakan data, manajemen penyedia, dan dukungan perusahaan cukup dalam.
Risiko kedua, adalah penyedia cloud juga akan membuat gateway model.
AWS, Google Cloud, Azure dan platform cloud lainnya, sudah memiliki klien perusahaan, sistem tagihan, sistem izin, dan kemampuan kepatuhan.
Mereka sepenuhnya dapat membuat panggilan multi-model, perutean, pemantauan, dan manajemen biaya menjadi bagian dari layanan cloud.
Kelebihan OpenRouter adalah terbuka dan netral, cakupan model lebih luas, akses lebih cepat.
Tetapi kelebihan penyedia cloud adalah hubungan klien dan proses pembelian perusahaan, ini adalah persaingan jangka panjang.
Risiko ketiga, adalah hubungan dengan penyedia model.
OpenRouter membawa lalu lintas untuk perusahaan model, tetapi juga membuat perusahaan model semakin jauh dari pengembang akhir.
Saat platform semakin besar, ia akan menguasai lebih banyak hubungan pengguna dan data penggunaan model.
Penyedia model berharap mendapatkan distribusi, tetapi juga khawatir kekuatan tawar melemah.
Platform lapisan tengah seperti ini, awal biasanya disambut baik oleh penyedia; setelah skala membesar, hubungan akan lebih halus.
Risiko keempat, adalah biaya platform mungkin ditekan.
OpenRouter mengenakan biaya platform 5,5%, sekarang terlihat tidak tinggi.
Tetapi jika layanan serupa semakin banyak, pengembang akan membandingkan harga, stabilitas, cakupan model, dan fungsi perusahaan.
Jika beberapa pesaing bersedia dengan tarif lebih rendah, atau penyedia cloud membundel kemampuan seperti ini ke layanan yang sudah ada, OpenRouter perlu membuktikan dirinya bukan hanya "penerus permintaan".
Ia harus terus menyediakan perutean yang lebih baik, cakupan model yang lebih kuat, harga yang lebih transparan, layanan yang lebih stabil, dan kontrol perusahaan yang lebih lengkap.
