Routing & Resilience

Urutan keputusan

Untuk setiap request, router:

1. Menerjemahkan model mengikuti urutan di Model & routing: chain:<nama> → alias → provider/model → nama polos. Hasilnya daftar target berurutan.
2. Memeriksa akses — allowlist key ∩ plan, dan budget aktif.
3. Memilih akun — akun dengan prioritas tertinggi yang tidak cooldown dan tidak dinonaktifkan; kalau provider memakai round-robin, akun diputar.
4. Meneruskan request — dan naik ke target berikutnya kalau gagal.

Fallback chain

Chain menentukan siapa dicoba berikutnya. Contoh heavy-coding: Claude dulu, GLM kedua, OpenRouter sebagai fallback penutup. Kalau langkah pertama kena 429, router masuk cooldown 30 detik untuk akun itu dan langsung lanjut ke langkah kedua — klien tidak melihat error.

Setiap langkah bisa dimatikan satu per satu (Chains → edit → saklar langkah, atau "active": false di API). Langkah yang nonaktif dilewati tapi tetap di posisinya, jadi menyalakannya lagi mengembalikan urutan semula.

Retry dan cooldown

Total maksimal 10 percobaan per request. Cooldown membuat akun yang bermasalah diistirahatkan, bukan dibanjiri lagi — statusnya terlihat di halaman Provider Health.

Di luar chat

Request web search/fetch, audio, gambar, dan embeddings melewati pipeline yang sama: allowlist key dan plan, budget, prioritas akun, cooldown, dan fallback ke target atau akun berikutnya. Token embeddings dicatat dan dihitung biayanya seperti token chat.

Konkurensi

Gateway membatasi request in-flight secara global (100). Saat penuh, request baru dijawab 503 — lebih jujur daripada antrean yang membengkak. Batas rpm/tpm/concurrent di plan tersimpan di skema, tapi belum ditegakkan gateway saat ini.

Metering

Setiap request tercatat: provider dan model yang benar-benar melayani, key, akun, jenis klien (terdeteksi dari User-Agent — Claude Code, Cursor, Codex, Cline, Copilot, Aider, dll), token per kategori, biaya, cache hit, latensi, dan TTFT. Semua itu yang kamu lihat di halaman Usage.