hermes - 💡(How to fix) Fix [Bug] auxiliary task provider identity lost when base_url + api_key are both set [1 pull requests]

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…

When users configure an auxiliary task (e.g. auxiliary.vision) with provider, base_url, and api_key all set, the provider name is silently discarded and replaced with "custom".

This causes provider-specific code paths (ZAI vision max_tokens skip, Anthropic transport detection, custom headers, etc.) to be bypassed, leading to subtle failures.

Error Message

  1. #26827: max_tokens sent to GLM vision API -> error 1210 (the _skip_max_tokens guard only checks provider == "zai")

Root Cause

In _resolve_task_provider_model (line 3985-3987):

if cfg_base_url and cfg_api_key:
    # Both base_url and api_key explicitly set -> custom endpoint.
    return "custom", resolved_model, cfg_base_url, cfg_api_key, resolved_api_mode

This branch ignores cfg_provider entirely. The subsequent code in resolve_vision_provider_client and _build_call_kwargs can no longer distinguish between:

  • A user who explicitly set provider: glm with a specific GLM endpoint
  • A user who set a truly custom endpoint with provider: custom

Fix Action

Fixed

Code Example

auxiliary:
  vision:
    provider: glm
    model: glm-4v-flash
    base_url: "https://open.bigmodel.cn/api/paas/v4/"
    api_key: "<key>"

---

if cfg_base_url and cfg_api_key:
    # Both base_url and api_key explicitly set -> custom endpoint.
    return "custom", resolved_model, cfg_base_url, cfg_api_key, resolved_api_mode

---

if cfg_base_url and cfg_api_key:
    effective_provider = cfg_provider if cfg_provider and cfg_provider != "auto" else "custom"
    return effective_provider, resolved_model, cfg_base_url, cfg_api_key, resolved_api_mode
RAW_BUFFERClick to expand / collapse

Description

When users configure an auxiliary task (e.g. auxiliary.vision) with provider, base_url, and api_key all set, the provider name is silently discarded and replaced with "custom".

This causes provider-specific code paths (ZAI vision max_tokens skip, Anthropic transport detection, custom headers, etc.) to be bypassed, leading to subtle failures.

Steps to Reproduce

auxiliary:
  vision:
    provider: glm
    model: glm-4v-flash
    base_url: "https://open.bigmodel.cn/api/paas/v4/"
    api_key: "<key>"

Root Cause

In _resolve_task_provider_model (line 3985-3987):

if cfg_base_url and cfg_api_key:
    # Both base_url and api_key explicitly set -> custom endpoint.
    return "custom", resolved_model, cfg_base_url, cfg_api_key, resolved_api_mode

This branch ignores cfg_provider entirely. The subsequent code in resolve_vision_provider_client and _build_call_kwargs can no longer distinguish between:

  • A user who explicitly set provider: glm with a specific GLM endpoint
  • A user who set a truly custom endpoint with provider: custom

Impact

  1. #26827: max_tokens sent to GLM vision API -> error 1210 (the _skip_max_tokens guard only checks provider == "zai")
  2. No ZAI vision fast-path: resolve_vision_provider_client line 3562-3587 has a dedicated ZAI OpenAI-wire route that forces api_mode="chat_completions" -- but it only triggers for requested == "zai", never for "custom"
  3. No provider headers: GLM, Xiaomi MiMo, and other providers that need custom headers via provider profiles get skipped

Suggested Fix

When cfg_provider is set alongside base_url + api_key, preserve the provider name:

if cfg_base_url and cfg_api_key:
    effective_provider = cfg_provider if cfg_provider and cfg_provider != "auto" else "custom"
    return effective_provider, resolved_model, cfg_base_url, cfg_api_key, resolved_api_mode

This way the downstream code can still apply provider-specific logic while using the explicit endpoint credentials.

Environment

  • Hermes Agent latest (2026-05)
  • Affects any auxiliary task with provider + base_url + api_key configured together

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

hermes - 💡(How to fix) Fix [Bug] auxiliary task provider identity lost when base_url + api_key are both set [1 pull requests]