Bayangkan skenario ini: tim teknisi IT di sebuah rumah sakit sedang mengembangkan sistem dokumentasi klinis berbasis AI. Mereka menggunakan *coding agent* untuk menghasilkan draf kode, model dari Anthropic untuk peninjauan *script*, dan GPT-4 untuk merangkum log operasional. Semua berjalan lancar, sampai suatu hari limit token API habis. Atau yang lebih buruk, layanan *provider* mengalami pemadaman *(downtime)* selama dua jam.


Seluruh *pipeline* pengembangan dan operasional berhenti total.


Kondisi ini bukanlah kegagalan teknis murni, melainkan **vendor lock**. Sebuah situasi di mana sistem dan alur kerja memiliki ketergantungan absolut pada satu *provider* eksternal yang berada di luar kendali tim internal.


## Chapter 1 — Masalah Tersembunyi: Vendor Lock dan Env Lock


Bagi infrastruktur IT Kesehatan, risikonya sangat tinggi. Sistem yang menopang operasional rumah sakit membutuhkan ketersediaan tinggi *(high availability)*. Ketergantungan pada satu vendor menciptakan *single point of failure* (SPOF) yang berisiko mengganggu ritme kerja.


Selain *vendor lock*, tim sering kali terjebak dalam **env lock**. Ini terjadi ketika variabel *environment*—seperti `API_KEY`, `BASE_URL`, dan `MODEL_NAME`—tertanam secara statis di berbagai mesin developer.


Gejala *env lock* sangat mudah dikenali:


* File konfigurasi berbeda-beda versinya di setiap mesin.

* Mengganti *provider* berarti harus melakukan *find-and-replace* di puluhan file secara manual.

* Orientasi *(onboarding)* teknisi baru memakan waktu berjam-jam hanya untuk menyamakan *setup environment*.


*Env lock* bukan sekadar masalah kerapian kode; ini adalah *bottleneck* operasional nyata.


## Chapter 2 — Pola Solusi: Router sebagai Abstraction Layer


Solusi dari kedua masalah operasional ini bermuara pada satu pola arsitektur: **AI Router**.


Router berfungsi sebagai *endpoint* tunggal yang diakses oleh seluruh tim. Di balik layar, router inilah yang bertugas mengelola koneksi ke berbagai *provider*, mengatur *fallback chain* (skema cadangan jika terjadi *error* jaringan), dan mengabstraksikan semua konfigurasi autentikasi.


### Instalasi dan Arsitektur OmniRoute


**OmniRoute** adalah *AI gateway* lokal yang mengekspos *endpoint* yang kompatibel dengan standar OpenAI, lalu merutekan *request* tersebut ke berbagai *provider* AI di belakangnya. Dibangun di atas *routing engine* 9Router, sistem ini memiliki manajemen kombinasi model dan strategi *fallback* yang sangat presisi di level proksi.


**Langkah Instalasi**

Pastikan sistem sudah terpasang Node.js (minimal versi 18). Buka terminal dan jalankan:


```bash

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

cd omni-route

npm install

npm run start


```


OmniRoute akan mulai beroperasi di `http://localhost:20128`. Arsitekturnya bekerja secara transparan:


```text

┌─────────────────────────────────────┐

│     Coding Agent / CLI     │

│  (OpenCode, Codex CLI, Cursor)   │

└────────────────┬────────────────────┘

          │ POST /v1/chat/completions

          ▼

┌─────────────────────────────────────┐

│        OmniRoute         │

│   http://localhost:20128/v1      │

│                    │

│ ┌─────────────────────────────┐   │

│ │  Routing Engine Layer    │   │

│ │  - Model translation     │   │

│ │  - Fallback chain logic   │   │

│ │  - Load balancing      │   │

│ └──────────────┬──────────────┘   │

└─────────────────┼───────────────────┘

          │

   ┌───────────┼───────────┐

   ▼       ▼       ▼

 OpenRouter  Anthropic  Ollama (Lokal)


```


## Chapter 3 — Setup Provider dan Kunci API Internal


Di dalam OmniRoute, **provider** adalah koneksi ke layanan AI eksternal yang mencakup kredensial dan URL dasar. Untuk IT Kesehatan, strategi terbaik adalah menggabungkan OpenRouter (untuk akses rute multi-model) dengan *provider* lokal seperti Ollama (untuk memproses *script* yang mengandung variabel sensitif secara *on-premise*).


**Konfigurasi Provider (via config.json):**


```json

{

 "providers": [

  {

   "name": "openrouter",

   "baseUrl": "https://openrouter.ai/api/v1",

   "apiKey": "sk-or-v1-..."

  },

  {

   "name": "anthropic",

   "baseUrl": "https://api.anthropic.com/v1",

   "apiKey": "sk-ant-..."

  }

 ],

 "auth": {

  "enabled": true,

  "keys": [

   {

    "name": "tim-it-medis",

    "key": "sk-omniroute-internal-2026"

   }

  ]

 }

}


```


Blok `"auth"` di atas sangat krusial. Alih-alih membagikan kunci API asli dari *provider* ke seluruh tim, kita menciptakan *internal key* (`sk-omniroute-internal-2026`).


**Verifikasi Setup:**


```bash

curl http://localhost:20128/v1/chat/completions \

 -H "Authorization: Bearer sk-omniroute-internal-2026" \

 -H "Content-Type: application/json" \

 -d '{

  "model": "openai/gpt-4o-mini",

  "messages": [{"role": "user", "content": "Tuliskan command linux untuk cek port aktif."}]

 }'


```


Jika merespons dengan format JSON standar OpenAI, proksi lokal Anda sudah siap menerima *traffic* dari agen tim.


## Chapter 4 — Integrasi ke Ekosistem OpenCode dan Codex CLI


Ini adalah tahap final di mana *abstraction layer* benar-benar menunjukkan nilainya. Teknisi tidak perlu memasang *plugin* yang berbeda-beda untuk tiap *provider*. Cukup ubah konfigurasi target pada agen yang digunakan.


Banyak lingkungan pengembangan yang mengandalkan klien *desktop* atau agen berbasis *Command Line Interface* (CLI) seperti **OpenCode** dan ekosistem **OpenAI Codex**. Alat-alat ini umumnya mengelola *state* dan kredensial melalui *file* konfigurasi berbasis YAML di dalam *plugin cache*.


Pengaturan *default* pada agen berbasis YAML sering kali rentan mengalami *error* autentikasi persisten—seperti pesan `403 Forbidden`—ketika struktur direktori lokal tidak sinkron atau *token* dari *provider* utama mengalami masalah limitasi di sisi *backend*.


Dengan menggunakan OmniRoute, isu-isu otorisasi langsung yang biasa terjadi antara CLI dan API *provider* dapat dicegah, karena OmniRoute mengambil alih proses validasi. Anda hanya perlu mengarahkan konfigurasi YAML di mesin lokal ke *endpoint* OmniRoute.


**Contoh Penyesuaian Konfigurasi YAML (OpenCode / Codex CLI):**


Buka *file* konfigurasi agen (biasanya terletak di `~/.opencode/config.yaml` atau di dalam direktori *cache plugin* CLI Anda), lalu modifikasi parameter URL dan autentikasinya:


```yaml

version: 1.0

active_profile: omniroute_local


profiles:

 omniroute_local:

  # Arahkan base_url ke proksi lokal alih-alih API eksternal

  base_url: "http://localhost:20128/v1"

   

  # Gunakan nama model standar, OmniRoute akan memetakan ke provider aktif

  default_model: "openai/gpt-4o-mini"

   

  # Gunakan API key internal yang telah dikonfigurasi di OmniRoute

  api_key: "sk-omniroute-internal-2026"

   

  settings:

   temperature: 0.2

   max_tokens: 2048


```


Simpan file YAML tersebut dan muat ulang layanan CLI. Saat agen OpenCode mengeksekusi perintah untuk *generate script*, *request* tersebut akan dikirim ke proksi lokal. Jika terjadi masalah dengan *provider* utama, OmniRoute akan secara diam-diam memicu *fallback* ke *provider* cadangan. Bagi OpenCode, respons seolah-olah berjalan mulus tanpa ada pesan *error 403* di terminal.


### Ekspos *Endpoint* ke Seluruh Tim (Opsional)


Untuk membuat *endpoint* OmniRoute ini bisa diakses oleh teknisi lain secara *remote* tanpa membuka *port* publik atau repot mengatur VPN, gunakan **Cloudflare Tunnel**:


```bash

cloudflared tunnel --url http://localhost:20128


```


URL publik yang dihasilkan (misal: `https://omni-internal.rs-domain.com/v1`) tinggal disalin dan dipasang pada *file* konfigurasi YAML masing-masing anggota tim. Mengganti *provider* atau mengatasi *downtime* kini bisa diselesaikan murni dari sisi server OmniRoute, membebaskan tim IT untuk fokus pada pengembangan infrastruktur, bukan mengurus *error provider*.