Reliability and Routing13 Oktober 2026Flatkey Team

OpenRouter Down? Cara Fail Over Tanpa Mengubah Kode

Periksa apakah OpenRouter sedang down, pisahkan error penyedia dari insiden platform, dan lakukan fail over dengan base_url, retries, provider fallback, dan model fallback.

Ketika orang mencari OpenRouter Down, biasanya mereka butuh dua jawaban cepat: apakah OpenRouter benar-benar sedang down, dan bagaimana saya menjaga request tetap berjalan tanpa menulis ulang aplikasi saya?

Jawaban paling aman bukan panik mengganti model di kode. Pertama, pastikan apakah masalahnya terjadi di seluruh OpenRouter, spesifik provider, spesifik akun, atau antrean retry Anda sendiri. Lalu pindahkan failover ke konfigurasi: pemeriksaan status, budget retry, fallback provider, fallback model, dan base_url yang kompatibel dengan OpenAI dan bisa diganti.

Tanggal pengecekan: 13 Oktober 2026. Jangan menganggap artikel ini sebagai bukti bahwa OpenRouter sedang down saat ini. Periksa halaman status OpenRouter dan log Anda sendiri sebelum memulai insiden.

Jawaban Singkat

Jika OpenRouter sedang down, atau jika satu rute OpenRouter gagal, gunakan urutan berikut:

Periksa https://status.openrouter.ai/ dan log error Anda.
Pisahkan error platform OpenRouter dari error model/provider upstream.
Patuhi Retry-After pada respons 429, 503, dan 402 dengan anggaran in-flight.
Tetap aktifkan provider.allow_fallbacks kecuali ada aturan kepatuhan yang mengharuskan sebaliknya.
Tambahkan fallback model melalui konfigurasi request jika kontrak kualitas respons mengizinkannya.
Tempatkan API gateway atau endpoint cadangan Anda di balik environment variable sehingga Anda bisa mengganti base_url tanpa mengedit kode aplikasi.

Poin terakhir itulah langkah nyata "tanpa mengubah kode". Aplikasi Anda harus membaca endpoint dari konfigurasi:

OPENAI_BASE_URL=https://openrouter.ai/api/v1
OPENAI_API_KEY=...

Selama insiden, perubahan operasional Anda menjadi:

OPENAI_BASE_URL=https://router.flatkey.ai/v1
OPENAI_API_KEY=...

Kode SDK Anda tetap sama.

Apakah OpenRouter Down?

Jangan menyimpulkan OpenRouter Down dari satu request yang gagal. Satu request gagal bisa berarti:

Gejala	Ruang lingkup yang mungkin	Apa yang diperiksa lebih dulu
Insiden di halaman status	Platform OpenRouter	Halaman status, linimasa insiden, pembaruan publik
`502 Bad Gateway`	Model/provider yang dipilih mungkin sedang down	Model, metadata provider, kelayakan fallback
`503 Service Unavailable`	Tidak ada provider yang memenuhi aturan routing Anda	Batasan provider, `only`, ZDR, persyaratan parameter
`429 Too Many Requests`	Rate limit atau kapasitas provider	`Retry-After`, concurrency antrean, fallback provider
`402 Payment Required`	Kredit atau budget pengeluaran in-flight	`Retry-After`, saldo akun, batas key
`403 Forbidden`	Budget, izin, moderasi, guardrail	`error.metadata`, kebijakan workspace/key
Streaming dimulai, lalu event error muncul	Provider gagal setelah HTTP `200`	Periksa body SSE, bukan hanya status HTTP awal

Dokumentasi error OpenRouter menyatakan bahwa 502 dapat berarti model yang dipilih sedang down atau mengembalikan respons yang tidak valid, sementara 503 dapat berarti tidak ada provider model yang tersedia yang memenuhi persyaratan routing. Dokumentasi yang sama juga menyebut OpenRouter dapat mengembalikan Retry-After pada 429, 503, dan beberapa respons 402 dengan anggaran in-flight. Sumber: OpenRouter errors and debugging.

OpenRouter pernah mengalami outage publik sebelumnya. Postmortem 17 dan 19 Februari 2026 menjelaskan kegagalan API akibat dependensi caching pihak ketiga dan mencatat bahwa beberapa pengguna melihat error 401 yang membingungkan selama insiden tersebut. Post historis itu berguna sebagai konteks, tetapi bukan bukti adanya outage saat ini. Sumber: OpenRouter outage postmortem.

Lima Menit Pertama: Triage OpenRouter Down

Gunakan checklist ini sebelum mengalihkan traffic.

Menit	Tindakan	Keputusan
0-1	Periksa halaman status OpenRouter dan linimasa alert Anda.	Jika halaman status mengonfirmasi insiden, lanjutkan ke kesiapan failover.
1-2	Kelompokkan error berdasarkan status code, model, provider, route, dan SDK.	Jika satu model/provider gagal, jangan berasumsi terjadi masalah di seluruh platform.
2-3	Periksa `Retry-After`, jumlah retry, dan concurrency antrean.	Hentikan retry storm sebelum menambah lebih banyak traffic fallback.
3-4	Bandingkan beban kerja berbayar, gratis, batch, dan agent.	Pertahankan traffic interaktif sebelum job latar belakang.
4-5	Pilih tindakan failover terkecil yang memulihkan kerja yang terlihat oleh pengguna.	Utamakan fallback provider sebelum fallback lintas model; utamakan pergantian konfigurasi sebelum deployment kode.

Kesalahan utama selama insiden OpenRouter Down adalah membuat setiap worker langsung retry. Retry storm dapat mengubah satu error provider menjadi masalah antrean di seluruh platform di dalam aplikasi Anda sendiri.

Failover Tanpa Mengubah Kode

Pola tanpa perubahan kode itu sederhana: pertahankan penggunaan SDK tetap stabil dan buat rutenya dapat dikonfigurasi.

import OpenAI from "openai";

export const ai = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
  baseURL: process.env.OPENAI_BASE_URL,
});

Lalu, simpan pemilihan endpoint di environment, konfigurasi deployment, feature flag, atau secret manager Anda:

ai_gateway:
  primary:
    base_url: https://openrouter.ai/api/v1
    key_env: OPENROUTER_API_KEY
  backup:
    base_url: https://router.flatkey.ai/v1
    key_env: FLATKEY_API_KEY
  switch_policy:
    trigger: confirmed_platform_incident_or_error_budget_exhausted
    owner: on_call_engineer
    rollback: after_30_minutes_below_error_threshold

Ini bekerja karena quickstart OpenRouter mengatakan API-nya bisa digunakan melalui SDK OpenAI dengan mengarahkan SDK ke OpenRouter. Bentuk integrasi yang sama inilah yang membuat gateway cadangan yang kompatibel dengan OpenAI menjadi praktis. Sumber: quickstart OpenRouter.

Gunakan Provider Fallback Sebelum Mengubah Model

Jika OpenRouter masih dapat dijangkau tetapi salah satu provider sedang bermasalah, provider fallback adalah langkah dengan risiko terendah. Anda tetap mempertahankan kontrak model yang sama dan membiarkan routing mencoba provider lain yang memenuhi syarat.

Dokumentasi routing provider OpenRouter menyebut bahwa request secara default di-load balance di antara provider teratas untuk memaksimalkan uptime, dan objek provider mencakup allow_fallbacks, yang default-nya true. Dokumentasi itu juga memperingatkan bahwa pengaturan sort atau order mengubah perilaku load balancing, dan filter provider yang ketat dapat mengurangi ruang routing. Sumber: routing provider OpenRouter.

Mulailah dengan ini:

{
  "model": "anthropic/claude-sonnet-4.5",
  "messages": [{ "role": "user", "content": "..." }],
  "provider": {
    "allow_fallbacks": true
  }
}

Berhati-hatilah dengan ini selama insiden:

{
  "provider": {
    "only": ["one-provider"],
    "allow_fallbacks": false
  }
}

Routing yang ketat mungkin tepat untuk kepatuhan, retensi data, wilayah, atau kebijakan harga. Namun routing yang ketat bukanlah pengaturan keandalan. Jika Anda memerlukan routing ketat untuk workload sensitif, buat jalur terpisah yang tidak sensitif yang bisa fail over dengan lebih bebas.

Tambahkan Model Fallback Hanya Jika Output Saling Dapat Dipertukarkan

Model fallback lebih kuat daripada provider fallback. Ini dapat menjaga aplikasi tetap hidup ketika model utama down, terkena rate limit, atau diblokir, tetapi juga dapat mengubah gaya output, latensi, biaya, panjang konteks, perilaku tool, dan hasil evaluasi.

Dokumentasi model fallback OpenRouter mengatakan parameter models memungkinkan Anda memberikan ID model dalam urutan prioritas. Jika model pertama mengembalikan error, OpenRouter mencoba model berikutnya. Dokumentasi tersebut mencantumkan rate limiting dan downtime di antara error yang dapat memicu fallback. Sumber: model fallback OpenRouter.

Gunakan model fallback untuk tugas dengan kontrak ekuivalensi yang longgar:

{
  "models": [
    "anthropic/claude-sonnet-4.5",
    "openai/gpt-4o",
    "google/gemini-2.5-pro"
  ],
  "messages": [{ "role": "user", "content": "Rangkum thread dukungan ini." }]
}

Hindari model fallback diam-diam untuk tugas di mana model yang tepat merupakan bagian dari jaminan produk:

Workload	Sikap terhadap model fallback
Ringkasan internal	Biasanya aman dengan evaluasi dan logging
Perencanaan agen coding	Mungkin, tetapi uji perilaku pemanggilan tool dan kepatuhan terhadap instruksi
Ekstraksi terstruktur	Hanya jika skema dan validasi lolos
Copy kreatif yang terlihat pelanggan	Mungkin, tetapi harapkan perbedaan gaya
Output yang diatur atau kontraktual	Jangan ubah model secara diam-diam
Benchmarking atau evals	Jangan fallback kecuali fallback itu sendiri adalah subjek pengujian

Kebijakan Insiden yang Praktis

Kebijakan ini sengaja membosankan. Ini menjaga kerja respons OpenRouter Down tetap operasional, bukan dramatis.

openrouter_down_policy:
  status_checks:
    - openrouter_status_page
    - synthetic_chat_completion
    - provider_error_rate_by_model
    - queue_retry_rate

  retry_budget:
    max_attempts: 3
    honor_retry_after: true
    jitter: true
    stop_retrying_on:
      - invalid_credentials
      - spent_budget
      - moderation_block
      - bad_request

  provider_fallback:
    default_allow_fallbacks: true
    loosen_provider_constraints_for:
      - non_sensitive_batch_jobs
      - internal_tools
      - support_summaries

  model_fallback:
    require_contract: equivalent_quality_or_validated_schema
    log_selected_model: true
    disallow_for:
      - evals
      - compliance_outputs
      - customer_promises_about_exact_model

  base_url_failover:
    primary: OPENAI_BASE_URL
    backup_env: OPENAI_BACKUP_BASE_URL
    switch_owner: on_call_engineer
    switch_requires:
      - confirmed_status_incident_or_internal_error_budget
      - rollback_plan
      - public_request_log_enabled

Field kunci yang perlu dicatat adalah:

Kolom	Mengapa penting
`base_url`	Membuktikan gateway mana yang menangani permintaan
`requested_model`	Menunjukkan model yang dimaksud oleh pemanggil
`served_model`	Menunjukkan model yang benar-benar digunakan setelah fallback
`provider`	Memisahkan masalah platform dari masalah provider
`status_code`	Menggerakkan keputusan retry/failover
`retry_after`	Mencegah storm retry
`attempt`	Menunjukkan apakah retry memperbesar traffic
`fallback_reason`	Membuat review insiden menjadi mungkin
`cost`	Memastikan fallback tidak menimbulkan lonjakan pengeluaran tak terduga
`request_id`	Memungkinkan support dan engineering melacak satu permintaan

Di Mana Flatkey Cocok

Flatkey berguna ketika Anda ingin playbook OpenRouter Down berjalan di luar kode aplikasi. Posisi produk Flatkey adalah gateway API LLM terpadu: satu kunci, satu saldo, dan endpoint yang kompatibel dengan OpenAI untuk routing lintas model teks, gambar, dan video resmi. Dalam pola insiden ini, nilai praktisnya bersifat operasional:

Biarkan aplikasi Anda tetap menggunakan bentuk client yang kompatibel dengan OpenAI.
Rutekan beban kerja melalui base_url cadangan tanpa mengubah logika aplikasi.
Sentralisasikan allowlist model, sub-key, log permintaan, kontrol anggaran, dan kebijakan fallback.
Bandingkan perilaku gateway menggunakan bukti permintaan, bukan anekdot.

Jangan pindahkan semua beban kerja saat terjadi insiden kecil. Pindahkan satu beban kerja representatif terlebih dahulu, amati error rate, latency, model yang dipilih, alasan fallback, dan biaya, lalu putuskan apakah perlu memperluas perpindahan.

Bacaan lanjutan yang berguna:

FAQ OpenRouter Down

Apakah OpenRouter sedang down sekarang?

Periksa terlebih dahulu halaman status OpenRouter. Artikel ini menjelaskan cara merespons ketika pencarian OpenRouter Down mengarah ke insiden nyata atau kegagalan provider lokal; artikel ini tidak menyatakan bahwa OpenRouter sedang down sekarang.

Apa yang harus saya lakukan pertama kali jika OpenRouter down?

Hentikan retry agresif, periksa status code, dan pertahankan traffic interaktif. Jika insiden terkonfirmasi, utamakan fallback provider sebelum fallback model, dan utamakan switch konfigurasi base_url sebelum deployment kode.

Bisakah saya melakukan fail over dari OpenRouter tanpa mengubah kode?

Ya, jika aplikasi Anda sudah membaca endpoint yang kompatibel dengan OpenAI dari konfigurasi. Letakkan baseURL atau base_url di balik environment variable, pertahankan bentuk pemanggilan SDK tetap stabil, dan ganti endpoint di konfigurasi deployment.

Haruskah saya menggunakan fallback model OpenRouter saat terjadi outage?

Gunakan fallback model hanya jika model fallback tersebut sesuai untuk tugasnya. Ini cocok untuk banyak workflow internal, tetapi tidak untuk evaluasi, output yang diatur regulasi, atau kasus ketika pelanggan dijanjikan model tertentu.

Apa perbaikan jangka panjang paling aman untuk risiko OpenRouter Down?

Rancang untuk portabilitas di tingkat rute: base_url yang dapat dikonfigurasi, logging di tingkat permintaan, retry budget, fallback provider, kontrak fallback model yang teruji, dan jalur gateway cadangan yang kompatibel dengan OpenAI. Tujuannya bukan menghindari setiap outage; tujuannya adalah membuat failover terasa biasa saja.