fix(providers): honor named custom timeout settings

[okbexx]

Summary

• preserve the requested provider identity when a named custom provider canonicalizes to the runtime custom transport
• resolve request and stale timeouts from the named route first, with case-insensitive provider IDs and normalized display-name aliases and providers.custom retained as a fallback
• apply the same identity across initialization, streaming/non-streaming calls, model switching, credential refresh, primary recovery, API/ACP, TUI/background, delegation, curator, and platform fork entry points

Root cause

Named custom providers intentionally resolve to provider="custom" at runtime. Timeout lookup used only that canonical runtime ID, so settings under providers.<named-route> were skipped and the generic stale watchdog default was used instead. Several secondary AIAgent construction paths also dropped the already-resolved requested_provider identity.

Tests

• added an integration regression covering AIAgent(provider="custom", requested_provider="custom:sub2api")
• added identity-propagation assertions for TUI/background, ACP, and API Server agent construction
• 266 targeted tests passed across 12 current test files after rebasing onto the pruned main suite covering timeout resolution, stale watchdogs, custom-provider switching, fallback, rollback, credential-pool recovery, background review, curator, TUI, ACP, API Server, delegation, and Feishu comment agents
• full AST/manual audit covers explicit and **kwargs AIAgent construction paths
• Ruff, bytecode compilation, and git diff --check passed

[alt-glitch]

This was generated by AI during triage.

Related: #34078, #33153, and #28869. #74099 preserves and prioritizes requested custom:<name> config keys, with bare-name and providers.custom fallbacks, across more runtime paths. #34078 forwards the requested route but resolves it to a bare config key. This is a config-contract choice, so these are related competing repairs rather than duplicates.

[okbexx]

Thanks for surfacing #34078, #33153, and #28869. The config contract intended by this PR is deliberately backward-compatible:

1. Preserve the original requested route identity when a named custom provider canonicalizes to the runtime custom transport.
2. Resolve timeouts in this order: the requested providers.custom:<name> route, the equivalent bare/normalized provider key or display-name alias, then the existing providers.custom block as the fallback.
3. Keep model-level timeout overrides ahead of provider-level values at each matched route.

The distinction from #34078 is that this PR does not collapse the config contract to bare keys only. Hermes runtime routing already accepts named custom routes, normalized provider keys, and display name aliases, so timeout resolution follows that same identity contract while retaining providers.custom behavior for existing configurations.

The identity is also preserved through the secondary AIAgent construction paths (TUI/Desktop background and preview agents, ACP, API Server, CLI background, delegation, curator/background review, credential refresh, model switching, and primary recovery), rather than fixing only the main CLI/gateway path.

Current verification after rebasing onto main 240afd0b7 (which pruned the old suite): 266 targeted tests across 12 surviving files, including direct AIAgent(provider="custom", requested_provider="custom:<name>"), mixed-case keys, display-name aliases, fallback/model-switch/recovery, and surface-specific propagation tests. Ruff, bytecode compilation, and git diff --check pass.

I’m happy to narrow or rebase this onto whichever config contract maintainers choose, but wanted to make the compatibility intent explicit.

[teknium1]

Thanks for the focused compatibility repair. The premise is verified on current main: named custom routes are canonicalized to runtime provider custom in hermes_cli/runtime_provider.py:1130, while timeout lookup reads only providers[provider_id] in hermes_cli/timeouts.py:27-40; active request/stale paths therefore miss named-route settings at run_agent.py:1358 and run_agent.py:1381.

The PR's route-first candidate lookup (hermes_cli/timeouts.py:14-95) preserves the requested identity before falling back to providers.custom, and its propagation changes cover the affected initialization, request, recovery, and secondary-agent construction paths. The added timeout regression test covers the canonicalized runtime identity and model-level request/stale precedence.

No blocking issue found in this read-only review. This is an automated hermes-sweeper review.

[GottZ]

This was generated by AI during triage.

Summary

Seven open PRs address or reference this issue complex: #33153, #34078, and #74099 directly repair named-custom-provider timeout lookup, while #33466, #38644, #57194, and #62326 change adjacent timeout or streaming controls without repairing the same identity-loss cause. The direct fixes differ materially: #33153 infers identity from static config, #34078 propagates the runtime-requested provider but uses bare-key resolution, and #74099 propagates that identity across more construction paths with route-first alias and fallback lookup.

Related pull requests

• Fix timeouts for named custom providers #33153 partial — (+75/-8) — n/a: Adds named-custom timeout lookup by rereading model.provider, covering request and stale timeout helpers, but the contributor keep-open review says this can select the wrong per-call identity and leaves explicit/fallback custom:<name> paths unresolved.
• feat: add header_timeout_seconds provider config for response header timeout control #33466 related — (+157/-9) — n/a: Adds a separate provider/model header timeout, not preservation of the named provider identity that causes Named custom provider stale_timeout_seconds ignored because runtime provider is normalized to custom #34001. The contributor keep-open review finds that request-scoped OpenAI timeouts override its client wiring and that native Anthropic and fallback paths are incomplete.
• fix(timeouts): plumb requested_provider through gateway to resolve named custom provider timeouts (#34001) #34078 best fix — (+285/-8) — n/a: The recorded best-fix propagates requested_provider through the gateway and uses it for named-provider request and stale timeout lookup, including direct named-provider syntax. Keep it open rather than treating it as complete: the contributor keep-open review requires rebasing onto the newer runtime layout, covering every timeout call path, and adding runtime-entrypoint tests.
• fix(agent): rebuild correct client on stream retry and add reasoning-only stream watchdog #38644 related — (+414/-14) — n/a: Adds a reasoning-only stream watchdog and client-rebuild changes, rather than fixing named-provider identity propagation. The contributor keep-open review says the rebuild portion is already present on main at a0b9663c7cfed007acede4f1261212811aa623ef and limits the salvageable part to a config-only watchdog.
• fix: support provider-scoped stream_retries config #57194 related — (+357/-76) — n/a: Adds provider/model stream_retries, wires it into chat, Anthropic, and Codex streaming, and changes explicit stream-stale timeout handling; it does not preserve the named custom-provider identity. Its maintainer-bot keep-open verdict supports salvaging this separate configuration feature after the added transport-path tests and documentation are retained.
• feat(config): add streaming override for providers and models #62326 related — (+356/-6) — n/a: Adds provider/model streaming overrides, base-URL fallback lookup, and non-streaming routing, not the requested-provider timeout repair. The contributor keep-open review identified native Anthropic inconsistency; the visible diff now resolves the override in _anthropic_messages_create and adds an Anthropic regression test.
• fix(providers): honor named custom timeout settings #74099 related — (+315/-50) — n/a: Preserves requested named-provider identity across primary, recovery, switching, API/ACP, TUI/background, delegation, curator, and platform-agent paths, then resolves route-specific, bare/alias, and providers.custom timeout settings in precedence order. The maintainer-bot keep-open verdict reports no blocking issue and high salvageability, while the contributor discussion distinguishes this broader config contract from fix(timeouts): plumb requested_provider through gateway to resolve named custom provider timeouts (#34001) #34078 rather than calling it a duplicate.

Suggested consolidation

Keep #74099 open with the concrete salvage path of retaining its route-first alias/fallback lookup, broad identity propagation, and integration coverage while explicitly reconciling the config-key contract with #34078. Preserve #34078 as the recorded best-fix candidate but require author action to rebase onto main and complete the contributor-requested timeout paths and entrypoint tests; #33153 should likewise remain open only for a revised runtime-identity approach, and #33466, #38644, #57194, and #62326 should be triaged separately because their diffs address distinct timeout or streaming features, leaving no evidence-backed duplicate closures in this set.

Cross-PR triage: Reviewed 7 pull requests and 1 issue in this complex. Each diff was read against this issue; Assessment working set: 149 kB of PR diffs, 22 kB of issue/PR text, 16 kB of discussion (13 comments), 3 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.

[ryanmcc09-dot]

Production validation from a multi-profile Hermes deployment:

• Reproduced the named custom-provider timeout identity bug on Hermes Agent v0.20.3, where a configured named route was normalized to runtime provider custom and the provider-specific timeout setting was not honored.
• A focused local repair preserving the requested named-provider identity fixed the observed behavior.
• Upgraded the deployment to current v0.20.5 / main at 7a54ab22.
• The local repair cherry-picked cleanly onto that current main generation with no conflicts.
• Targeted regression test: tests/hermes_cli/test_timeouts.py → 3/3 passed.
• Seven systemd-managed profile gateways plus the remote Desktop backend were restarted successfully on the patched v0.20.5 checkout.

This is additional real-world evidence that the requested named-provider identity needs to survive canonicalization to the runtime custom transport for timeout lookup, and that this fix remains relevant on the current release generation.

For clarity, I’m not opening a competing PR here because #74099 already addresses the same root cause more comprehensively; I wanted to add production validation from a current multi-profile deployment.