Mesej "Rate Limited" Berulang Kali? Ini Punca Sebenar & Cara Selesaikan

Masalah utama: Mekanisme ini beroperasi secara "per-turn" (setiap giliran mesej). Ini bermakna, setiap kali anda menghantar mesej baharu, Hermes akan mencuba kembali ke model utama terlebih dahulu. Jika model utama masih belum pulih daripada had kadar, ia akan gagal lagi dan bertukar semula ke sandaran — menyebabkan mesej amaran yang sama muncul berulang kali.

Kenapa Ia Berulang-ulang?

Ada beberapa punca yang perlu diperiksa:

1. Perkongsian Pool atau Gateway

Amaran menunjukkan fallback melalui sg claude opus 4.7 via custom — ini adalah titik hujung (endpoint) tersuai yang telah dikonfigurasi dalam Hermes. Jika model utama dan sandaran anda berkongsi:

• Gateway yang sama
• Pool kekunci API yang sama
• Kuota pembekal huluan yang sama

Maka kedua-duanya akan terjejas serentak apabila had kadar dikenakan. Anda akan lihat pertukaran berlaku, tetapi prestasi tetap "tersekat" kerana kedua-dua laluan mengalami masalah kuota yang serupa.

Dokumentasi Hermes mengesahkan bahawa endpoint tersuai disimpan dalam config.yaml, dan rantai fallback juga terkandung dalam fail yang sama di bawah entri fallback_providers.

2. Konteks Perbualan Yang Terlalu Panjang

Jika ralat spesifik adalah HTTP 429: rate_limit_error: Extra usage is required for long context requests, ini menandakan permintaan anda terlalu besar (konteks panjang) dan pembekal memerlukan kuota tambahan untuk memprosesnya.

3. Kesan "False Positive" dalam Gateway

Ada kes di mana OpenClaw memaparkan mesej "API rate limit reached" sedangkan API sebenar berfungsi dengan baik — ini adalah bug yang dilaporkan dalam mekanisme cooldown gateway, bukan had kadar sebenar daripada pembekal.

Langkah Praktikal Untuk Diagnosis & Penyelesaian

Semak Konfigurasi Fallback Anda

Buka fail ~/.hermes/config.yaml dan periksa entri fallback_providers. Pastikan model sandaran menggunakan laluan pembekal yang berbeza sepenuhnya daripada model utama — bukan sekadar model berbeza tetapi melalui gateway atau pool yang sama.

Contoh konfigurasi yang betul:

fallback_providers:
  - provider: openrouter
    model: anthropic/claude-sonnet-4

Setiap entri memerlukan kedua-dua provider dan model. Jika ada yang hilang, fallback akan dilumpuhkan.

Gunakan Alat Probe

Jalankan arahan openclaw gateway probe untuk melihat status sebenar gateway anda:

• Reachable: yes menunjukkan sambungan berjaya
• Jika anda lihat Capability: limited - missing scope: operator.read, ini adalah diagnostik degradasi, bukan ralat sambungan
• Perhatikan teks ralat mentah: jika mengandungi retry-after, RESOURCE_EXHAUSTED, atau menyebut 'organization quota', ini mengesahkan masalah di peringkat pembekal model

Periksa Kekunci API

Pastikan kekunci API anda:

• Diletakkan pada hos gateway yang betul
• Jika menggunakan systemd/launchd, simpan dalam ~/.openclaw/.env untuk akses daemon
• Mulakan semula gateway selepas sebarang perubahan pada kekunci atau konfigurasi

Untuk Masalah Konteks Panjang

Jika ralat khusus berkaitan long context:

• Kurangkan saiz konteks perbualan anda
• Mulakan sesi baru untuk topik berbeza dan elakkan perbualan yang terlalu panjang dalam satu sesi
• Buka /gateway/troubleshooting#anthropic-429-extra-usage-required-for-long-context untuk panduan spesifik

Bagaimana Hendak Menghentikannya Dengan Pantas?

Jalan pintas: Semasa menunggu had kadar pulih, anda boleh menukar model utama terus kepada model yang tidak mengalami masalah kuota. Gunakan arahan hermes model untuk pemilihan interaktif, atau arahan /model dalam sesi perbualan untuk bertukar antara pembekal yang telah dikonfigurasikan.

Penyelesaian jangka panjang:

• Konfigurasikan rantai fallback yang benar-benar berasingan (pembekal/pool berbeza)
• Tambahkan beberapa lapisan fallback untuk daya tahan lebih baik
• Pantau penggunaan kuota pembekal anda dan naik taraf pelan jika perlu

Intinya: amaran ini berulang kerana Hermes melaksanakan tugasnya dengan betul — bertukar ke sandaran apabila utama gagal, tetapi kembali ke utama setiap kali ada mesej baru. Untuk menghentikannya secara kekal, anda perlu menyelesaikan punca di peringkat model utama atau gateway, bukan sekadar mengabaikan mesej amaran tersebut.