Teknologi AI

OmniRoute: Gateway AI Lokal untuk Semua Model

M
MUGHU
42 menit baca
OmniRoute: Gateway AI Lokal untuk Semua Model
Daftar isi

OmniRoute adalah gateway AI lokal dan sumber terbuka yang menyatukan ratusan penyedia model bahasa ke satu endpoint yang kompatibel dengan API OpenAI. Teman-Teman bisa menghubungkan Cursor, Claude Code, Codex, Cline, Copilot, dan aplikasi lain tanpa perlu mengubah konfigurasi setiap kali kuota habis atau ingin pindah model.

Ringkasnya: OmniRoute menerima permintaan dari aplikasi di komputer Teman-Teman, menerjemahkan formatnya bila perlu, memilih penyedia AI berdasarkan aturan routing, lalu mengembalikan respons melalui satu alamat lokal seperti http://localhost:20128/v1.

Proyek ini cocok untuk pengembang individu, tim perangkat lunak, laboratorium kampus, serta perusahaan di Indonesia yang ingin mengelola banyak akun dan API AI secara lebih rapi. Kegunaan utamanya bukan sekadar mencari akses gratis, melainkan mengurangi ketergantungan pada satu penyedia, meningkatkan ketahanan layanan, dan memberi visibilitas lebih baik atas pemakaian model.

Repositori resminya tersedia di GitHub OmniRoute. Karena pengembangannya bergerak cepat, jumlah penyedia dan fitur dapat berubah antarversi. Dokumentasi terbaru menyebut dukungan sekitar 236–237 penyedia, lebih dari 90 opsi dengan tingkat gratis, puluhan strategi routing, serta integrasi MCP dan A2A.

Latar Belakang: Kenapa Gateway AI Lokal Mulai Dibutuhkan?

Saat sebuah proyek hanya memakai satu API AI, arsitekturnya terlihat sederhana. Aplikasi mengirim permintaan ke satu endpoint, menerima jawaban, lalu menampilkannya kepada pengguna.

Masalah mulai terasa ketika pemakaian bertambah:

  • Kuota penyedia habis di tengah pekerjaan.

  • Batas permintaan per menit terlalu rendah.

  • Model tertentu lambat atau sedang bermasalah.

  • Format API berbeda antara OpenAI, Anthropic, dan Gemini.

  • Setiap IDE membutuhkan konfigurasi sendiri.

  • Biaya sulit diprediksi karena permintaan tersebar di banyak layanan.

  • Kunci API tersimpan di terlalu banyak aplikasi.

  • Tim tidak punya satu tempat untuk memantau kesehatan koneksi.

Situasi ini umum terjadi pada tim pengembang di Jakarta, Bandung, Surabaya, Yogyakarta, Bali, dan kota lain yang mulai memasukkan AI ke alur kerja harian. Biaya dalam dolar, keterbatasan kartu pembayaran internasional, dan koneksi ke pusat data luar negeri membuat pemilihan penyedia makin penting.

Gateway AI bertindak seperti petugas lalu lintas. Aplikasi cukup berbicara kepada satu gerbang, sedangkan gerbang tersebut menentukan jalan terbaik menuju model yang tersedia.

Gateway AI adalah lapisan perantara yang menerima permintaan dari aplikasi, menerapkan autentikasi dan kebijakan routing, lalu meneruskannya ke satu atau beberapa penyedia model.

OmniRoute mengambil pendekatan local-first. Konfigurasi, kredensial, riwayat penggunaan, dan basis data utamanya berjalan di lingkungan yang Teman-Teman kelola sendiri. Namun, isi permintaan tetap dikirim ke penyedia AI yang dipilih, jadi local-first tidak sama dengan inferensi sepenuhnya lokal.

Masalah yang Ingin Diselesaikan OmniRoute

Bayangkan sebuah tim kecil memakai Claude untuk menulis kode, Gemini untuk tugas dengan konteks panjang, dan model gratis sebagai cadangan. Tanpa gateway, setiap alat harus dikonfigurasi secara terpisah.

Ketika akun utama terkena batas kuota, seseorang harus:

  1. Menghentikan pekerjaan.

  2. Membuka pengaturan aplikasi.

  3. Mengganti URL atau kunci API.

  4. Memilih model baru.

  5. Menguji apakah konfigurasi tersebut berfungsi.

  6. Mengulang langkah yang sama di perangkat lain.

Perpindahan manual seperti ini terlihat sepele, tetapi biayanya besar jika terjadi berkali-kali. Gangguan lima sampai sepuluh menit pada beberapa anggota tim dapat berubah menjadi berjam-jam waktu kerja yang hilang setiap bulan.

OmniRoute menawarkan pendekatan empat tingkat:

  1. Subscription untuk memanfaatkan paket berlangganan yang sudah dibayar.

  2. API Key untuk memakai API resmi yang memiliki kredensial.

  3. Cheap untuk mengalihkan tugas ke model yang lebih ekonomis.

  4. Free sebagai lapisan cadangan terakhir.

Urutan tersebut tidak wajib. Teman-Teman tetap bisa membuat combo dan aturan sendiri sesuai kebutuhan, kebijakan privasi, anggaran, serta target kualitas.

Gambaran Produk OmniRoute

OmniRoute dibangun dengan TypeScript dan menyediakan endpoint yang kompatibel dengan OpenAI. Aplikasi yang mendukung alamat API khusus biasanya bisa diarahkan ke OmniRoute tanpa integrasi yang rumit.

Fitur utamanya meliputi:

  • Satu endpoint untuk banyak penyedia

  • Auto-fallback saat penyedia gagal atau kuota habis

  • Penerjemahan format OpenAI, Claude, Gemini, dan Responses API

  • Strategi routing berdasarkan prioritas, biaya, kuota, kecepatan, atau beban

  • Dashboard untuk provider, model, penggunaan, dan kesehatan layanan

  • Circuit breaker untuk menghindari penyedia yang sedang gagal

  • Cooldown per koneksi atau akun

  • Lockout per model

  • Kompresi prompt RTK dan Caveman

  • Server MCP dengan puluhan alat

  • Dukungan A2A berbasis JSON-RPC

  • Deployment melalui npm, Docker, atau aplikasi desktop

  • Penyimpanan lokal berbasis SQLite

  • Dukungan proxy pada beberapa tingkat konfigurasi

OmniRoute berjalan pada port 20128 secara default. Endpoint yang paling sering dipakai adalah:

TEXT
http://localhost:20128/v1

Dashboard biasanya tersedia melalui:

TEXT
http://localhost:20128/dashboard

Pada beberapa versi atau mode pemasangan, membuka alamat akar berikut juga dapat mengarahkan Teman-Teman ke antarmuka yang sesuai:

TEXT
http://localhost:20128

OmniRoute Cocok untuk Siapa?

OmniRoute paling relevan untuk:

  • Pengembang yang memakai beberapa alat coding berbasis AI.

  • Tim yang punya beberapa akun atau kunci API.

  • Pengelola server internal yang ingin satu titik konfigurasi.

  • Pengguna yang sering terkena batas kuota.

  • Tim dengan kebutuhan fallback otomatis.

  • Pengguna yang ingin memantau biaya dan kesehatan provider.

  • Pengembang yang membutuhkan API OpenAI-compatible di atas banyak backend.

  • Tim Indonesia yang ingin menjalankan gateway di komputer sendiri, VPS Jakarta, atau server regional Singapura.

OmniRoute mungkin bukan pilihan terbaik jika:

  • Kebijakan perusahaan mewajibkan satu penyedia AI saja.

  • Data hanya boleh diproses di wilayah tertentu.

  • Organisasi membutuhkan SLA komersial dan dukungan resmi 24 jam.

  • Tim tidak ingin mengelola pembaruan dan keamanan server sendiri.

  • Semua inferensi harus berlangsung offline.

  • Beban kerja mengandung data sensitif yang tidak boleh diteruskan ke layanan pihak ketiga.

Lisensi MIT memberi keleluasaan untuk penggunaan dan modifikasi perangkat lunak. Namun, lisensi OmniRoute tidak menggantikan syarat penggunaan masing-masing penyedia. Kredensial OAuth, API gratis, dan akun web tetap tunduk pada kebijakan layanan asalnya.

Memulai: Istilah yang Perlu Dipahami

Sebelum memasang OmniRoute, ada beberapa istilah penting.

Provider

Provider adalah penyedia model atau layanan AI. Contohnya OpenAI, Anthropic, Google Gemini, Groq, NVIDIA, dan penyedia lain yang kompatibel dengan API tertentu.

Connection

Connection adalah akun atau kredensial yang dipakai untuk mengakses provider. Satu provider bisa mempunyai beberapa koneksi, misalnya tiga API key dari proyek berbeda.

Model

Model adalah mesin AI yang menerima prompt. Nama model dapat berbeda antarprovider meskipun kemampuan umumnya mirip.

Combo

Combo adalah kumpulan target model yang diatur sebagai satu jalur routing. Jika target pertama gagal, OmniRoute dapat mencoba target berikutnya sesuai strategi.

Auto-routing

Auto-routing memilih target berdasarkan kondisi saat permintaan diterima. Penilaian dapat mempertimbangkan kesehatan, biaya, latensi, kuota, dan riwayat keberhasilan.

Circuit breaker

Circuit breaker menghentikan permintaan sementara ke provider yang berulang kali gagal. Konsepnya sama seperti pemutus arus listrik: jalur bermasalah dihentikan agar tidak mengganggu keseluruhan sistem.

MCP dan A2A

MCP atau Model Context Protocol memungkinkan aplikasi dan agen AI menggunakan alat melalui protokol yang seragam. A2A berfokus pada komunikasi antarsistem agen.

OmniRoute dapat mengekspos kemampuan gateway melalui MCP atau A2A. Agen yang diberi izin dapat memeriksa provider, routing, cache, compression, memory, dan fungsi operasional lain.

Prasyarat Instalasi OmniRoute

Teman-Teman tidak perlu memahami seluruh arsitektur internal sebelum mulai. Namun, lingkungan yang rapi akan mencegah sebagian besar masalah pemasangan.

Prasyarat umum

Siapkan hal berikut:

  • Windows, macOS, atau Linux.

  • Hak untuk memasang aplikasi.

  • Koneksi internet.

  • Browser modern.

  • Ruang penyimpanan beberapa gigabita.

  • Terminal seperti PowerShell, Terminal, Bash, atau Zsh.

  • Setidaknya satu akun atau API key provider untuk pengujian.

  • Cadangan konfigurasi sebelum melakukan peningkatan versi besar.

Prasyarat untuk instalasi npm

Jika memilih npm, siapkan:

  • Node.js versi yang didukung rilis terbaru.

  • npm yang terpasang bersama Node.js.

  • Build tools jika modul native harus dikompilasi.

  • Port 20128 yang belum dipakai aplikasi lain.

Periksa panduan Node.js resmi untuk memasang versi LTS yang sesuai. Gunakan versi LTS, bukan rilis eksperimental, kecuali catatan rilis OmniRoute menyatakan dukungan khusus.

Prasyarat build tools per sistem operasi

Sistem operasi

Komponen yang umumnya diperlukan

Kenapa dibutuhkan

Windows

Visual Studio Build Tools dan Python

Membantu kompilasi modul Node.js native

macOS

Xcode Command Line Tools

Menyediakan compiler dan alat build

Ubuntu/Debian

build-essential, Python, Git

Menyediakan GCC, Make, dan utilitas build

Fedora/RHEL

Development Tools, Python, Git

Menyediakan toolchain native

Docker

Docker Engine atau Docker Desktop

Menjalankan image tanpa memasang dependensi npm langsung

Kebutuhan persis dapat berubah. Selalu cocokkan dengan README.md, package.json, dan catatan rilis versi yang akan dipasang.

Perbandingan Cara Memasang OmniRoute

OmniRoute dapat dipasang melalui npm, Docker, aplikasi desktop, atau kode sumber.

Opsi

Paling cocok untuk

Kelebihan

Kekurangan

npm global

Komputer pengembang

Cepat, ringan, mudah dipanggil dari terminal

Bisa perlu compiler untuk modul native

Docker

VPS, server tim, homelab

Isolasi baik, mudah dicadangkan dan dipindah

Perlu memahami volume, port, dan jaringan

Desktop

Pengguna Windows, macOS, Linux

Antarmuka paling praktis, instalasi visual

Ukuran unduhan lebih besar

Kode sumber

Kontributor dan integrasi khusus

Kendali penuh atas build dan perubahan kode

Pemeliharaan lebih rumit

Portable Windows

Pengujian tanpa instalasi penuh

Bisa dijalankan langsung

Pengelolaan pembaruan lebih manual

Rekomendasi berdasarkan skenario

  • Laptop pribadi: pilih npm atau desktop.

  • Komputer kantor tanpa banyak akses terminal: pilih desktop.

  • VPS untuk beberapa anggota tim: pilih Docker.

  • Eksperimen terhadap kode internal: gunakan kode sumber.

  • Pengujian cepat di Windows: gunakan versi portable.

  • Server produksi internal: gunakan Docker dengan volume persisten, autentikasi kuat, TLS, dan pembatasan jaringan.

Step 1 — Periksa Node.js, npm, Git, dan Port

Jika Teman-Teman memilih jalur npm, buka terminal lalu jalankan:

BASH
node --version
npm --version
git --version

Contoh keluaran:

TEXT
v22.17.0
10.9.2
git version 2.47.1

Angka di komputer Teman-Teman tidak harus sama. Yang penting, versinya memenuhi persyaratan rilis OmniRoute yang sedang dipasang.

Kenapa pemeriksaan ini penting?

Modul seperti driver SQLite dapat menyertakan komponen native. Ketidakcocokan antara Node.js, arsitektur prosesor, dan binary dependency sering menyebabkan instalasi berhenti dengan pesan node-gyp, better-sqlite3, atau prebuild-install.

Selanjutnya, periksa apakah port 20128 sedang dipakai.

Windows PowerShell

POWERSHELL
Get-NetTCPConnection -LocalPort 20128 -ErrorAction SilentlyContinue

Linux

BASH
ss -ltnp | grep 20128

macOS

BASH
lsof -i :20128

Jika tidak ada keluaran, port biasanya masih tersedia.

Contoh ketika port sudah dipakai:

TEXT
node    4812 user   22u  IPv4  TCP localhost:20128 (LISTEN)

Catat nomor prosesnya. Jangan langsung mematikan proses jika belum tahu aplikasi apa yang menggunakannya.

Step 2 — Pasang Build Tools Bila Diperlukan

Langkah ini terutama penting jika npm tidak menemukan binary siap pakai dan harus mengompilasi modul native.

Ubuntu atau Debian

BASH
sudo apt update
sudo apt install -y build-essential python3 git

Keluaran yang diharapkan akan menampilkan pemasangan atau konfirmasi bahwa paket sudah tersedia:

TEXT
build-essential is already the newest version
python3 is already the newest version
git is already the newest version

macOS

BASH
xcode-select --install

Jika sudah terpasang, macOS akan memberi tahu bahwa command line tools tersedia.

Windows

Pasang Visual Studio Build Tools dengan komponen Desktop development with C++. Setelah selesai, tutup lalu buka kembali PowerShell agar perubahan lingkungan terbaca.

Kenapa langkah ini penting?

JavaScript dapat berjalan langsung melalui Node.js, tetapi beberapa paket memakai kode C atau C++ untuk kinerja dan akses sistem. Tanpa compiler, npm tidak dapat membangun modul tersebut ketika binary yang cocok tidak tersedia.

Step 3 — Instal OmniRoute dengan npm

npm logo png 10 free Cliparts | Download images on Clipground 2026

Jalankan:

BASH
npm install -g omniroute

Pemasangan global membuat perintah omniroute tersedia dari terminal mana pun.

Contoh keluaran:

TEXT
added 642 packages in 48s

Jumlah paket dan durasi dapat berbeda. Komputer dengan koneksi Indonesia yang mengakses registry luar negeri mungkin memerlukan waktu lebih lama.

Periksa apakah perintahnya dikenali:

BASH
omniroute --version

Contoh:

TEXT
3.8.46

Lalu lihat bantuan:

BASH
omniroute --help

Keluaran umumnya menampilkan daftar perintah yang tersedia, misalnya menjalankan server, menyiapkan integrasi CLI, atau mengelola koneksi.

Kenapa instalasi global dipilih?

Untuk gateway yang dipakai oleh banyak proyek lokal, instalasi global lebih praktis daripada memasang salinan di setiap repositori. Semua aplikasi dapat mengarah ke satu service yang sama.

Kesalahan umum: perintah tidak ditemukan

Pesan yang mungkin muncul:

TEXT
omniroute: command not found

atau di Windows:

TEXT
'omniroute' is not recognized as an internal or external command

Periksa lokasi binary global npm:

BASH
npm config get prefix

Lalu periksa apakah direktori binary tersebut masuk ke PATH.

Pada macOS atau Linux:

BASH
npm bin -g

Jika versi npm tidak mendukung perintah itu, gunakan:

BASH
npm prefix -g

Setelah memperbaiki PATH, tutup terminal dan buka kembali.

Step 4 — Jalankan OmniRoute untuk Pertama Kali

Mulai server:

BASH
omniroute

Pada versi tertentu, perintah eksplisitnya dapat berupa:

BASH
omniroute serve

Ikuti sintaks yang tampil pada omniroute --help, karena antarmuka CLI dapat berubah.

Keluaran yang diharapkan kurang lebih seperti:

TEXT
OmniRoute v3.8.x
Dashboard: http://localhost:20128/dashboard
API:       http://localhost:20128/v1
Server listening on port 20128

Biarkan terminal tetap terbuka selama pengujian pertama. Jika proses dihentikan dengan Ctrl+C, endpoint lokal juga berhenti.

Kenapa server lokal diperlukan?

Cursor, Cline, atau aplikasi lain tidak berbicara langsung ke setiap provider. Mereka mengirim permintaan ke OmniRoute pada port 20128, lalu OmniRoute meneruskannya ke target yang dipilih.

Alur sederhananya:

TEXT
Cursor
  ↓
http://localhost:20128/v1
  ↓
OmniRoute
  ↓
Provider dan model terpilih
  ↓
Respons kembali ke Cursor

Kesalahan umum: EADDRINUSE

Pesan:

TEXT
Error: listen EADDRINUSE: address already in use :::20128

Artinya, port tersebut sudah dipakai. Penyebab yang sering terjadi:

  • OmniRoute sudah berjalan di terminal lain.

  • Aplikasi desktop OmniRoute sedang aktif.

  • Container Docker masih berjalan.

  • Service lama belum berhenti.

  • Aplikasi lain kebetulan memakai port yang sama.

Cari prosesnya terlebih dahulu.

Linux atau macOS

BASH
lsof -i :20128

Windows

POWERSHELL
Get-NetTCPConnection -LocalPort 20128

Jika prosesnya memang OmniRoute yang sudah aktif, tidak perlu menjalankan salinan kedua. Aplikasi desktop juga memakai single-instance lock untuk mengurangi risiko benturan proses.

Step 5 — Buka Dashboard dan Selesaikan Konfigurasi Awal

Buka browser ke:

TEXT
http://localhost:20128/dashboard

Jika alamat tersebut tidak terbuka, coba:

TEXT
http://127.0.0.1:20128/dashboard

Perbedaan localhost dan 127.0.0.1 biasanya tidak penting, tetapi konfigurasi DNS lokal atau proxy kadang membuat salah satunya lebih andal.

Pada konfigurasi awal, dashboard dapat meminta Teman-Teman membuat kredensial pengelola. Gunakan kata sandi yang unik, terutama jika service kelak dibuka ke jaringan lokal atau server jarak jauh.

Kenapa keamanan dashboard penting?

Dashboard dapat mempunyai akses ke:

  • Kredensial provider

  • Pengaturan proxy

  • Token akses lokal

  • Daftar model

  • Riwayat penggunaan

  • Aturan routing

  • Fitur operasional service

Menganggap dashboard aman hanya karena berjalan di localhost adalah kebiasaan yang kurang tepat. Aplikasi lokal lain, ekstensi browser, atau salah konfigurasi reverse proxy tetap dapat memperbesar risiko.

Pengaturan awal yang disarankan

  • Buat kredensial pengelola yang kuat.

  • Jangan membuka port dashboard ke internet secara langsung.

  • Aktifkan autentikasi untuk endpoint yang digunakan aplikasi.

  • Simpan data directory di lokasi persisten.

  • Periksa pengaturan logging sebelum memproses data sensitif.

  • Nonaktifkan provider yang tidak akan digunakan.

  • Pisahkan token pengguna dan token pengelola jika tersedia.

Step 6 — Tambahkan Provider Pertama

Untuk pengujian, pilih provider yang aksesnya memang Teman-Teman miliki. Jalur paling aman adalah API resmi atau OAuth yang didukung secara jelas.

Buka menu Providers, pilih provider, lalu ikuti metode autentikasinya.

Metode koneksi dapat berupa:

  • API key

  • OAuth

  • Session cookie

  • Kredensial lokal

  • Endpoint OpenAI-compatible

  • Provider lokal seperti Ollama atau LM Studio

Untuk percobaan, Teman-Teman dapat memakai provider dengan tingkat gratis yang tersedia di wilayah dan akun masing-masing. Ketersediaan tingkat gratis dapat berubah, jadi jangan menjadikannya satu-satunya fondasi layanan penting.

Contoh alur dengan Gemini

  1. Buka halaman provider.

  2. Pilih integrasi Gemini yang sesuai.

  3. Tekan tombol koneksi atau autentikasi.

  4. Selesaikan OAuth di browser.

  5. Kembali ke dashboard.

  6. Pastikan status koneksi menjadi sehat.

  7. Sinkronkan model jika diminta.

Status yang diharapkan:

TEXT
Connected
Healthy
Models available

Kenapa mulai dari satu provider?

Menambahkan sepuluh provider sekaligus membuat diagnosis sulit. Jika permintaan gagal, Teman-Teman tidak langsung tahu apakah masalahnya ada pada API key, nama model, aturan combo, format request, atau jaringan.

Mulailah dengan satu jalur yang sederhana. Setelah satu request berhasil, baru tambahkan fallback.

Kesalahan umum: API key ditolak

Pesan dapat berupa:

TEXT
401 Unauthorized
Invalid API key
Authentication failed

Periksa hal berikut:

  • Tidak ada spasi sebelum atau sesudah API key.

  • Key berasal dari proyek atau akun yang benar.

  • Provider memang mengaktifkan API tersebut.

  • Billing atau tingkat gratis masih aktif.

  • Key belum dicabut.

  • Base URL sesuai dokumentasi provider.

  • Waktu sistem komputer tidak melenceng jauh.

Jangan menempelkan API key ke issue publik, tangkapan layar, atau log yang akan dibagikan.

Step 7 — Buat Kunci API Lokal OmniRoute

Kunci provider dan kunci OmniRoute adalah dua hal berbeda.

  • Kunci provider dipakai OmniRoute untuk berkomunikasi dengan layanan AI.

  • Kunci OmniRoute dipakai Cursor atau aplikasi lain untuk mengakses gateway.

Buka menu pengelolaan API key di dashboard, lalu buat token baru. Beri nama yang menjelaskan pemakaiannya, misalnya:

TEXT
cursor-laptop-alama

atau:

TEXT
tim-backend-jakarta

Salin token ketika ditampilkan dan simpan di password manager.

Contoh bentuk token:

TEXT
omr_xxxxxxxxxxxxxxxxxxxxxxxxx

Bentuk sebenarnya dapat berbeda antarversi.

Kenapa setiap aplikasi sebaiknya punya token sendiri?

Token terpisah memudahkan Teman-Teman untuk:

  • Mencabut akses satu perangkat tanpa mengganggu perangkat lain.

  • Melacak penggunaan per aplikasi.

  • Menetapkan scope berbeda.

  • Membatasi dampak jika token bocor.

  • Memisahkan lingkungan pengembangan dan produksi.

Jangan memakai token pengelola sebagai token harian jika token dengan hak lebih sempit sudah cukup.

Step 8 — Uji Endpoint /v1/models

Sebelum menghubungkan IDE, uji gateway dengan curl.

BASH
curl http://localhost:20128/v1/models \
  -H "Authorization: Bearer OMNIROUTE_API_KEY"

Ganti OMNIROUTE_API_KEY dengan token lokal yang dibuat pada langkah sebelumnya.

Contoh keluaran:

JSON
{
  "object": "list",
  "data": [
    {
      "id": "auto",
      "object": "model",
      "owned_by": "omniroute"
    },
    {
      "id": "gemini-cli/gemini-2.5-pro",
      "object": "model",
      "owned_by": "gemini-cli"
    }
  ]
}

Nama model di akun Teman-Teman bisa berbeda. Gunakan ID yang benar-benar muncul dari endpoint tersebut, bukan nama yang disalin dari tutorial lama.

PowerShell

Di PowerShell, gunakan:

POWERSHELL
$headers = @{
  Authorization = "Bearer OMNIROUTE_API_KEY"
}

Invoke-RestMethod `
  -Uri "http://localhost:20128/v1/models" `
  -Headers $headers `
  -Method Get

Kenapa pengujian model penting?

Request ini menguji empat hal sekaligus:

  • Server aktif.

  • Port dapat dijangkau.

  • Token OmniRoute valid.

  • Katalog model berhasil dibentuk.

Jika langkah ini gagal, belum ada gunanya mengubah pengaturan Cursor. Selesaikan masalah gateway terlebih dahulu.

Step 9 — Kirim Chat Completion Pertama

Pilih salah satu model dari /v1/models, lalu kirim request:

BASH
curl http://localhost:20128/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer OMNIROUTE_API_KEY" \
  -d '{
    "model": "auto",
    "messages": [
      {
        "role": "user",
        "content": "Buat fungsi JavaScript untuk menjumlahkan angka positif dalam array."
      }
    ],
    "stream": false
  }'

Contoh respons:

JSON
{
  "id": "chatcmpl-example",
  "object": "chat.completion",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "function sumPositive(values) {\n  return values.reduce((total, value) => value > 0 ? total + value : total, 0);\n}"
      },
      "finish_reason": "stop"
    }
  ]
}

Kenapa memakai auto?

Model ID auto meminta OmniRoute memilih jalur yang sesuai dari koneksi yang tersedia. Ini berguna setelah provider dan routing dikonfigurasi dengan benar.

Untuk diagnosis awal, model spesifik sering lebih baik:

JSON
{
  "model": "provider-id/model-id"
}

Model spesifik mengurangi variabel. Jika model spesifik berhasil tetapi auto gagal, masalah kemungkinan ada di katalog kandidat atau aturan auto-routing.

Step 10 — Hubungkan Cursor ke OmniRoute

Di Cursor, buka pengaturan model atau konfigurasi API OpenAI-compatible. Nama menunya dapat berubah mengikuti versi aplikasi.

Masukkan:

TEXT
Base URL: http://localhost:20128/v1
API Key:   OMNIROUTE_API_KEY
Model:     auto

Pastikan /v1 ikut ditulis. Kesalahan yang sering terjadi adalah hanya memasukkan:

TEXT
http://localhost:20128

Padahal aplikasi mengharapkan root endpoint API berada di /v1.

Kenapa Cursor bisa memakai OmniRoute?

Cursor dapat berbicara dengan layanan yang meniru kontrak API OpenAI. OmniRoute menyediakan endpoint tersebut, lalu menerjemahkan permintaan ke format provider tujuan jika dibutuhkan.

Alurnya:

TEXT
Cursor menggunakan format OpenAI
        ↓
OmniRoute menerima request
        ↓
Request diterjemahkan bila provider memakai format lain
        ↓
Provider memproses prompt
        ↓
Respons dinormalisasi kembali
        ↓
Cursor menampilkan jawaban

Uji dari Cursor

Buat percakapan baru dan kirim:

TEXT
Buat file Python sederhana yang membaca CSV dan menghitung jumlah nilai pada kolom total.

Di dashboard OmniRoute, buka pemantauan request. Jika berhasil, Teman-Teman akan melihat request masuk, provider yang terpilih, model, latensi, dan status respons.

Kesalahan umum: model tidak ditemukan

Pesan:

TEXT
Model not found

atau:

TEXT
invalid model id

Solusinya:

  1. Jalankan ulang GET /v1/models.

  2. Salin ID model persis seperti yang dikembalikan.

  3. Perhatikan huruf besar dan kecil.

  4. Sinkronkan katalog provider.

  5. Pastikan koneksi provider sehat.

  6. Coba auto jika combo otomatis tersedia.

Jangan mengandalkan nama model dari video lama. Katalog AI berubah cepat dan model preview sering diganti atau dihentikan.

Step 11 — Hubungkan Aplikasi OpenAI-Compatible Lain

Konsep yang sama berlaku untuk Cline, Continue, Roo Code, Aider, atau aplikasi lain yang menerima custom base URL.

Gunakan tiga nilai utama:

TEXT
Base URL: http://localhost:20128/v1
API Key:  token lokal OmniRoute
Model:    ID dari endpoint /v1/models

Beberapa aplikasi meminta alamat lengkap endpoint. Jika demikian, masukkan:

TEXT
http://localhost:20128/v1/chat/completions

Namun, kebanyakan aplikasi hanya meminta base URL.

Variabel lingkungan umum

Untuk aplikasi yang membaca variabel lingkungan:

macOS atau Linux

BASH
export OPENAI_BASE_URL="http://localhost:20128/v1"
export OPENAI_API_KEY="OMNIROUTE_API_KEY"

Windows PowerShell

POWERSHELL
$env:OPENAI_BASE_URL = "http://localhost:20128/v1"
$env:OPENAI_API_KEY = "OMNIROUTE_API_KEY"

Lalu jalankan alat dari terminal yang sama.

Kenapa variabel lingkungan berguna?

Pendekatan ini menghindari penulisan kredensial langsung di kode sumber. Teman-Teman juga dapat mengganti target gateway tanpa mengubah aplikasi.

Tetap berhati-hati karena variabel lingkungan bisa terlihat oleh proses lain, log CI, atau perintah debugging tertentu.

Step 12 — Buat Combo Fallback Pertama

Setelah satu provider bekerja, tambahkan provider kedua. Lalu buat combo berisi dua atau tiga target.

Contoh rancangan:

Urutan

Target

Fungsi

1

Model langganan utama

Kualitas tertinggi

2

API berbiaya rendah

Cadangan ekonomis

3

Model tingkat gratis

Cadangan terakhir

Pilih strategi priority agar target dicoba sesuai urutan.

Contoh konsep:

YAML
name: coding-reliable
strategy: priority
targets:
  - provider: subscription-provider
    model: coding-model-primary
  - provider: low-cost-provider
    model: coding-model-secondary
  - provider: free-provider
    model: free-coding-model

Konfigurasi sebenarnya sebaiknya dibuat melalui dashboard agar cocok dengan skema versi yang sedang dipakai.

Kenapa combo lebih baik daripada mengganti model secara manual?

Combo memisahkan identitas model yang dipakai aplikasi dari detail provider di belakangnya. Cursor cukup memanggil satu nama combo, sementara OmniRoute menangani perpindahan target.

Ini memberi tiga manfaat:

  • Konfigurasi aplikasi tetap stabil.

  • Perubahan provider dilakukan dari satu dashboard.

  • Kegagalan dapat ditangani tanpa menghentikan alur kerja.

Uji fallback secara aman

Jangan sengaja merusak kredensial produksi. Buat koneksi pengujian atau gunakan target yang dapat dinonaktifkan sementara.

Langkah uji:

  1. Pastikan combo berhasil pada target pertama.

  2. Nonaktifkan target pertama melalui dashboard.

  3. Kirim request baru.

  4. Periksa apakah target kedua dipilih.

  5. Aktifkan kembali target pertama.

  6. Pastikan status kesehatan pulih.

Keluaran log yang diharapkan kurang lebih menunjukkan:

TEXT
Target 1 unavailable
Trying next target
Target 2 selected
Request completed

Step 13 — Pilih Strategi Routing yang Sesuai

OmniRoute menyediakan banyak strategi routing. Jumlahnya berkembang antarversi, jadi dashboard dan catatan rilis menjadi rujukan terbaik.

Strategi

Cara kerja

Cocok untuk

priority

Memilih target sesuai urutan

Model utama dan fallback

round-robin

Bergantian antar target

Membagi beban secara merata

weighted

Memilih sesuai bobot

Pembagian trafik yang terkontrol

least-used

Memilih target dengan beban lebih rendah

Banyak koneksi aktif

cost-optimized

Mengutamakan biaya lebih rendah

Pengendalian anggaran

headroom

Mengutamakan sisa kuota

Banyak akun dengan batas berbeda

context-optimized

Menyesuaikan kapasitas konteks

Prompt panjang

lkgp

Menjaga jalur terakhir yang berhasil

Stabilitas percakapan

auto

Menilai beberapa faktor secara dinamis

Konfigurasi umum

fusion

Meminta beberapa model lalu menyintesis hasil

Analisis bernilai tinggi

pipeline

Menjalankan target secara berurutan

Alur tinjau dan perbaikan

Prioritas

Gunakan priority jika Teman-Teman sudah tahu model yang diinginkan. Strategi ini paling mudah dijelaskan dan diaudit.

Contoh:

TEXT
1. Model langganan
2. API murah
3. Model gratis

Round-robin

Gunakan round-robin untuk menyebarkan request ke beberapa koneksi yang setara.

Contoh:

TEXT
Request 1 → Account A
Request 2 → Account B
Request 3 → Account C
Request 4 → Account A

Jangan memakai strategi ini untuk mengakali batas yang secara jelas dilarang oleh provider. Gunakan hanya pada akun dan skenario yang sesuai ketentuan layanan.

Cost-optimized

Strategi ini menarik untuk aplikasi bertrafik besar, tetapi data harga harus akurat. Model yang terlihat murah belum tentu lebih hemat jika membutuhkan prompt lebih panjang, menghasilkan jawaban berulang, atau sering gagal.

Fusion

Fusion mengirim tugas ke beberapa model, lalu menggunakan model penilai untuk menggabungkan jawaban. Kualitas dapat meningkat, tetapi biaya dan latensi juga naik.

Pakai fusion untuk:

  • Tinjauan arsitektur penting

  • Analisis risiko

  • Perbandingan solusi

  • Keputusan yang layak mendapat pendapat kedua

Jangan jadikan fusion sebagai default untuk autocomplete atau tugas singkat.

Pipeline

Strategi pipeline menjalankan model secara berurutan. Misalnya:

  1. Model A menyusun solusi.

  2. Model B memeriksa kelemahan.

  3. Model C memperbaiki jawaban akhir.

Ini cocok untuk proses tinjau kode, tetapi kesalahan di tahap awal dapat ikut terbawa. Beri instruksi yang jelas pada setiap langkah.

Step 14 — Aktifkan Kompresi dengan Hati-Hati

OmniRoute menawarkan kompresi prompt melalui RTK, Caveman, dan mesin lain. Klaim penghematan berada di kisaran 15–95% untuk konten yang memenuhi syarat, terutama keluaran alat yang panjang dan berulang.

Angka tersebut bukan jaminan untuk setiap prompt. Kode pendek, instruksi presisi, dan percakapan ringkas mungkin tidak memperoleh penghematan berarti.

Contoh sebelum kompresi

TEXT
The function should iterate over the list of items, and for each item,
it should check whether the value is greater than zero, and if so,
add it to the running total.

Contoh setelah kompresi agresif

TEXT
Sum all list items where value > 0.

Maknanya masih mirip, tetapi tidak semua teks aman dipadatkan seperti ini.

Konten yang cocok dikompresi

  • Log build yang berulang

  • Hasil git diff yang panjang

  • Keluaran test runner

  • Daftar file

  • JSON besar dengan struktur berulang

  • Konteks percakapan yang menduplikasi informasi

  • Pesan alat yang mengandung banyak boilerplate

Konten yang perlu dijaga

  • Instruksi sistem

  • Persyaratan hukum

  • Angka keuangan

  • Kontrak API

  • Kode yang sensitif terhadap karakter

  • Stack trace yang sedang didiagnosis

  • Prompt dengan contoh format presisi

  • Data medis atau keselamatan

Cara menguji kompresi

  1. Ambil sepuluh sampai dua puluh prompt yang mewakili pekerjaan nyata.

  2. Jalankan tanpa kompresi.

  3. Catat token, latensi, biaya, dan kualitas.

  4. Aktifkan tingkat kompresi ringan.

  5. Jalankan prompt yang sama.

  6. Bandingkan hasil secara manual.

  7. Naikkan tingkat hanya jika kualitas tetap terjaga.

Kompresi yang bagus bukan sekadar menghasilkan token lebih sedikit. Informasi penting harus tetap sampai ke model.

Step 15 — Gunakan MCP untuk Integrasi Agen

OmniRoute memiliki server MCP yang dapat mengekspos fungsi gateway sebagai alat. Dokumentasi proyek menyebut puluhan alat dalam berbagai scope, mencakup routing, provider, quota, memory, dan compression.

Contoh alamat MCP HTTP:

TEXT
http://localhost:20128/api/mcp/stream

Periksa alamat yang benar pada dashboard atau dokumentasi versi yang dipakai.

Contoh penambahan ke Claude Code dapat terlihat seperti:

BASH
claude mcp add omniroute \
  --type http \
  --url http://localhost:20128/api/mcp/stream

Keluaran yang diharapkan:

TEXT
MCP server "omniroute" added
Connection successful

Kenapa scope MCP penting?

Agen yang hanya perlu melihat kesehatan provider tidak harus mendapat hak untuk mengubah routing atau kredensial. Gunakan prinsip least privilege, yaitu memberi izin sekecil mungkin untuk menyelesaikan tugas.

Contoh pembagian:

Kebutuhan

Scope yang sebaiknya diberikan

Melihat model

Baca katalog

Memeriksa kuota

Baca penggunaan

Memantau kesehatan

Baca status

Mengubah combo

Kelola routing

Mengelola kredensial

Hak administratif khusus

Jangan memberi akses administratif penuh kepada agen hanya karena konfigurasi tersebut lebih cepat.

Step 16 — Pasang OmniRoute dengan Docker

Untuk server atau VPS, Docker sering menjadi pilihan yang lebih mudah dipelihara. Image resminya tersedia melalui Docker Hub OmniRoute.

Tarik image:

BASH
docker pull diegosouzapw/omniroute:latest

Buat direktori data:

BASH
mkdir -p "$HOME/omniroute-data"

Jalankan container:

BASH
docker run -d \
  --name omniroute \
  --restart unless-stopped \
  -p 127.0.0.1:20128:20128 \
  -v "$HOME/omniroute-data:/app/data" \
  diegosouzapw/omniroute:latest

Periksa status:

BASH
docker ps --filter name=omniroute

Contoh keluaran:

TEXT
CONTAINER ID   IMAGE                                  STATUS
a1b2c3d4e5f6   diegosouzapw/omniroute:latest         Up 20 seconds

Lihat log:

BASH
docker logs -f omniroute

Kenapa port diikat ke 127.0.0.1?

Konfigurasi berikut:

TEXT
127.0.0.1:20128:20128

membuat service hanya dapat diakses dari server itu sendiri. Ini lebih aman untuk konfigurasi awal daripada:

TEXT
0.0.0.0:20128:20128

yang dapat membuka port ke semua antarmuka jaringan.

Untuk akses tim, letakkan reverse proxy dengan HTTPS dan autentikasi di depan OmniRoute. Jangan membuka dashboard mentah ke internet.

Kenapa volume wajib?

Tanpa volume persisten, data dapat hilang ketika container dihapus atau dibuat ulang.

Bagian ini:

BASH
-v "$HOME/omniroute-data:/app/data"

menyimpan data di host. Sesuaikan path jika image versi yang dipakai mendokumentasikan direktori data berbeda.

Docker Compose

Buat compose.yaml:

YAML
services:
  omniroute:
    image: diegosouzapw/omniroute:latest
    container_name: omniroute
    restart: unless-stopped
    ports:
      - "127.0.0.1:20128:20128"
    volumes:
      - ./data:/app/data
    environment:
      DATA_DIR: /app/data

Jalankan:

BASH
docker compose up -d

Lihat log:

BASH
docker compose logs -f

Hentikan:

BASH
docker compose down

Perintah terakhir tidak menghapus direktori ./data, selama Teman-Teman tidak menambahkan opsi penghapusan volume yang tidak diperlukan.

Step 17 — Pasang Aplikasi Desktop

Aplikasi desktop tersedia untuk Windows, macOS, dan Linux melalui halaman rilis GitHub.

Windows

Pilihan umumnya:

  • Installer NSIS berformat .exe

  • Versi portable OmniRoute.exe

Langkah pemasangan:

  1. Buka halaman rilis resmi.

  2. Pilih rilis terbaru yang stabil.

  3. Unduh installer Windows.

  4. Jalankan installer.

  5. Ikuti petunjuk.

  6. Buka OmniRoute.

  7. Pastikan dashboard dapat dimuat.

Versi portable dapat dijalankan langsung tanpa wizard pemasangan.

macOS

Pilih file DMG sesuai prosesor:

  • Intel atau x64

  • Apple Silicon atau arm64

Langkahnya:

  1. Unduh DMG.

  2. Buka file.

  3. Seret aplikasi ke folder /Applications.

  4. Jalankan OmniRoute.

  5. Izinkan aplikasi melalui pengaturan keamanan jika macOS meminta konfirmasi.

Linux

Pilihan umumnya:

  • AppImage

  • Paket Debian .deb

Untuk AppImage:

BASH
chmod +x OmniRoute-*.AppImage
./OmniRoute-*.AppImage

Untuk paket Debian:

BASH
sudo apt install ./omniroute-desktop_*_amd64.deb

Kenapa desktop menarik?

Aplikasi desktop membungkus server dan dashboard dalam paket yang lebih mudah dijalankan. Ini cocok ketika Teman-Teman ingin pengalaman visual tanpa mengelola npm secara manual.

Kekurangannya, ukuran paket lebih besar dan pembaruan tetap perlu diperhatikan. Unduh hanya dari rilis resmi serta cocokkan checksum jika tersedia.

Step 18 — Jalankan OmniRoute dari Kode Sumber

Untuk memeriksa kode, membuat integrasi, atau berkontribusi, clone repositorinya:

BASH
git clone https://github.com/diegosouzapw/OmniRoute.git
cd OmniRoute

Periksa branch dan commit:

BASH
git status
git log -1 --oneline

Pasang dependensi berdasarkan package manager yang ditetapkan repositori. Jika lockfile npm digunakan:

BASH
npm ci

Lihat script yang tersedia:

BASH
npm run

Jalankan mode pengembangan sesuai README.md, misalnya:

BASH
npm run dev

Keluaran yang diharapkan biasanya menunjukkan server dashboard dan API mulai berjalan.

Kenapa memakai npm ci?

npm ci memasang versi persis dari lockfile dan lebih konsisten untuk build ulang. Perintah ini cocok untuk CI, pengujian, serta reproduksi masalah.

Jangan menebak perintah build

Repositori aktif dapat mengubah script, struktur monorepo, dan persyaratan runtime. Selalu periksa:

  • README.md

  • CONTRIBUTING.md

  • AGENTS.md

  • package.json

  • .env.example

  • Catatan rilis

Step 19 — Konfigurasikan Akses Jarak Jauh dengan Aman

Remote mode memungkinkan satu OmniRoute di server dipakai dari komputer lain. Ini berguna bagi tim yang ingin berbagi konfigurasi provider dan routing.

Namun, akses jarak jauh memperbesar permukaan serangan. Teman-Teman perlu memisahkan akses jaringan, autentikasi, dan enkripsi.

Pilihan aman untuk pengujian: SSH tunnel

Dari laptop, jalankan:

BASH
ssh -L 20128:127.0.0.1:20128 [email protected]

Lalu buka:

TEXT
http://localhost:20128/dashboard

Traffic diteruskan melalui koneksi SSH ke OmniRoute yang hanya mendengarkan di loopback server.

Kenapa SSH tunnel berguna?

  • Tidak perlu membuka port 20128 ke internet.

  • Traffic mendapat enkripsi dari SSH.

  • Konfigurasi awal lebih sederhana daripada reverse proxy publik.

  • Cocok untuk satu atau beberapa pengelola.

Reverse proxy untuk tim

Untuk penggunaan lebih luas, gunakan:

  • HTTPS

  • Sertifikat valid

  • Autentikasi kuat

  • Pembatasan IP atau VPN

  • Rate limiting

  • Log keamanan

  • Token dengan scope terbatas

Jangan menaruh kunci provider di konfigurasi reverse proxy atau kode klien.

Antigravity pada server jarak jauh

OAuth desktop sering memakai callback ke 127.0.0.1. Pada VPS, callback tersebut mengarah ke mesin server, bukan laptop tempat browser dibuka.

OmniRoute menyediakan helper:

BASH
omniroute login antigravity

Helper menjalankan OAuth di mesin lokal, menukar kode, lalu menghasilkan blob kredensial satu baris dengan bentuk seperti:

TEXT
omniroute-cred-v1....

Blob tersebut kemudian ditempelkan ke langkah koneksi Antigravity pada dashboard server.

Kenapa pendekatan ini diperlukan?

Google native atau desktop OAuth mengandalkan loopback lokal. Menjalankan proses autentikasi di laptop membuat callback 127.0.0.1 kembali ke mesin yang benar.

Perlakukan blob kredensial seperti password. Jangan kirim melalui grup percakapan, email tanpa enkripsi, atau tiket dukungan publik.

Step 20 — Sesuaikan Deployment untuk Kondisi Indonesia

Lokasi server memengaruhi latensi dari pengguna ke gateway, tetapi bukan satu-satunya faktor. Setelah request mencapai gateway, OmniRoute masih harus menghubungi provider yang mungkin berada di Singapura, Tokyo, Eropa, atau Amerika Serikat.

Untuk tim di Indonesia, pola yang praktis biasanya:

  • Laptop lokal untuk penggunaan pribadi.

  • VPS Jakarta untuk akses internal domestik.

  • VPS Singapura untuk konektivitas regional yang sering lebih stabil ke provider global.

  • VPN perusahaan untuk mengakses dashboard.

  • Cache dan kompresi untuk mengurangi payload berulang.

  • Provider lokal atau model self-hosted jika kebijakan data menuntutnya.

Jakarta versus Singapura

Pertimbangan

VPS Jakarta

VPS Singapura

Latensi dari pengguna Indonesia

Umumnya lebih rendah

Biasanya tetap cukup baik

Jalur ke provider global

Bergantung operator

Sering punya peering internasional lebih luas

Pilihan penyedia cloud

Bertambah, tetapi lebih terbatas

Sangat banyak

Kebutuhan residensi data

Lebih sesuai untuk kebutuhan domestik tertentu

Perlu kajian kebijakan lintas negara

Biaya

Bervariasi

Kompetitif, tetapi dibayar dalam mata uang asing

Jangan memilih lokasi hanya berdasarkan ping ke gateway. Uji alur lengkap:

TEXT
Laptop → Gateway → Provider → Gateway → Laptop

Catat waktu respons awal, durasi streaming, tingkat kegagalan, dan konsistensi pada jam sibuk.

Step 21 — Ukur Hasil dengan Metrik yang Masuk Akal

Klaim besar seperti “hemat 95%” tidak boleh langsung dijadikan proyeksi anggaran. Penghematan bergantung pada bentuk prompt, model, provider, dan konfigurasi compression.

Gunakan metrik berikut:

  • Tingkat keberhasilan request

  • Persentase request yang membutuhkan fallback

  • Latensi median

  • Latensi persentil ke-95

  • Token input sebelum dan setelah compression

  • Biaya per satu juta token

  • Biaya per tugas selesai

  • Waktu gangguan akibat kuota

  • Jumlah perpindahan konfigurasi manual

  • Waktu yang dibutuhkan untuk memulihkan provider

Contoh tabel pengujian:

Metrik

Sebelum gateway

Setelah OmniRoute

Perubahan

Request berhasil

94,0%

98,7%

+4,7 poin

Gangguan karena kuota

6 kali/bulan

1 kali/bulan

Turun 83%

Token input rata-rata

18.000

12.600

Turun 30%

Latensi median

2,8 detik

3,1 detik

Naik 0,3 detik

Pergantian konfigurasi manual

14 kali/bulan

2 kali/bulan

Turun 86%

Angka di atas adalah contoh format pengukuran, bukan jaminan hasil. MUGHU menyarankan Teman-Teman membuat baseline dari pekerjaan sendiri selama satu sampai dua minggu.

Kenapa biaya per tugas lebih penting?

Model murah yang menghasilkan jawaban buruk dapat memerlukan tiga kali percobaan. Dalam situasi itu, harga per token rendah belum tentu menghasilkan biaya operasional lebih kecil.

Ukur satuan yang mendekati hasil bisnis, misalnya:

  • Biaya per pull request

  • Waktu per perbaikan bug

  • Biaya per ringkasan dokumen

  • Waktu penyelesaian tiket

  • Jumlah intervensi manual

Studi Kasus: Tim Pengembang dengan Tiga Provider

Background

Sebuah tim perangkat lunak kecil memakai tiga layanan AI. Model utama memberi hasil coding terbaik, provider kedua lebih murah, dan provider ketiga mempunyai tingkat gratis.

Setiap anggota tim mengatur API sendiri di Cursor. Ketika kuota model utama habis, semua orang mengganti base URL secara manual.

Challenge atau Problem

Tim menghadapi empat masalah:

  • Konfigurasi berbeda antaranggota.

  • Tidak ada fallback otomatis.

  • Kunci API tersebar di banyak perangkat.

  • Tidak ada data terpusat tentang provider yang paling sering gagal.

Gangguan rata-rata sepuluh menit terasa kecil. Namun, jika terjadi tiga kali per minggu pada lima orang, waktu hilang dapat mencapai 150 menit per minggu.

Approach

Tim menempatkan OmniRoute pada server internal dan membuat tiga lapisan target:

  1. Model langganan utama.

  2. Model API berbiaya rendah.

  3. Model gratis untuk cadangan.

Akses dashboard dibatasi melalui VPN. Setiap anggota mendapat token OmniRoute sendiri dengan scope penggunaan API.

Implementation

Tahap penerapannya:

  1. Pasang container OmniRoute dengan volume persisten.

  2. Tambahkan tiga koneksi provider.

  3. Verifikasi satu model dari setiap provider.

  4. Buat combo coding-team.

  5. Pilih strategi priority.

  6. Atur model berlangganan sebagai target pertama.

  7. Atur provider murah sebagai target kedua.

  8. Atur provider gratis sebagai target ketiga.

  9. Hubungkan Cursor semua anggota ke endpoint yang sama.

  10. Aktifkan log operasional tanpa menyimpan data sensitif berlebihan.

  11. Uji fallback dalam jendela pemeliharaan.

  12. Pantau hasil selama dua minggu.

Konfigurasi klien menjadi seragam:

TEXT
Base URL: https://ai-gateway.internal.example/v1
Model: coding-team
API Key: token per pengguna

Results

Setelah penerapan, perubahan konfigurasi provider dilakukan di satu tempat. Anggota tim tidak perlu mengetahui detail API key provider.

Metrik yang layak dipantau meliputi:

  • Penurunan perpindahan manual

  • Peningkatan tingkat keberhasilan

  • Tambahan latensi gateway

  • Persentase traffic per provider

  • Biaya rata-rata per request

  • Jumlah fallback per hari

Dalam skenario seperti ini, ROI paling nyata biasanya berasal dari waktu kerja yang tidak terputus, bukan semata-mata token gratis.

Key Learnings

  • Mulai dari dua provider sebelum menambah katalog besar.

  • Tetapkan satu target utama yang jelas.

  • Jangan mencampurkan provider sensitif dan provider eksperimen dalam combo yang sama.

  • Uji fallback sebelum mengandalkannya.

  • Buat token per pengguna atau perangkat.

  • Pantau kualitas jawaban, bukan hanya status HTTP.

  • Simpan cadangan data directory dan konfigurasi.

Perbandingan OmniRoute, LiteLLM, OpenRouter, dan API Langsung

Tidak ada alat yang selalu paling baik. Pilihan harus mengikuti kebutuhan operasional, tata kelola data, dan kapasitas tim.

Kriteria

OmniRoute

LiteLLM

OpenRouter

API provider langsung

Model deployment

Self-hosted

Self-hosted atau layanan terkait

Managed

Managed oleh provider

Satu endpoint

Ya

Ya

Ya

Tidak lintas provider

Banyak provider

Sangat luas

Luas

Banyak model terkelola

Satu ekosistem

Auto-fallback

Ya

Ya

Tergantung fitur routing

Harus dibuat sendiri

Dashboard lokal

Ya

Tersedia pada deployment tertentu

Dashboard cloud

Dashboard provider

MCP dan A2A

Terintegrasi dalam OmniRoute

Fokus utama berbeda

Bukan fokus utama

Bergantung provider

Kompresi prompt

RTK, Caveman, dan pipeline terkait

Bergantung konfigurasi

Bukan fungsi utama

Dibuat sendiri

Tanggung jawab operasi

Pengguna

Pengguna

Penyedia layanan

Provider

Kendali data gateway

Tinggi

Tinggi

Lebih rendah

Bergantung provider

SLA komersial

Tidak selalu tersedia

Tergantung produk atau paket

Bergantung layanan

Sering tersedia

Cocok untuk

Eksperimen multi-provider dan routing lokal

Proxy produksi yang dapat disesuaikan

Akses model terkelola

Kepatuhan satu vendor

Pilih OmniRoute jika

  • Teman-Teman ingin local-first gateway.

  • Banyak provider dan akun perlu disatukan.

  • Auto-fallback serta combo menjadi kebutuhan utama.

  • Integrasi alat coding penting.

  • Kompresi dan MCP ingin dikelola dalam satu sistem.

  • Tim siap memelihara service sendiri.

Pilih LiteLLM jika

  • Tim membutuhkan proxy yang sudah dikenal luas dalam arsitektur aplikasi.

  • Integrasi observability dan pola deployment Python lebih cocok.

  • Tim punya pengalaman operasional dengan stack tersebut.

  • Kebutuhan produksi lebih menitikberatkan proxy API daripada desktop coding workflow.

Pilih OpenRouter jika

  • Teman-Teman ingin layanan terkelola.

  • Tidak ingin menjalankan server sendiri.

  • Satu billing dan katalog model lebih penting daripada kontrol lokal.

  • Kebijakan organisasi mengizinkan perantara cloud tambahan.

Pilih API langsung jika

  • Kepatuhan mengharuskan satu vendor.

  • Tim membutuhkan SLA dan dukungan resmi provider.

  • Arsitektur sederhana lebih penting daripada fallback lintas penyedia.

  • Beban kerja bergantung pada fitur khusus yang tidak selalu diterjemahkan sempurna oleh gateway.

Rekomendasi akhir berdasarkan use case

Use case

Rekomendasi

Coding pribadi dengan beberapa provider

OmniRoute lokal

Tim kecil dengan server internal

OmniRoute Docker

SaaS produksi dengan kebutuhan proxy matang

Evaluasi OmniRoute dan LiteLLM melalui uji beban

Akses cepat tanpa mengelola infrastruktur

OpenRouter

Data sangat sensitif dan satu vendor disetujui

API langsung

Model sepenuhnya lokal

OmniRoute dengan Ollama/LM Studio atau akses langsung ke runtime lokal

Organisasi membutuhkan SLA resmi

Provider langsung atau gateway komersial dengan kontrak

Kelebihan OmniRoute

Satu konfigurasi untuk banyak alat

Alamat API tidak perlu berubah ketika target provider berubah. Ini mengurangi beban konfigurasi pada Cursor, Cline, Codex, dan alat lain.

Ketahanan berlapis

OmniRoute tidak hanya mengenal fallback daftar model. Arsitekturnya memisahkan masalah pada tingkat provider, connection, dan model.

Jika satu model bermasalah, model lain pada provider yang sama masih dapat tersedia. Jika satu connection terkena cooldown, akun lain tidak harus ikut berhenti.

Banyak strategi routing

Tim dapat memilih antara kestabilan, biaya, pembagian beban, sisa kuota, atau kualitas. Fleksibilitas ini berguna ketika penggunaan AI sudah cukup besar untuk memerlukan kebijakan.

Local-first

Konfigurasi dan data operasional dapat disimpan pada lingkungan yang dikelola sendiri. Ini memberi kontrol lebih tinggi dibanding gateway cloud terkelola.

Dukungan protokol luas

OpenAI-compatible API mempermudah integrasi aplikasi. MCP dan A2A memperluas pemakaian ke agen yang dapat mengelola atau mengamati gateway.

Pilihan deployment beragam

npm cocok untuk laptop, desktop cocok untuk pengalaman visual, dan Docker cocok untuk server.

Kekurangan dan Batasan OmniRoute

Kompleksitas meningkat seiring jumlah provider

Ratusan provider terdengar menarik, tetapi setiap koneksi menambah kemungkinan kegagalan, perubahan autentikasi, perbedaan format, dan kebutuhan pemantauan.

Katalog besar tidak berarti Teman-Teman harus mengaktifkan semuanya.

Tidak menghapus tanggung jawab terhadap syarat provider

Fitur routing tidak otomatis membuat semua cara akses diizinkan. Tinjau syarat penggunaan, pembatasan akun, kebijakan proxy, dan aturan penggunaan komersial.

Local-first bukan berarti data tidak keluar

Prompt tetap dikirim ke provider eksternal, kecuali targetnya model lokal. Gateway lokal hanya mengontrol jalur dan penyimpanan pada lapisan perantara.

Tambahan latensi

Setiap lapisan routing, translation, logging, dan compression dapat menambah waktu pemrosesan. Pada jaringan yang baik, tambahan tersebut mungkin kecil, tetapi tetap harus diukur.

Proyek berkembang cepat

Rilis yang sering memberi banyak fitur, tetapi juga menuntut disiplin saat memperbarui. Konfigurasi lama perlu diuji sebelum dibawa ke versi baru.

Tidak selalu mempunyai SLA perusahaan

Untuk aplikasi kritis, tim perlu menilai dukungan, audit keamanan, kebijakan rilis, dan rencana pemulihan. Sumber terbuka yang aktif bukan pengganti kontrak layanan.

Kesalahan yang Sering Terjadi

Menggunakan base URL tanpa /v1

Salah:

TEXT
http://localhost:20128

Benar untuk kebanyakan klien OpenAI-compatible:

TEXT
http://localhost:20128/v1

Memakai API key provider di Cursor

Cursor harus menerima token OmniRoute, bukan kredensial provider mentah.

Salah:

TEXT
Cursor → API key Gemini

Benar:

TEXT
Cursor → token OmniRoute → OmniRoute → kredensial Gemini

Menyalin nama model dari tutorial lama

Model preview dapat diganti, dihentikan, atau diubah namanya. Selalu ambil daftar terbaru:

BASH
curl http://localhost:20128/v1/models \
  -H "Authorization: Bearer OMNIROUTE_API_KEY"

Mengaktifkan terlalu banyak provider sekaligus

Mulai dari satu, uji, lalu tambah satu per satu. Cara ini membuat sumber masalah lebih mudah ditemukan.

Membuka dashboard ke internet tanpa perlindungan

Binding ke 0.0.0.0 bukan pengganti desain akses yang aman. Gunakan VPN, SSH tunnel, atau reverse proxy HTTPS dengan autentikasi.

Menganggap model gratis selalu tersedia

Tingkat gratis dapat berubah, terkena antrean, dibatasi wilayah, atau memiliki kebijakan penggunaan tertentu. Gunakan sebagai bagian dari strategi, bukan satu-satunya fondasi layanan penting.

Mengaktifkan compression agresif tanpa evaluasi

Token bisa turun, tetapi detail penting juga dapat hilang. Uji dengan prompt nyata dan cek kualitas keluaran.

Tidak mencadangkan data

Buat cadangan direktori data sebelum upgrade. Jangan mengandalkan snapshot container saja.

Troubleshooting Instalasi dan Runtime

npm ERR! code EACCES

Masalah ini muncul ketika npm global tidak punya izin menulis ke direktori sistem.

Hindari memakai sudo npm install -g sebagai solusi permanen tanpa memahami akibatnya. Lebih baik gunakan pengelola versi Node seperti nvm, atau ubah prefix npm ke direktori pengguna.

Contoh:

BASH
mkdir -p "$HOME/.npm-global"
npm config set prefix "$HOME/.npm-global"

Tambahkan ke PATH:

BASH
export PATH="$HOME/.npm-global/bin:$PATH"

Simpan baris tersebut di ~/.bashrc, ~/.zshrc, atau berkas konfigurasi shell yang sesuai.

Error node-gyp

Pesan dapat menyebut compiler, Python, atau header Node.js.

Periksa:

BASH
python3 --version
gcc --version
make --version
node --version

Pada Windows, pastikan komponen C++ Build Tools terpasang. Pada macOS, pastikan Xcode Command Line Tools aktif.

Cannot find module setelah upgrade

Bersihkan pemasangan global lalu pasang kembali:

BASH
npm uninstall -g omniroute
npm cache verify
npm install -g omniroute

Jangan menghapus seluruh cache secara agresif kecuali ada alasan jelas.

Dashboard kosong atau terus memuat

Periksa log server:

BASH
omniroute serve

atau untuk Docker:

BASH
docker logs --tail 200 omniroute

Periksa juga:

  • Status HTTP di browser developer tools

  • Kesalahan JavaScript

  • CSP

  • Reverse proxy

  • WebSocket

  • Cookie autentikasi

  • Versi frontend dan backend

Jika memakai reverse proxy, pastikan koneksi WebSocket diteruskan.

Request model menghasilkan 401

Bedakan dua kemungkinan:

  • 401 dari OmniRoute karena token lokal salah.

  • 401 dari provider karena kredensial upstream salah.

Lihat sumber error pada log. Jangan mengganti semua token sekaligus.

Request menghasilkan 429 Too Many Requests

Artinya ada batas permintaan atau kuota.

Tindakan yang dapat dilakukan:

  • Tunggu sampai cooldown selesai.

  • Periksa reset quota.

  • Gunakan combo fallback.

  • Kurangi concurrency.

  • Batasi request dari aplikasi.

  • Pakai model yang memiliki headroom lebih besar.

  • Pastikan retry tidak terlalu agresif.

Retry tanpa backoff dapat memperburuk masalah.

Request menghasilkan 402 atau 403

Kemungkinan penyebab:

  • Model berbayar dipilih pada akun tanpa billing.

  • Provider melarang akses model tersebut.

  • Wilayah tidak didukung.

  • Akun tidak punya paket yang diperlukan.

  • Kebijakan jaringan atau anti-bot menolak koneksi.

Jika ingin hanya menampilkan model gratis, gunakan pengaturan penyembunyian model berbayar bila tersedia pada versi yang dipakai.

Streaming terputus

Periksa:

  • Timeout reverse proxy

  • Buffering proxy

  • Koneksi WebSocket atau SSE

  • Batas waktu provider

  • Stabilitas jaringan

  • Format translation

  • Dukungan streaming klien

Untuk Nginx, buffering sering perlu dinonaktifkan pada endpoint streaming.

Contoh konsep:

NGINX
proxy_buffering off;
proxy_read_timeout 3600s;

Sesuaikan konfigurasi dengan lingkungan dan tinjauan keamanan.

Docker tidak dapat menulis data

Periksa izin direktori:

BASH
ls -ld "$HOME/omniroute-data"

Lihat pengguna di dalam container jika diperlukan:

BASH
docker exec omniroute id

Sesuaikan kepemilikan direktori dengan hati-hati. Jangan memberi izin 777 sebagai jalan pintas permanen.

Container terus restart

Periksa:

BASH
docker inspect omniroute \
  --format '{{.State. Status}} {{.State. ExitCode}} {{.State. Error}}'

Lalu:

BASH
docker logs --tail 300 omniroute

Penyebab umum:

  • Variabel lingkungan salah

  • Data directory tidak dapat ditulis

  • Migrasi basis data gagal

  • Port bentrok

  • Image tidak cocok dengan arsitektur

  • Memori server terlalu kecil

Tips Keamanan untuk Penggunaan Serius

Gunakan token terpisah

Buat token per pengguna, perangkat, atau aplikasi. Jangan berbagi satu token melalui grup tim.

Batasi scope

Aplikasi chat hanya membutuhkan akses inferensi. Akses pengelolaan provider dan konfigurasi sebaiknya dipisahkan.

Lindungi data directory

Direktori tersebut dapat berisi konfigurasi sensitif. Atur izin filesystem dan backup terenkripsi.

Jangan merekam semua prompt tanpa alasan

Logging penuh memang memudahkan debugging, tetapi juga dapat menyimpan source code, data pelanggan, dan rahasia internal.

Tentukan:

  • Data apa yang dicatat

  • Berapa lama disimpan

  • Siapa yang boleh membaca

  • Bagaimana data dihapus

  • Apakah prompt perlu disamarkan

Gunakan HTTPS untuk akses jaringan

HTTP lokal dapat diterima untuk pengujian loopback. Begitu traffic melewati jaringan, gunakan TLS.

Perbarui secara bertahap

Pola upgrade yang aman:

  1. Cadangkan data.

  2. Catat versi aktif.

  3. Baca release notes.

  4. Uji pada salinan staging.

  5. Verifikasi provider utama.

  6. Uji fallback.

  7. Pantau log.

  8. Baru terapkan ke lingkungan tim.

Verifikasi image dan binary

Unduh dari repositori dan registry resmi. Jika release menyediakan SHA-256, cocokkan checksum.

Contoh Linux:

BASH
sha256sum OmniRoute-3.8.46. AppImage

Contoh PowerShell:

POWERSHELL
Get-FileHash .\OmniRoute.exe -Algorithm SHA256

Bandingkan hasil dengan checksum pada halaman rilis.

Tips Performa dan Efisiensi

Jangan aktifkan semua fitur sekaligus

Setiap fitur observability, compression, memory, dan routing kompleks menambah pekerjaan. Mulailah dengan konfigurasi minimum.

Gunakan model spesifik untuk debugging

auto nyaman untuk pekerjaan harian, tetapi model spesifik lebih mudah dianalisis ketika terjadi error.

Pantau persentil, bukan hanya rata-rata

Rata-rata dapat menyembunyikan request yang sangat lambat. Catat median dan persentil ke-95.

Atur timeout berdasarkan jenis tugas

Autocomplete membutuhkan respons cepat. Analisis repositori dapat diberi timeout lebih panjang.

Bedakan traffic interaktif dan batch

Buat combo terpisah:

TEXT
coding-interactive
analysis-batch
documentation-cheap
review-high-quality

Traffic interaktif sebaiknya mengutamakan latensi. Batch dapat mengutamakan biaya.

Tempatkan gateway dekat pengguna atau provider

Jika mayoritas pengguna berada di Indonesia dan provider memiliki titik koneksi regional, uji Jakarta serta Singapura. Jangan berasumsi satu lokasi selalu paling cepat.

Checklist Produksi

Sebelum OmniRoute dipakai oleh tim, periksa daftar berikut:

  • Versi OmniRoute sudah dipatok dan dicatat.

  • Data directory memakai penyimpanan persisten.

  • Cadangan sudah diuji untuk dipulihkan.

  • Dashboard tidak terbuka langsung ke internet.

  • HTTPS atau tunnel aman sudah aktif.

  • Token dibuat per pengguna atau aplikasi.

  • Scope token mengikuti kebutuhan.

  • Provider utama sudah diuji.

  • Fallback sudah diuji.

  • Nama model berasal dari /v1/models.

  • Timeout dan retry sudah ditetapkan.

  • Log tidak menyimpan rahasia secara berlebihan.

  • Kebijakan retensi data sudah dibuat.

  • Syarat penggunaan setiap provider sudah ditinjau.

  • Biaya dan quota alert sudah diatur.

  • Rencana rollback upgrade sudah tersedia.

  • Pemilik operasional service sudah ditunjuk.

Pola Konfigurasi yang Disarankan

Penggunaan pribadi

TEXT
Deployment: npm atau desktop
Provider: 1 utama + 1 cadangan
Strategy: priority atau auto
Access: localhost
Compression: ringan, setelah diuji

Tim kecil

TEXT
Deployment: Docker pada server internal
Provider: 2–4 provider terverifikasi
Strategy: priority atau cost-optimized
Access: VPN atau reverse proxy HTTPS
Token: per anggota
Backup: harian

Eksperimen model

TEXT
Deployment: laptop atau lab server
Provider: beberapa provider
Strategy: weighted atau round-robin
Logging: metrik lengkap, prompt disamarkan
Tujuan: membandingkan kualitas, biaya, dan latensi

Aplikasi dengan persyaratan ketat

TEXT
Deployment: lingkungan terisolasi
Provider: hanya yang disetujui
Strategy: priority dengan allowlist
Access: jaringan privat
Logging: sesuai kebijakan data
Audit: aktif
Fallback: hanya dalam wilayah dan kontrak yang disetujui

Pertanyaan yang Sering Ditanyakan

Apakah OmniRoute benar-benar gratis?

Perangkat lunaknya menggunakan lisensi MIT dan dapat dijalankan sendiri. Namun, provider yang dipakai dapat mengenakan biaya.

Tingkat gratis juga memiliki batas, syarat, dan ketersediaan yang dapat berubah.

Apakah OmniRoute memberi token AI gratis?

OmniRoute menggabungkan akses ke provider yang menawarkan tingkat gratis atau akses tertentu. OmniRoute bukan sumber token model itu sendiri.

Angka agregat seperti sekitar 1,6 miliar token per bulan berasal dari penjumlahan kapasitas tingkat gratis yang terdokumentasi. Jumlah nyata yang dapat digunakan satu orang bergantung pada akun, wilayah, model, rate limit, dan syarat provider.

Apakah data tetap di komputer?

Konfigurasi gateway dapat berada di komputer Teman-Teman. Prompt tetap keluar ke provider eksternal ketika model eksternal dipilih.

Jika semua data harus tetap lokal, gunakan model lokal melalui Ollama, LM Studio, vLLM, atau backend lain yang berjalan di infrastruktur sendiri.

Apakah OmniRoute bisa dipakai untuk Cursor?

Bisa, selama versi Cursor yang dipakai menerima custom OpenAI-compatible base URL atau integrasi yang sesuai.

Gunakan:

TEXT
http://localhost:20128/v1

serta token lokal OmniRoute.

Apakah bisa dipasang di VPS Indonesia?

Bisa, selama sistem operasi, arsitektur CPU, memori, dan runtime memenuhi persyaratan. Gunakan Docker untuk deployment yang mudah dipindahkan.

Jangan membuka dashboard langsung ke IP publik tanpa TLS dan autentikasi.

Apakah OmniRoute lebih baik daripada memakai API langsung?

Tidak selalu. OmniRoute unggul ketika Teman-Teman membutuhkan banyak provider, fallback, routing, dan satu endpoint.

API langsung lebih sederhana dan dapat lebih cocok untuk aplikasi yang hanya memakai satu vendor atau membutuhkan fitur provider yang sangat khusus.

Apakah compression selalu aman?

Tidak. Compression dapat menghapus detail yang dianggap kurang penting. Gunakan evaluasi nyata, terutama untuk kode, dokumen hukum, data keuangan, dan instruksi presisi.

Berapa tambahan latensinya?

Tidak ada satu angka yang berlaku untuk semua lingkungan. Routing lokal biasanya menambah overhead, sedangkan fallback, translation, dan compression dapat menambah waktu lebih banyak.

Ukur dari aplikasi sampai respons selesai, bukan hanya waktu proses gateway.

Langkah Berikutnya Setelah Instalasi Berhasil

Setelah request pertama berhasil, urutan pengembangan yang paling aman adalah:

  1. Tambahkan satu provider cadangan.

  2. Buat combo priority.

  3. Uji fallback.

  4. Buat token terpisah untuk setiap aplikasi.

  5. Aktifkan metrik penggunaan.

  6. Susun batas biaya.

  7. Uji compression ringan.

  8. Cadangkan data directory.

  9. Dokumentasikan cara rollback.

  10. Evaluasi akses MCP hanya jika memang diperlukan.

Hindari menambahkan semua provider dan strategi sekaligus. Gateway yang sederhana, terukur, dan mudah dijelaskan biasanya lebih andal daripada konfigurasi besar yang tidak pernah diuji.

Kesimpulan

OmniRoute menawarkan pendekatan praktis untuk menyatukan beberapa provider AI melalui satu endpoint yang kompatibel dengan OpenAI. Nilai utamanya bukan sekadar akses ke berbagai model, melainkan kemampuan mengatur routing, fallback, biaya, dan penggunaan secara lebih terpusat. Meski demikian, kualitas implementasinya tetap bergantung pada konfigurasi provider, kebijakan privasi, pengujian latensi, dan pengamanan deployment.

Untuk penggunaan lokal maupun VPS Indonesia, mulailah dengan konfigurasi kecil yang mudah diaudit. Tambahkan provider cadangan secara bertahap, pisahkan token setiap aplikasi, pantau metrik, dan ikuti panduan keamanan Docker saat menjalankannya dalam container. Compression dan strategi routing sebaiknya diterapkan hanya setelah manfaatnya terbukti melalui pengujian dengan beban kerja nyata.

OmniRoute layak dipertimbangkan ketika satu API langsung sudah tidak cukup fleksibel, tetapi bukan pengganti perencanaan arsitektur yang matang. Bangun gateway sederhana terlebih dahulu, ukur hasilnya, lalu tingkatkan kompleksitas berdasarkan kebutuhan nyata—bukan sekadar karena fiturnya tersedia.


Referensi

GitHub. (2026). OmniRoute: Never stop coding with a free AI gateway.

GitHub. (2026). OmniRoute releases.

OmniRoute. (2026). Free AI gateway for multi-provider LLMs.

DeepWiki. (2026). OmniRoute installation and setup.

Docker Hub. (2026). OmniRoute Docker image.

SourceForge. (2026). OmniRoute download.

DeepWiki. (2026). OmniRoute local-first AI API routing gateway.

DEV.co. (2026). OmniRoute: Free AI gateway for 237 LLM providers.

Awesome Ecosyste.ms. (2026). OmniRoute AI gateway for multi-provider LLMs.

YouTube. (2026). OmniRoute GitHub tutorial: Connect Cursor to a local AI gateway.

Komentar (0)

Belum ada komentar. Jadilah yang pertama berbagi pendapat!

Tinggalkan komentar