מכיוון שהגיבוי הוא per-turn, Hermes לא "נשאר" על הגיבוי — הוא תמיד ינסה לחזור לראשי בתור הבא. זהו עיצוב מכוון שמטרתו לחזור למודל המועדף ברגע שהוא זמין שוב. הבעיה מתעוררת כאשר:
שימו לב לשורה הספציפית: sg claude opus 4.7 via custom. משמעות הציון "via custom" היא שהגיבוי עובר דרך נקודת קצה מותאמת אישית (custom endpoint) שהוגדרה מראש ב-config.yaml, ולא בהכרח דרך ספק אחר לחלוטין כמו OpenRouter או Anthropic ישיר. אם גם הראשי וגם הגיבוי משתמשים באותו מאגר מכסות, שניהם יהיו חסומים בו-זמנית.
הריצו את הפקודות הבאות כדי להבין מי הראשי ומה שרשרת הגיבוי:
hermes model — יציג את המודל הראשי הנוכחי.hermes fallback list — יציג את שרשרת הגיבויים המלאה.fallback_providers ב-~/.hermes/config.yaml.הריצו probe לבדיקת מצב השער:
openclaw gateway probe
אם אתם רואים HTTP 429, זו מגבלת קצב אמיתית מהספק במעלה הזרם (upstream), לא תקלת UI. שימו לב גם להקשר: בקשות עם הקשר ארוך במיוחד עלולות לעורר 429 גם כשנראה שיש לכם מכסה — OpenClaw מציין במפורש שייתכן שיידרש "שימוש נוסף" (extra usage) עבור בקשות הקשר ארוך.
בהתאם לממצאים:
~/.openclaw/.env או ~/.hermes/.env, והפעילו מחדש את השירות לאחר העדכון.ההודעה הזו חוזרת כי Hermes עושה את העבודה שלו — הוא מנסה לחזור לראשי בכל תור, וכל עוד הראשי חסום תקבלו את אותה ההודעה. הפתרון האמיתי הוא לטפל בבעיית החסימה במקור: להבין מי חוסם, למה, ולוודא שלגיבוי יש באמת מסלול עצמאי. התמקדות רק בהודעה עצמה מבלי לטפל בסיבה תשאיר אתכם בלופ אינסופי.
אם אתם רוצים שאעזור לכם לבדוק את הקובץ המדויק ולזהות בדיוק איפה הבעיה — ספרו לי ואכוון אתכם צעד-צעד.