Mengapa Peringatan "Switching to Fallback Provider" Muncul Berulang Kali di Hermes Agent

Yang penting dipahami, fallback ini bersifat per-turn. Artinya, pengalihan hanya berlaku untuk satu giliran percakapan saja. Pada giliran berikutnya, Hermes akan selalu mencoba kembali menghubungi model utama Anda terlebih dahulu. Jika model utama masih bermasalah, barulah Hermes akan kembali beralih ke model cadangan. Inilah mengapa Anda melihat pesan peringatan itu muncul berulang kali.

Mengapa Peringatan Ini Muncul Berulang Kali

Penyebabnya sederhana: model utama Anda masih terus mengalami rate limit. Selama upstream provider model utama Anda belum pulih dari pembatasan, setiap percakapan baru akan memicu siklus yang sama: coba model utama → gagal (rate limit) → alihkan ke model fallback.

Secara teknis, jika kode error yang sebenarnya muncul adalah HTTP 429: rate_limit_error, ini adalah kategori kesalahan yang perlu Anda selidiki di tingkat gateway, bukan hanya diabaikan sebagai "masalah sementara" . Dalam beberapa kasus, error 429 bahkan berkaitan dengan permintaan berkonteks panjang (long-context requests), di mana prompt atau riwayat percakapan Anda yang sangat besar menyebabkan penyedia mengetatkan kuota atau menolak permintaan .

Kasus Khusus: Model Utama dan Fallback Berbagi Sumber Daya yang Sama

Dalam kasus Anda, model fallback yang muncul adalah sg claude opus 4.7 via custom. Akhiran via custom ini mengindikasikan bahwa fallback Anda diarahkan melalui sebuah endpoint khusus (custom endpoint) yang telah dikonfigurasi sebelumnya di Hermes, bukan beralih ke penyedia native yang benar-benar berbeda.

Inilah inti permasalahannya. Jika model utama dan model fallback (custom endpoint) Anda ternyata bergantung pada gateway, pool, atau backend yang sama, maka ketika sumber daya bersama itu sedang kehabisan kuota, Anda akan melihat Hermes "berpindah" model tetapi tetap merasakan error yang sama berulang-ulang. Belum ada bukti yang cukup untuk memastikan kedua jalur ini berbagi pool yang sama tanpa memeriksa konfigurasi asli Anda, tetapi ini adalah kemungkinan yang sangat tinggi dan layak menjadi fokus investigasi utama.

Langkah-Langkah Mengatasi Masalah

1. Periksa Konfigurasi Model Utama dan Fallback Anda

Semua konfigurasi, termasuk penyedia model utama dan daftar fallback, tersimpan di file config.yaml. Periksa bagian fallback_providers untuk melihat ke mana model cadangan Anda diarahkan.

2. Verifikasi Apakah Ada Ketergantungan pada Gateway atau Pool yang Sama

Periksa apakah penyedia model utama Anda dan custom endpoint (sg claude opus 4.7 via custom) ternyata menggunakan gateway, kunci API, atau backend pool yang identik. Jika ya, Anda perlu mendiversifikasi jalur koneksi atau mengatur ulang kuota.

3. Gunakan Perintah Probe untuk Diagnosis

Jika Anda menjalankan OpenClaw gateway atau gateway kustom, gunakan perintah probe untuk melihat status koneksi dan jenis error yang sebenarnya terjadi, apakah itu 429 (rate limit), kegagalan autentikasi, atau masalah lain .

4. Periksa Konfigurasi Kunci API dan Environment

Jika gateway membaca kunci API dari environment variable, pastikan kunci tersebut tersedia di host yang menjalankan gateway dan restart gateway Anda setelah melakukan perubahan pada kunci atau konfigurasi .

5. Waspadai Masalah pada Konteks Percakapan Panjang

Jika peringatan ini lebih sering muncul saat Anda menggunakan konteks percakapan yang panjang atau instruksi yang kompleks, kemungkinan besar Anda mengalami masalah long-context rate limit yang spesifik. Solusinya bisa berupa memulai sesi baru yang lebih ringkas atau mengonfigurasi penyedia dengan kuota long-context yang lebih besar .

6. Edit Langsung File config.yaml Jika Diperlukan

Anda dapat mengedit langsung daftar fallback di config.yaml dengan menambahkan blok fallback_providers. Pastikan untuk menyertakan pasangan provider dan model yang valid untuk setiap entri. Jika Anda meletakkannya di bawah direktori ~/.hermes/, gunakan path ~/.hermes/config.yaml .

Kesimpulan

Peringatan “switching to fallback” yang berulang terjadi karena Hermes melakukan tugasnya dengan benar sesuai desain. Ia tidak akan pernah berhenti mencoba kembali ke model utama di setiap giliran percakapan baru. Satu-satunya cara untuk menghentikan siklus ini adalah dengan menyelesaikan masalah mendasar di sisi model utama Anda—apakah itu rate limit, kuota habis, atau kegagalan infrastruktur bersama.

Jika Anda membutuhkan bantuan lebih lanjut, berikan akses ke file konfigurasi config.yaml Anda saat ini untuk kami analisis lebih detail, sehingga kami dapat menunjukkan dengan tepat model utama mana yang gagal, ke mana custom endpoint sg-* mengarah, dan mengapa siklus fallback ini terus berulang.