Skip to content

fix(auxiliary): sync missing provider aliases from models.py - #50116

Closed
ryptotalent wants to merge 1 commit into
NousResearch:mainfrom
ryptotalent:fix/aux-provider-aliases
Closed

fix(auxiliary): sync missing provider aliases from models.py#50116
ryptotalent wants to merge 1 commit into
NousResearch:mainfrom
ryptotalent:fix/aux-provider-aliases

Conversation

@ryptotalent

Copy link
Copy Markdown
Contributor

Summary

_PROVIDER_ALIASES in agent/auxiliary_client.py was missing 46 aliases that exist in hermes_cli/models.py. When users configured auxiliary.vision.provider: dashscope (or any of the other missing aliases like aws, hf, nim, deep-seek, mimo, etc.), _normalize_aux_provider() returned the un-normalized string, causing the vision/compression/web_extract pipeline to silently fail because resolve_provider_client() did not recognize the provider.

Root Cause

_PROVIDER_ALIASES in auxiliary_client.py (line 165) is a manually-maintained subset of the canonical _PROVIDER_ALIASES in hermes_cli/models.py (line 1179). The two dicts drifted — models.py has 76 entries, auxiliary_client.py had only 30. The 46 missing entries include common aliases like:

Alias Canonical Impact
dashscope alibaba #49464 — auxiliary.vision fails
aws / amazon bedrock Bedrock vision/compression fails
hf huggingface HF auxiliary tasks fail
nim nvidia NVIDIA NIM auxiliary tasks fail
deep-seek deepseek DeepSeek auxiliary tasks fail
mimo xiaomi Xiaomi auxiliary tasks fail
lm-studio lmstudio LM Studio auxiliary tasks fail
... ... 39 more

Fix

Sync all missing aliases from models.py into auxiliary_client.py. This is additive — existing aliases are unchanged, no behavior change for currently-working providers.

Test Plan

  • Added 8 regression tests in TestNormalizeAuxProvider covering all newly-added alias groups
  • All 10 tests in TestNormalizeAuxProvider pass
  • Verified _normalize_aux_provider("dashscope") now returns "alibaba" (was returning "dashscope")

Closes #49464

_PROVIDER_ALIASES in auxiliary_client.py was missing 46 aliases that
exist in hermes_cli/models.py (dashscope→alibaba, aws→bedrock, hf→
huggingface, nim→nvidia, deep-seek→deepseek, mimo→xiaomi, etc.).

When users configured auxiliary.vision.provider: dashscope (or any of
the other missing aliases), _normalize_aux_provider() returned the
un-normalized string, causing the vision/compression/web_extract
pipeline to silently fail with "couldn't be analyzed" because the
provider was not recognized by resolve_provider_client().

Closes NousResearch#49464
@alt-glitch alt-glitch added type/bug Something isn't working comp/agent Core agent runtime: loop, agent_init, prompt builder, context-compression, responses endpoint tool/vision Vision analysis and image generation P2 Medium — degraded but workaround exists labels Jun 21, 2026
@Slobaka

Slobaka commented Jun 28, 2026

Copy link
Copy Markdown
Contributor

Closing in favor of a rebased PR against the latest main (b31b0b9). The original branch diverged significantly. New PR coming shortly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/agent Core agent runtime: loop, agent_init, prompt builder, context-compression, responses endpoint P2 Medium — degraded but workaround exists tool/vision Vision analysis and image generation type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

auxiliary.vision with dashscope/qwen models always fails with "couldn't be analyzed" on Windows

3 participants