fix(auxiliary): don't skip sibling models when a configured fallback_chain reuses the same provider

[okalentiev]

Summary

_try_configured_fallback_chain skips every auxiliary.<task>.fallback_chain
entry whose provider matches the provider that just failed. That's correct
when the provider itself is unreachable (e.g. missing credentials), but it
also fires for a chain that intentionally lists several different models
under the same provider — e.g.

auxiliary:
  compression:
    provider: nvidia
    model: deepseek-ai/deepseek-v4-pro
    fallback_chain:
      - provider: nvidia
        model: minimaxai/minimax-m3
      - provider: nvidia
        model: deepseek-ai/deepseek-v4-flash

When the primary NVIDIA NIM model times out, the provider-only skip check
(fb_provider.lower() == skip) discards both fallback entries — they all
say provider: nvidia — so the configured NIM fallback chain is silently a
no-op. The call falls straight through to the main-agent-model safety net
instead, which in our case was also degraded at the time, producing a
confusing final error that named the main model instead of NIM.

Real trace that surfaced this (from agent.log)

Auxiliary compression: using nvidia (deepseek-ai/deepseek-v4-pro) at https://integrate.api.nvidia.com/v1/
Auxiliary compression: timeout on the critical path; skipping same-provider retry and falling back: Request timed out.
Auxiliary compression: connection error on nvidia (Request timed out.), trying fallback
Auxiliary compression: connection error on nvidia — falling back to main agent model main-agent(openai-codex) (gpt-5.5)
Failed to generate context summary: Codex auxiliary Responses stream exceeded 120.0s total timeout.

The two configured NIM fallback models were never attempted.

Fix

Add an optional failed_model parameter to _try_configured_fallback_chain.
When provided, the skip narrows to the exact (provider, model) pair that
just failed, instead of the whole provider:

if fb_provider.lower() == skip and (
    skip_model is None or fb_model_raw.lower() == skip_model
):
    continue

• _try_configured_fallback_for_unavailable_client (client-build failures,
  where the whole provider is unreachable regardless of model — e.g. missing
  API key) does not pass failed_model, so it keeps the old provider-wide
  skip. That's still correct there.
• The two runtime request-error call sites, call_llm and async_call_llm,
  now pass failed_model=final_model — the model that actually failed — so
  sibling models under the same provider get a chance.

Tests

Added to tests/agent/test_auxiliary_client.py:

• test_same_provider_sibling_model_not_skipped_when_failed_model_given —
  regression test for this exact bug (NVIDIA NIM sibling model chain).
• test_same_provider_same_model_still_skipped — the exact failed
  (provider, model) pair is still excluded.
• test_same_provider_skipped_wholesale_without_failed_model — back-compat:
  callers that don't pass failed_model keep skipping the whole provider.

Also updated 3 pre-existing tests whose assert_called_with(...) checks
needed the new failed_model kwarg added to their expected call signature.

Full relevant suites pass locally: 302 in
test_auxiliary_client.py/test_auxiliary_main_first.py, and 495 across
compression + auxiliary related test files.

Out of scope

Whether the main-agent-model safety net should itself retry/back off
differently when it also times out — that's a separate concern from making
the configured fallback_chain actually usable.

🤖 Patch authored with assistance from Claude Code

[okalentiev]

Pushed a follow-up commit after a self-review caught a regression in the original change.

Regression: narrowing the chain skip to the exact failed (provider, model) pair is only correct for model-specific failures. For auth (401) and payment (402) errors the whole provider is broken (shared credentials/account), so a sibling model on that provider can't recover — and returning that sibling client would bypass the main-agent-model safety net that the old provider-wide skip reached. In auto mode, a 402 could then burn an extra doomed request and fail the aux task instead of falling through to the main model.

Fix: only forward failed_model for model-specific failures (timeout, connection, rate limit, model-incompatible, invalid response). Auth/payment keep failed_model=None → whole-provider skip → main-agent-model safety net, exactly as before.

Added an integration test that a timeout forwards the failed model, and updated the payment-error test to assert failed_model=None. Full test_auxiliary_client.py (297) + related compression suites (172) pass; ruff clean.

[teknium1]

Thanks for the focused fallback-chain fix. Static review confirms the reported behavior remains on current main: agent/auxiliary_client.py:3986 skips every entry sharing the failed provider, and both runtime paths invoke that helper without model identity (agent/auxiliary_client.py:7157, :7166, :7668, :7677).

The PR narrows that skip only for runtime model-specific failures and retains the existing provider-wide behavior for unavailable-client, auth, and payment cases. The sync and async paths are both covered by the proposed change, and no additional runtime callers were found.

This is an automated hermes-sweeper review.

[teknium1]

Merged via PR #72468 — your commits were cherry-picked onto current main with your authorship preserved in git log (rebase merge).

Your fix turned out to matter beyond the configured fallback_chain: the same provider-label-only skip existed in the main-agent-model safety net layer, where it left single-provider users (aux model + main model behind one custom endpoint) with zero working fallbacks for compression. PR #72468 carries your two commits verbatim and extends your failed_model narrowing to that layer too, keeping your auth/payment provider-wide carve-out semantics.

Thanks for the clean fix and the real trace in the PR body — it made the wider bug class easy to confirm.