hermes - 💡(How to fix) Fix Auxiliary 401/token_invalidated errors do not traverse auxiliary fallback_chain or main-agent fallback

Title: Auxiliary 401/token_invalidated errors do not traverse auxiliary fallback_chain or main-agent fallback

Bug description

When an auxiliary task uses an explicit provider and that provider returns a 401 auth failure (for example token_invalidated), Hermes does not traverse the auxiliary fallback_chain and does not fall back to the main agent model.

This creates an asymmetry with the primary runtime:

• primary provider auth failures do fall through to configured fallback providers
• auxiliary auth failures do not

In practice this means auxiliary features such as compression can hard-fail on 401 even when the main runtime would successfully fall back.

Expected behavior

For auxiliary tasks using an explicit provider:

1. first try same-provider auth recovery / refresh if available
2. if auth recovery fails and the error remains a 401 / token_invalidated, traverse auxiliary.<task>.fallback_chain
3. if that chain is empty or exhausted, fall back to the main agent model as the last-resort safety net

At minimum, the auth-fallback semantics should be consistent with the primary runtime, which already falls through on auth errors.

Actual behavior

For auxiliary tasks using an explicit provider:

• 401 / auth errors go through same-provider recovery only
• if recovery does not fix the error, the request raises without trying fallback_chain
• main-agent fallback is also skipped

So auxiliary auth failures behave differently from payment / connection / rate-limit failures.

Why this looks like a bug

The code comments and fallback structure strongly suggest that auxiliary fallback is intended to provide a safety net when the configured auxiliary backend cannot serve the request.

But the current gate excludes auth failures from should_fallback, so the fallback code path is never entered for 401.

Code evidence

Primary runtime does auth fallback:

• gateway/run.py:1064-1069
  • catches AuthError
  • logs Primary provider auth failed ... trying fallback
  • calls _try_resolve_fallback_provider()
• gateway/run.py:1118-1127
  • fallback resolution returns the fallback provider config, including the fallback model

Auxiliary runtime does not auth fallback:

• agent/auxiliary_client.py:4973-4988
  • should_fallback includes only:
    • _is_payment_error(first_err)
    • _is_connection_error(first_err)
    • _is_rate_limit_error(first_err)
  • _is_auth_error(first_err) is not included
  • therefore if should_fallback and (is_auto or is_capacity_error): is never entered for 401 auth failures
• agent/auxiliary_client.py:5005-5020
  • this is where auxiliary fallback ordering is implemented:
    1. _try_configured_fallback_chain(...)
    2. _try_main_agent_model_fallback(...)
  • but this code is unreachable for 401 because the earlier gate blocks it

The asymmetry is visible here:

• primary path falls through on auth
• auxiliary path falls through on payment / connection / rate-limit, but not auth

Reproduction outline

Configuration shape:

• main model/provider configured and working
• auxiliary task configured with an explicit provider
• optional auxiliary fallback_chain configured, or else rely on main-agent fallback as last resort

Trigger:

• make the explicit auxiliary provider return 401 / token_invalidated

Observed result:

• auxiliary call fails after same-provider recovery attempt
• fallback_chain is not tried
• main-agent fallback is not tried

Impact

This breaks the resilience story for auxiliary features under auth expiry / invalidation:

• compression can fail on 401 even though the main runtime would fall back successfully
• users can see auxiliary failures during context compaction or other aux operations despite having a working primary fallback setup
• operators cannot rely on "fallback on everything" semantics for auxiliary tasks

Expected vs actual

Expected:

• auxiliary 401 auth failure -> recovery attempt -> fallback_chain -> main-agent fallback

Actual:

• auxiliary 401 auth failure -> recovery attempt -> exception raised

Environment

• Hermes package: 0.14.0
• Git revision: d7c5d5dee5503bbe1ebbce8fa65b3a8a5746cd19
• Git describe: v2026.5.16-979-gd7c5d5dee

Suggested direction

After same-provider auth recovery is attempted and still fails, auxiliary fallback should likely treat _is_auth_error(first_err) similarly to the primary runtime and continue into:

1. auxiliary.<task>.fallback_chain
2. _try_main_agent_model_fallback(...)

That would make auxiliary auth behavior consistent with the primary auth-fallback path.