Issue Station
Sign In
Tools hereToolbox

hermes - ✅(Solved) Fix custom provider: stale_timeout_seconds and HERMES_API_CALL_STALE_TIMEOUT are ignored — hardcoded 30s timeout [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#25249•Fetched 2026-05-14 03:47:51
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
rptmatroxrptmatrox
Participants
rptmatroxrptmatrox
Timeline (top)
labeled ×4cross-referenced ×1

When using a custom provider (Ollama/local LLM), the stale_timeout_seconds config key and HERMES_API_CALL_STALE_TIMEOUT env var have no effect. The timeout is always ~30s regardless of what is set.

Error Message

Every attempt always times out at exactly ~30s (Elapsed: 30.3xs), regardless of config. Additionally, even with api_max_retries: 0, Hermes always makes one extra attempt (🔁 Transient APITimeoutError — rebuilt client, waiting 4s before one last primary attempt), resulting in a minimum of ~64s before fallback engages.

Root Cause

When using a custom provider (Ollama/local LLM), the stale_timeout_seconds config key and HERMES_API_CALL_STALE_TIMEOUT env var have no effect. The timeout is always ~30s regardless of what is set.

Fix Action

Fixed

PR fix notes

PR #25260: fix(agent): honor provider timeout config in streaming API calls

Description (problem / solution / changelog)

Summary

Fixes two bugs in the streaming chat-completions path that caused stale_timeout_seconds and request_timeout_seconds provider configs to be silently ignored.

Bugs Fixed

Bug 1: Hardcoded connect/pool timeout

The httpx.Timeout for streaming calls used hardcoded connect=30.0 and pool=30.0 regardless of the user`s providers.<id>.request_timeout_seconds config. If a custom provider (e.g. Ollama) was unreachable, the call always waited exactly 30s before failing.

Fix: Use _base_timeout (from config) for connect and pool phases when the user has set request_timeout_seconds. Fall back to 30.0 when no config is set (preserving existing behavior).

Bug 2: Streaming stale timeout ignored provider config

The stream stale detector read only the HERMES_STREAM_STALE_TIMEOUT env var (default 180s). The providers.<id>.stale_timeout_seconds config key was never consulted for streaming calls, despite being correctly used for non-streaming calls.

Fix: Check get_provider_stale_timeout() first, then fall back to the env var. Aligns streaming path with non-streaming priority chain: config → env → default.

Before/After

Before (custom provider unreachable):

  • stale_timeout_seconds: 5 → ignored, always times out at 30s
  • request_timeout_seconds: 10 → only affects read/write, connect stuck at 30s

After:

  • stale_timeout_seconds: 5 → stale detector triggers at 5s
  • request_timeout_seconds: 10 → connect/read/write/pool all capped at 10s

Testing

  • All 12 tests in test_timeouts.py pass
  • All 17 tests in test_provider_config_validation.py pass

Files Changed

FileChange
run_agent.pyStreaming httpx.Timeout: use config for connect/pool; streaming stale: read provider config

Closes #25249

Changed files

  • run_agent.py (modified, +11/-3)

Code Example

providers:
  custom:
    stale_timeout_seconds: 5
RAW_BUFFERClick to expand / collapse

Summary

When using a custom provider (Ollama/local LLM), the stale_timeout_seconds config key and HERMES_API_CALL_STALE_TIMEOUT env var have no effect. The timeout is always ~30s regardless of what is set.

Environment

  • Hermes Agent v0.13.0 (2026.5.7)
  • Provider: custom (Ollama via OpenAI-compatible endpoint)
  • Docker deployment

Config applied (ignored)

providers:
  custom:
    stale_timeout_seconds: 5

Also tried via env var: HERMES_API_CALL_STALE_TIMEOUT=5 HERMES_API_TIMEOUT=10

Observed behavior

Every attempt always times out at exactly ~30s (Elapsed: 30.3xs), regardless of config. Additionally, even with api_max_retries: 0, Hermes always makes one extra attempt (🔁 Transient APITimeoutError — rebuilt client, waiting 4s before one last primary attempt), resulting in a minimum of ~64s before fallback engages.

Expected behavior

stale_timeout_seconds: 5 should cause the timeout at ~5s, enabling faster fallback to OpenRouter when the local provider is unreachable.

Use case

Local LLM as primary (free), OpenRouter as fallback when local machine is offline. Fast fallback (~10s) is essential for good UX on Discord gateway.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

stale_timeout_seconds: 5 should cause the timeout at ~5s, enabling faster fallback to OpenRouter when the local provider is unreachable.

#api#cache error#pipeline error#runtime error#dependency conflict

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING