Skip to content

[Bug] auxiliary task provider identity lost when base_url + api_key are both set #26879

@zccyman

Description

@zccyman

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. vision_analyze tool fails with GLM (glm-4v-flash) provider: error 1210 request format mismatch #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

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Low — cosmetic, nice to havearea/configConfig system, migrations, profilescomp/agentCore agent loop, run_agent.py, prompt buildertype/bugSomething isn't working

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions