## Bug Report: Cannot use GLM for both main agent and auxiliary title generation simultaneously

[mis3250]

Bug Report: Cannot use GLM for both main agent and auxiliary title generation simultaneously

Summary

When using GLM as the main agent via the Anthropic-compatible endpoint (/api/anthropic), auxiliary tasks like title generation cannot use GLM's OpenAI-compatible endpoint (/api/paas/v4) even when base_url is explicitly set in config.yaml. This is because GLM_BASE_URL always overrides any base_url specified under auxiliary.title_generation in config.yaml.

Environment

• Hermes Web UI (latest, cloned from main)
• GLM main agent endpoint: https://open.bigmodel.cn/api/anthropic
• OS: Ubuntu (WSL2)

Steps to Reproduce

1. Set GLM_BASE_URL=https://open.bigmodel.cn/api/anthropic in ~/.hermes/.env (required for main agent to work via Anthropic-compatible endpoint)
2. Configure auxiliary.title_generation in config.yaml with an explicit OpenAI-compatible base URL:

   auxiliary:
     title_generation:
       provider: zai
       model: glm-4-flash
       base_url: https://open.bigmodel.cn/api/paas/v4
       api_key: ''
       timeout: 30
       extra_body: {}

3. Start Hermes and send a chat message.

Expected Behavior

The base_url explicitly set under auxiliary.title_generation in config.yaml should take priority for auxiliary tasks, allowing the main agent and title generation to use different GLM endpoints.

Actual Behavior

Title generation fails with:

⚠ Auxiliary title generation failed: HTTP 401: 令牌已过期或验证不正确

This happens because _resolve_zai_base_url() in hermes_cli/auth.py gives GLM_BASE_URL absolute priority:

def _resolve_zai_base_url(api_key, default_url, env_override):
    if env_override:  # GLM_BASE_URL always wins — ignores config.yaml base_url
        return env_override

So the Anthropic-format endpoint is used for title generation too, which returns 401 since it doesn't accept OpenAI-format requests.

Root Cause

GLM_BASE_URL is a single global variable controlling the GLM endpoint for the entire application. There is no way to specify different endpoints for the main agent vs auxiliary tasks. The base_url field in auxiliary.title_generation config is silently ignored for the zai provider.

Suggested Fix

In _resolve_zai_base_url(), check for an explicit base_url passed from the auxiliary config before falling back to GLM_BASE_URL:

def _resolve_zai_base_url(api_key, default_url, env_override, explicit_base_url=None):
    if explicit_base_url:  # config.yaml base_url takes priority for aux tasks
        return explicit_base_url
    if env_override:       # GLM_BASE_URL wins for main agent
        return env_override
    ...

Alternatively, introduce a separate GLM_AUX_BASE_URL environment variable for auxiliary tasks.

Impact

Any user running GLM via the Anthropic-compatible endpoint as their main model cannot use GLM for auxiliary tasks (title generation, vision, web extract, etc.) without breaking their main agent configuration.

[nesquena-hermes]

Thanks for the detailed report and for tracing it down to _resolve_zai_base_url().

The root cause is correct: GLM_BASE_URL is a process-global env override, and there's no mechanism for auxiliary task configs to provide a different endpoint. Since GLM exposes two distinct API formats at two different URL paths (Anthropic-compatible at /api/anthropic, OpenAI-compatible at /api/paas/v4), a single global override necessarily forces all callers to the same format — which breaks when the main agent and auxiliary tasks need different protocol formats.

On the suggested fix: the explicit_base_url priority approach is the right direction. The config-specified base_url under auxiliary.title_generation should win for auxiliary callers, since that's the explicit per-task configuration. GLM_BASE_URL as a process-wide default should only apply when no explicit base_url is set. The priority order you've proposed (explicit config > env override > default) is consistent with how other providers handle this pattern.

The alternative (separate GLM_AUX_BASE_URL) is a reasonable workaround but would proliferate env variables and doesn't solve the underlying issue for users who configure base_url in their YAML expecting it to be respected.

Impact scope: this affects any user running GLM where the main agent endpoint differs from the auxiliary endpoint — which is exactly the case when using the Anthropic-compatible route for the main agent.

Logging as a bug. The fix is in hermes_cli/auth.py in _resolve_zai_base_url(). Would accept a PR with the priority change and a regression test covering the case where explicit_base_url is provided alongside a set GLM_BASE_URL.

[nesquena-hermes]

Root cause confirmed: _resolve_zai_base_url() in hermes_cli/auth.py gives GLM_BASE_URL unconditional priority, silently ignoring any base_url explicitly set in auxiliary.title_generation (or other auxiliary blocks) in config.yaml.

Contributor pickup: The fix is a small, well-scoped change. If you'd like to contribute a fix:

1. Find _resolve_zai_base_url() in hermes_cli/auth.py
2. Add an explicit_base_url=None parameter and check it before env_override:

   def _resolve_zai_base_url(api_key, default_url, env_override, explicit_base_url=None):
       if explicit_base_url:   # config.yaml base_url takes priority for aux tasks
           return explicit_base_url
       if env_override:        # GLM_BASE_URL wins for main agent
           return env_override
       ...

3. Pass the base_url value from the auxiliary config block wherever _resolve_zai_base_url() is called for auxiliary tasks
4. Add a test: auxiliary config with explicit base_url should not be overridden by GLM_BASE_URL
5. Open a PR referencing this issue

The core change is under 10 lines. The fix would let any GLM user run their main agent on the Anthropic-compat endpoint while routing auxiliary tasks to the OpenAI-compat endpoint.

[bergeouss]

Investigation — Root Cause in hermes-agent (upstream)

After tracing the full title generation flow, the root cause is in hermes-agent (agent/auxiliary_client.py), not in hermes-webui.

Two bugs found:

1. _resolve_task_provider_model() forces provider to "custom" when base_url is set
File: agent/auxiliary_client.py:3128-3131

When a user configures auxiliary.title_generation with both provider: zai and base_url: https://open.bigmodel.cn/api/paas/v4, the function returns ("custom", ...) — discarding the "zai" provider name. The "custom" provider resolves API keys from OPENAI_API_KEY, but the user's GLM key is in GLM_API_KEY. Result: 401.

2. _resolve_zai_base_url() always honors GLM_BASE_URL env var
File: hermes_cli/auth.py:602-611

When GLM_BASE_URL=https://open.bigmodel.cn/api/anthropic is set (required for the main agent), any auxiliary task using "zai" without an explicit base_url inherits this Anthropic endpoint. The auxiliary client uses OpenAI SDK → sends OpenAI-format requests to an Anthropic endpoint → 401.

Proposed fix (hermes-agent repo):

In _resolve_task_provider_model() (line 3130-3131): when both cfg_provider and cfg_base_url are set, pass the provider through instead of forcing "custom".

if cfg_base_url and cfg_provider:
    return cfg_provider, resolved_model, cfg_base_url, cfg_api_key, resolved_api_mode
if cfg_base_url:
    return "custom", resolved_model, cfg_base_url, cfg_api_key, resolved_api_mode

The existing explicit_base_url override path in resolve_provider_client() (line 2363-2369) already handles this correctly — the zai handler will use the explicit base_url with the zai API key.

Suggestion:

• Move this issue to NousResearch/hermes-agent or open a companion issue there
• Existing test file: tests/test_title_aux_routing.py (489 lines)

🤖 AI-assisted via Hermes Agent

[nesquena-hermes]

Thanks for the upstream trace. You've correctly identified that the canonical fix lives in hermes-agent, not hermes-webui — both _resolve_task_provider_model() (agent/auxiliary_client.py:3128-3131) and _resolve_zai_base_url() (hermes_cli/auth.py:602-611) are agent-side. The webui repo only consumes the agent's resolved auxiliary client, so a webui-only patch would have to monkey-patch the agent module — wrong layer.

The two-bug picture you've drawn matches the symptoms in this issue:

1. Provider clobber on base_url set — _resolve_task_provider_model() returns ("custom", ...) whenever cfg_base_url is truthy, discarding cfg_provider="zai" and routing API-key resolution through OPENAI_API_KEY. That alone would cause 401 even without the second bug, because the auxiliary client never sees the user's GLM_API_KEY.
2. GLM_BASE_URL env override unconditional — even after the provider survives to "zai", the env override path in _resolve_zai_base_url() still beats explicit base_url from auxiliary config. So format mismatch would persist in the case where (1) is fixed but (2) isn't.

Your proposed shape — if cfg_base_url and cfg_provider: return cfg_provider, ... before falling through to the "custom" path — is the right minimal change for (1). The resolve_provider_client() explicit_base_url plumbing already handles routing once the provider is preserved. (2) is the second priority-order fix per my earlier comment.

Filed an upstream-tracking note. Keeping this issue open as a tracking shell for the hermes-webui side; the actual code fix lands in hermes-agent. If/when an agent PR is cut, link it here so the trail stays connected for users searching this symptom.