fix(auxiliary): honor Z.AI detected_endpoint for vision provider resolution and add glm-4.6v for vision model on GLM coding plan - #74071
Open
Musanna-al-akil wants to merge 3 commits into
Open
Conversation
…lution
Z.AI Coding Lite / Coding Plan keys are only valid on the
/api/coding/paas/v4 endpoint, but the vision resolver
(resolve_vision_provider_client) only tried the hardcoded generic
/api/paas/v4 URLs, producing error 1113 ("insufficient balance") on
otherwise valid accounts.
The main chat model already avoided this by reading the endpoint
auto-detected at setup time (auth.json providers.zai.detected_endpoint)
via the credential pool. This extends the same detected_endpoint lookup
to the vision resolver path, with a key_hash guard to prevent a stale
cached endpoint from poisoning resolution.
Also adds glm-4.6v to the Z.AI provider model list.
alt-glitch
added
type/bug
Contributor
|
Thanks for tracing the explicit Z.AI vision path. The premise is real: current main forces that path through generic PaaS URLs at Problems
Suggested changes
Automated hermes-sweeper review. |
teknium1
added
the
sweeper:blast-contained
…al resolver The initial vision fix read auth.json directly for the detected endpoint, bypassing the shared profile→global auth-state fallback that _load_provider_state and read_credential_pool both apply. A profile that resolves a global Z.AI key but has no locally cached detected_endpoint would therefore miss the globally cached endpoint and fall back to the generic URLs, reintroducing error 1113 on Coding Lite/Plan keys. Replace the direct auth.json read with a call to resolve_api_key_provider_credentials, which flows through _resolve_zai_base_url → _load_provider_state and inherits the same profile→global fallback. The resolver also owns GLM_BASE_URL precedence and endpoint detection, keeping all credential-sensitive resolution on one path. Add api_key_override (keyword-only) to resolve_api_key_provider_credentials so the vision resolver can thread its effective key (resolved or pool-sourced) through the same base-URL resolution, keeping cache validation and client construction tied to the same key. Restructure resolve_provider_client's explicit key/base_url handling so a complete caller-supplied pair skips provider discovery, while a partial override still goes through the resolver. Adds a global-auth fallback regression test and glm-4.6v to the Z.AI model list.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Fixes Z.AI vision calls failing with error 1113 ("insufficient balance") for Coding Lite / Coding Plan subscribers. These keys are only valid on the
/api/coding/paas/v4endpoint, but the vision resolver (resolve_vision_provider_client) only tried the hardcoded generic/api/paas/v4URLs — unlike the chat model, which already reads the auto-detected endpoint fromauth.jsonvia the credential pool.This PR extends the same
detected_endpointlookup to the vision resolver path, with akey_hashguard to prevent stale cached endpoints from poisoning resolution. It also addsglm-4.6vto the Z.AI provider model list — on the Coding Plan,glm-5v-turbois not available, makingglm-4.6vthe primary vision model for Z.AI users.Related Issue
Fixes #
Type of Change
Changes Made
agent/auxiliary_client.py—resolve_vision_provider_clientnow reads thedetected_endpointcache fromauth.json(providers.zai.detected_endpoint) and inserts it as the first candidate URL before falling back to the hardcoded generic endpoints. Includes a SHA-256key_hashguard so a stale endpoint cached for a different key is silently skipped. Any error readingauth.jsonis caught and logged at debug level.hermes_cli/models.py— Addsglm-4.6vto the Z.AI provider model list so it appears as a selectable auxiliary vision model.tests/agent/test_zai_vision_detected_endpoint.py(new) — Four regression tests covering: coding endpoint selection, standard endpoint selection, credential-pool-only key resolution, and stale key-hash fallback.How to Test
hermes setupto auto-detect the endpointglm-4.6v) as the auxiliary vision provider/api/coding/paas/v4endpoint is used and vision workspytest tests/agent/test_zai_vision_detected_endpoint.py -vChecklist
Code
fix(scope):,feat(scope):, etc.)pytest tests/ -qand all tests passDocumentation & Housekeeping
docs/, docstrings) — or N/Acli-config.yaml.exampleif I added/changed config keys — or N/ACONTRIBUTING.mdorAGENTS.mdif I changed architecture or workflows — or N/A