Issue Station
Sign In
Tools hereToolbox

hermes - ✅(Solved) Fix vision_analyze: _client_cache key missing model causes wrong model to be used [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#14085•Fetched 2026-04-23 07:46:51
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
shakeshake
Participants
shakeshake
Timeline (top)
labeled ×4cross-referenced ×1

Error Message

  1. Observe error: invalid params, unknown model 'openai/gpt-4o' (2013) — this happens because the cached client (created with google/gemini-3-flash-preview) receives a request with model openai/gpt-4o, which OpenRouter rejects

Root Cause

  1. Configure auxiliary.vision with provider: "auto" and model: "openai/gpt-4o" in config.yaml
  2. Set OPENROUTER_API_KEY environment variable
  3. Call vision_analyze tool
  4. Observe error: invalid params, unknown model 'openai/gpt-4o' (2013) — this happens because the cached client (created with google/gemini-3-flash-preview) receives a request with model openai/gpt-4o, which OpenRouter rejects

Fix Action

Fixed

PR fix notes

PR #14249: fix(agent): include model in auxiliary client cache key

Description (problem / solution / changelog)

Summary

Fixes a bug where _client_cache_key only used provider as the cache key, causing different model parameters to return the same cached client and leading to wrong models being used for vision requests.

Root Cause

_client_cache_key() generated cache keys as (provider, async_mode, base_url, api_key, api_mode, runtime_key), omitting model. When the first call with provider="openrouter" cached a client for google/gemini-3-flash-preview, subsequent calls with openai/gpt-4o hit the same cache entry because the key did not differentiate by model. The cached client then sent requests with the wrong model, causing OpenRouter to reject them with invalid params, unknown model 'openai/gpt-4o' (2013).

Changes

  • Added model: Optional[str] = None parameter to _client_cache_key()
  • Included model in the returned cache key tuple
  • Updated _refresh_nous_auxiliary_client() and _get_cached_client() to pass model through
  • Updated the cache key comment to reflect the new structure

Testing

  • Python syntax check passed (py_compile)
  • Ran related test suite:
    • tests/agent/test_auxiliary_client.py ✅
    • tests/agent/test_crossloop_client_cache.py ✅
    • tests/agent/test_vision_resolved_args.py ✅
    • 87 passed, 1 failed (failure is an unrelated environment proxy issue: socks://proxyhk.zte.com.cn:80)

Related Issue

Fixes #14085

Changed files

  • agent/auxiliary_client.py (modified, +5/-2)

Code Example

_client_cache: dict[str, Any] = {}

---

def _resolve_strict_vision_backend(provider: str) -> Tuple[Optional[Any], Optional[str]]:
    ...
    if provider == "openrouter":
        return _try_openrouter()  # Returns google/gemini-3-flash-preview as default_model

---

client = _client_cache.get(client_cache_key)
...
if resolved_model is None:
    resolved_model = default_model
RAW_BUFFERClick to expand / collapse

Bug Description

The _client_cache in auxiliary_client.py uses only provider as the cache key, not including model. This causes different model parameters to return the same cached client, leading to wrong model being used for vision requests.

Code Location

agent/auxiliary_client.py

Problematic Code

  1. _client_cache definition (line ~2450):
_client_cache: dict[str, Any] = {}

Cache key is only provider, not (provider, model).

  1. _resolve_strict_vision_backend for "openrouter" (line ~1936):
def _resolve_strict_vision_backend(provider: str) -> Tuple[Optional[Any], Optional[str]]:
    ...
    if provider == "openrouter":
        return _try_openrouter()  # Returns google/gemini-3-flash-preview as default_model

When provider == "openrouter", the function always returns google/gemini-3-flash-preview as the default_model, ignoring whatever model was passed by the caller.

  1. Cache usage in _finalize (line ~2057):
client = _client_cache.get(client_cache_key)
...
if resolved_model is None:
    resolved_model = default_model

Since client_cache_key only contains provider (e.g., "openrouter") but not model, the first call with google/gemini-3-flash-preview caches that client. Subsequent calls with openai/gpt-4o return the same cached client, using the wrong model.

Reproduction Steps

  1. Configure auxiliary.vision with provider: "auto" and model: "openai/gpt-4o" in config.yaml
  2. Set OPENROUTER_API_KEY environment variable
  3. Call vision_analyze tool
  4. Observe error: invalid params, unknown model 'openai/gpt-4o' (2013) — this happens because the cached client (created with google/gemini-3-flash-preview) receives a request with model openai/gpt-4o, which OpenRouter rejects

Expected Behavior

Different model parameters should use different cached clients, or the cache should be invalidated when model changes.

Related Issues

  • #13065 (related: vision model selection issues)

extent analysis

TL;DR

Update the _client_cache key to include both provider and model to ensure different models use separate cached clients.

Guidance

  • Modify the _client_cache definition to use a tuple of (provider, model) as the cache key.
  • Update the _resolve_strict_vision_backend function to consider the provided model when resolving the vision backend for "openrouter".
  • Verify the fix by running the reproduction steps with different models and checking that the correct model is used for each request.
  • Consider adding a cache invalidation mechanism to handle model changes.

Example

_client_cache: dict[tuple[str, str], Any] = {}

And when using the cache:

client_cache_key = (provider, model)
client = _client_cache.get(client_cache_key)

Notes

This fix assumes that the model parameter is available when creating the cache key. If the model is not always available, additional logic may be needed to handle this case.

Recommendation

Apply the workaround by updating the _client_cache key to include both provider and model, as this directly addresses the root cause of the issue.

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#runtime error#dependency conflict#environment setup#environment variable

Still need to ship something?

×6

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

Back to top recommendations

TRENDING