feat(logging): add config option to suppress fallback/rate-limit status messages

[zccyman]

Problem

Hermes sends internal lifecycle status messages (rate-limit, fallback switching) directly through the gateway status callback, flooding the main chat with technical debugging noise. No config option exists to suppress these selectively.

Closes #27131

Solution

Add logging.suppress_fallback_messages: true config key in config.yaml:

• CLI log: Messages still printed via _vprint(force=True) — full debug visibility preserved
• Gateway chat: Fallback/rate-limit messages are not forwarded to status_callback — clean chat UI
• Other messages: Errors, warnings, tool failures remain visible (default behavior unchanged)

Changes

run_agent.py (+29 lines):

• Read logging.suppress_fallback_messages from config in __init__, store as self._suppress_fallback_status
• Extend _emit_status() docstring with suppress behavior
• Add keyword-based message matching (Rate limited, switching to fallback, trying fallback, etc.) — skip status_callback call when matched

tests/run_agent/test_suppress_fallback_status.py (new, 109 lines):

• 6 tests covering: normal forwarding, suppress fallback, non-fallback passthrough, default behavior, final error suppression, no-callback safety

Test Results

6 passed (new tests)
8 passed (existing empty_response + fallback tests — no regression)

Config Usage

# config.yaml
logging:
  suppress_fallback_messages: true

Default: false (existing behavior preserved, zero-change for users who do not opt in).

[alt-glitch]

Note: #27131 (which this closes) was itself closed as duplicate of #19572. Competing with open PR #4242 (silent_fallback option) and #12610 (email-specific suppression). Consider consolidating with the existing proposals.

[zccyman]

Thanks @alt-glitch for the cross-reference.

Closing in favor of #4242 — it's the more comprehensive approach:

• Scope: feat(fallback): add silent_fallback option to suppress status messages #4242 adds silent_fallback as a per-provider config option (+94/-7), covering both single and chain fallbacks. Our PR uses a global logging.suppress_fallback_messages key (+29/-0), which is narrower.
• Config model: feat(fallback): add silent_fallback option to suppress status messages #4242's per-provider silent_fallback: true is more flexible than our global toggle.
• Timeline: feat(fallback): add silent_fallback option to suppress status messages #4242 was opened March 31 vs our May 16 — earlier by 6 weeks.

Good convergent design — both identify the same noise problem. #4242's approach is the better one to ship. 🙏

[zccyman]

Closing — #4242 is the more comprehensive approach for silent fallback.