[Bug] zai provider ignores config.yaml base_url and always probes endpoints in hardcoded order — standard endpoint always wins over coding endpoint

[wyl1988]

Bug Description

The zai provider's _resolve_zai_base_url() function in hermes_cli/auth.py completely ignores the base_url configured in config.yaml. Instead, it probes a hardcoded list of 4 endpoints in order:

ZAI_ENDPOINTS = [
    ("global",        "https://api.z.ai/api/paas/v4"),
    ("cn",            "https://open.bigmodel.cn/api/paas/v4"),
    ("coding-global", "https://api.z.ai/api/coding/paas/v4"),
    ("coding-cn",     "https://open.bigmodel.cn/api/coding/paas/v4"),
]

The same API key works on both standard and coding endpoints. Since probing takes the first endpoint that succeeds, standard endpoints always win — coding endpoints (positions 3-4) are unreachable.

Related issue #51229 addresses cache persistence but not the core problem: config.yaml's base_url field is ignored entirely.

Impact

Zhipu AI offers separate Coding Plan endpoints (/coding/paas/v4) with different quota/pricing. Users who configure base_url: https://open.bigmodel.cn/api/coding/paas/v4 in config.yaml expect all requests to go through that endpoint. Instead:

1. config.yaml's base_url is silently ignored
2. Every gateway restart triggers endpoint probing
3. Each probe sends a glm-5, max_tokens=1 test request to the standard endpoint — wasting tokens
4. The standard endpoint is always selected first
5. All subsequent requests burn standard-endpoint quota

In a 20-profile deployment, switching from hindsight to openviking required gateway restarts that triggered mass re-probing, accidentally routing all traffic to standard endpoints for days before detection.

Workaround

Set environment variable GLM_BASE_URL (source line 670-671 in auth.py). This bypasses probing entirely:

if env_override:
    return env_override

But this requires setting GLM_BASE_URL in every .env file, every systemd Environment= directive, AND every EnvironmentFile — because EnvironmentFile silently overrides Environment for same-named variables.

Expected Behavior

config.yaml's base_url should be respected as the authoritative endpoint. Probing should only be a fallback when base_url is not explicitly configured.

# Proposed priority:
# 1. GLM_BASE_URL env var (current — keep)
# 2. config.yaml base_url (NEW — currently ignored!)
# 3. auth.json cached detection (current — keep)
# 4. Live probing (current — last resort only)

Environment

• Hermes Agent: 0.18.0
• Provider: zai (Zhipu AI / Z.AI)
• Deployment: 20 profiles, all using GLM-5.2 via coding endpoint
• Issue discovered: 2026-06-27, affecting all 20 profiles

[DeamonDev888]

This is exactly the bug that sparked PR #62467. The unified resolve_provider_credentials() in that PR fixes this in two ways:

1. Config.yaml precedence — model.base_url is now honored as Step 4 of the resolver, with a guard that preserves non-default pool URLs (per teknium1's review feedback).
2. Probe ordering — Coding endpoints (/api/coding/paas/v4) are probed before standard endpoints (/api/paas/v4), so Coding Plan keys get the right URL cached.

The _resolve_zai_base_url() function is now called from both the auxiliary path and the runtime path (previously only auxiliary), so Desktop and Gateway sessions also benefit.

PR: #62467

[DeamonDev888]

PR #66971 (hermes auth add --base-url) fixes this directly.

The bug: Z.AI endpoint probe order tests the standard /paas/v4 endpoint first, which responds 200 on Coding Plan keys (because glm-5 is available on both). So the detected endpoint becomes /paas/v4 (metered) instead of /coding/paas/v4 (subscription quota).

What #66971 does: hermes auth add --base-url lets you pin the correct endpoint:

hermes auth add zai --type api-key --api-key KEY --base-url https://api.z.ai/api/coding/paas/v4

This bypasses the probe entirely — the base_url is stored on the pool entry and used directly. hermes auth list shows coding tag for each entry, confirming the endpoint.

The unified resolver in #62467 also reverses the probe order (coding endpoints first), but if you just want the CLI fix without the full resolver refactor, #66971 is the targeted solution.

[GottZ]

This was generated by AI during triage.

Summary

One PR directly addresses #58071. #58088 changes the shared Z.AI credential resolver to honor a matching config.yaml model.base_url after GLM_BASE_URL but before cached detection and live probing, eliminating the reported silent fallback to the standard endpoint.

Related pull requests

• fix(zai): honor configured base url #58088 best fix — (+97/-5) — fixes: Adds explicit config.yaml endpoint precedence for Z.AI aliases while preserving GLM_BASE_URL as the highest-priority override and preventing unrelated providers' URLs from leaking into Z.AI resolution; its tests verify configured-URL selection, probe bypass, and precedence. The contributor keep_open review on fix(zai): honor configured base url #58088 agrees that this fixes the resolver gap and requests additional end-to-end regressions for the glm runtime alias and an auxiliary direct-provider caller.

Suggested consolidation

Merge #58088 after adding the two regressions requested by the contributor keep_open review: a model.provider: glm runtime test and an auxiliary direct-provider test. It is the focused fix for #58071's root cause; no listed PR is a duplicate to close.

Complex graph

flowchart LR
    classDef open fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a
    classDef merged fill:#dcfce7,stroke:#15803d,color:#14532d
    classDef closed fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    classDef unverified fill:#f3f4f6,stroke:#9ca3af,color:#374151
    classDef best stroke-width:3px,stroke:#b45309
    classDef target stroke-width:3px,stroke:#4338ca
    I58071(["issue #58071 (open)"])
    P58088["PR #58088 (open)"]
    P58088 -->|best fix| I58071
    class I58071 open
    class I58071 target
    class P58088 open
    class P58088 best
    click I58071 "https://github.com/NousResearch/hermes-agent/issues/58071"
    click P58088 "https://github.com/NousResearch/hermes-agent/pull/58088"

Loading

Graph: solid arrow = fixes / best fix, dashed arrow = partial or unverified (see edge label); boxed group = PRs duplicating each other; amber border = best fix; indigo border = target; gray node = closed or no verify verdict yet (state tag in the node label).

Cross-PR triage: Reviewed 1 pull request and 1 issue in this complex. Each diff was read against this issue; Assessment working set: 6 kB of PR diffs, 5 kB of issue/PR text, 3 kB of discussion (5 comments), 2 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.