Issue Station
Sign In
Tools hereToolbox

hermes - ✅(Solved) Fix [Bug]: In auxiliary client, an exhausted OpenRouter key is logged as key not being set [2 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#14618•Fetched 2026-04-24 06:15:55
View on GitHub
Comments
0
Participants
1
Timeline
7
Reactions
0
Author
AllardQuekAllardQuek
Participants
AllardQuekAllardQuek
Timeline (top)
labeled ×4cross-referenced ×2closed ×1

Error Message

Additional Logs / Traceback (optional)

Root Cause

Root Cause Analysis (optional)

Fix Action

Fixed

PR fix notes

PR #14646: fix(agent): clarify exhausted OpenRouter auxiliary credentials

Description (problem / solution / changelog)

Fixes #14618.

Root cause

The explicit OpenRouter auxiliary path collapsed two different failure modes into the same warning. When the OpenRouter credential pool existed but pool.select() could not produce a usable entry (for example exhausted credentials), Hermes logged the same OPENROUTER_API_KEY not set message used for a truly missing env var.

What changed

  • added a small helper to describe why OpenRouter credentials are unavailable
  • distinguish credential-pool exhaustion / unusable pool entries from a genuinely missing OPENROUTER_API_KEY
  • added regression tests for both the exhausted-pool path and the missing-env path

Tests

  • python -m pytest tests/agent/test_auxiliary_client.py -q --tb=short
  • git diff --check

Changed files

  • agent/auxiliary_client.py (modified, +17/-2)
  • tests/agent/test_auxiliary_client.py (modified, +28/-0)

PR #14739: fix(agent): clarify exhausted OpenRouter auxiliary credentials (salvage #14646)

Description (problem / solution / changelog)

Salvages #14646 (@sgaofen) onto current main.

Distinguishes exhausted OpenRouter credential pool from a genuinely missing OPENROUTER_API_KEY in the auxiliary client warning log. Closes #14618.

Changes

  • agent/auxiliary_client.py: new _describe_openrouter_unavailable() helper; openrouter branch in _wrap_if_needed logs the precise reason instead of a hardcoded "not set" message.
  • tests/agent/test_auxiliary_client.py: regression tests for exhausted-pool and missing-env paths.

Validation

scripts/run_tests.sh tests/agent/test_auxiliary_client.py — 84/84 pass.

Closes #14618. Closes #14646.

Changed files

  • agent/auxiliary_client.py (modified, +17/-2)
  • tests/agent/test_auxiliary_client.py (modified, +28/-0)

Code Example

Debug report uploaded:
  Report     https://paste.rs/sqGOH
  agent.log  https://paste.rs/iGTHz

---
RAW_BUFFERClick to expand / collapse

Bug Description

In auxiliary client, an exhausted OpenRouter key is logged as key not being set which is misleading.

Steps to Reproduce

  1. Use an exhausted OpenRouter key for auxiliary task

Expected Behavior

Hermes should differentiate between key not being set (i.e. empty) v.s. invalid keys or keys with spend limit exceeded, etc. so that more descriptive logs can be provided.

Actual Behavior

Logs show: WARNING agent.auxiliary_client: resolve_provider_client: openrouter requested but OPENROUTER_API_KEY not set

Affected Component

Other

Messaging Platform (if gateway-related)

No response

Debug Report

Debug report uploaded:
  Report     https://paste.rs/sqGOH
  agent.log  https://paste.rs/iGTHz

Operating System

MacOS 26.4

Python Version

No response

Hermes Version

No response

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

No response

Proposed Fix (optional)

No response

Are you willing to submit a PR for this?

  • I'd like to fix this myself and submit a PR

extent analysis

TL;DR

The issue can be addressed by modifying the logging mechanism in the auxiliary client to differentiate between an exhausted OpenRouter key and a key that is not set.

Guidance

  • Review the resolve_provider_client function in the auxiliary client to understand how it handles OpenRouter key validation and logging.
  • Modify the logging statement to include more descriptive information about the error, such as "OpenRouter key exhausted" or "Invalid OpenRouter key".
  • Consider adding additional error handling to distinguish between different types of key-related errors, such as key not set, key invalid, or key exhausted.
  • Examine the debug report and agent.log to gain more insight into the issue and identify potential areas for improvement.

Example

No code example is provided due to lack of specific implementation details.

Notes

The solution may require modifications to the Hermes codebase, and the exact changes will depend on the specific implementation details. Additionally, the issue may be related to the OpenRouter API or the auxiliary client's interaction with it.

Recommendation

Apply workaround: Modify the logging mechanism to provide more descriptive error messages, as this will help to differentiate between an exhausted OpenRouter key and a key that is not set, and will provide more informative logs.

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…
#api#mixed precision#training loop#device allocation#model download

Still need to ship something?

×6

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

Back to top recommendations

TRENDING