fix(auxiliary): resolve named custom providers and 'main' alias in auxiliary routing by teknium1 · Pull Request #5978 · NousResearch/hermes-agent

teknium1 · 2026-04-08T00:49:00Z

Summary

Fixes auxiliary task routing (vision, compression, web_extract, session_search, etc.) for users on named custom providers.

Bug: Setting auxiliary.vision.provider: main or auxiliary.vision.provider: beans (a named custom provider from custom_providers in config.yaml) fails with:

RuntimeError: No LLM provider configured for task=vision provider=main. Run: hermes setup

Root cause — two bugs in auxiliary_client.py:

main alias hardcoded to "custom" — only checks legacy OPENAI_BASE_URL env vars, missing the user's actual provider config entirely
Named custom providers unrecognized — resolution chain jumps to PROVIDER_REGISTRY.get("beans") → None → "unknown provider", never consulting custom_providers from config.yaml

Fix — 3 targeted changes (+34 lines):

Location	Change
`resolve_provider_client()` main alias	Read `_read_main_provider()` → resolve to actual provider name
`resolve_provider_client()` before PROVIDER_REGISTRY	Try `_get_named_custom_provider()` for config.yaml entries
`_normalize_vision_provider()` main alias	Same main → actual provider resolution for vision path

Test results

13 new unit tests covering both bugs + edge cases
96 existing auxiliary client tests: all pass
E2E verification with isolated HERMES_HOME confirms both provider: main and provider: beans resolve correctly

Related PRs

Support custom_providers in auxiliary_client resolution #4484 (closed, not merged) — directly addressed named custom providers
fix(setup+auxiliary): custom endpoint loses config after setup, and auxiliary ignores active provider #3442 (open) — partial fix for custom endpoint resolution
fix(vision): apply non-aggregator provider fix to vision routing (follow-up to #5091) #5376 (open) — vision auto-routing for non-aggregator providers

This fix is more comprehensive and handles both bugs in a single change.

Reported by Laura via Discord.

…e match Captions in photo bursts and media group albums were silently dropped when a shorter caption happened to be a substring of an existing one (e.g. "Meeting" lost inside "Meeting agenda"). Extract a shared _merge_caption static helper that splits on "\n\n" and uses exact match with whitespace normalisation, then use it in both _enqueue_photo_event and _queue_media_group_event. Adds 13 unit tests covering the fixed bug scenarios. Cherry-picked from PR #2671 by Dilee.

Move _merge_caption helper from TelegramAdapter to BasePlatformAdapter so all adapters inherit it. Fix the same substring-containment bug in: - gateway/platforms/base.py (photo burst merging) - gateway/run.py (priority photo follow-up merging) - gateway/platforms/feishu.py (media batch merging) The original fix only covered telegram.py. The same bug existed in base.py and run.py (pure substring check) and feishu.py (list membership without whitespace normalization).

…xiliary routing Two bugs caused auxiliary tasks (vision, compression, etc.) to fail when using named custom providers defined in config.yaml: 1. 'provider: main' was hardcoded to 'custom', which only checks legacy OPENAI_BASE_URL env vars. Now reads _read_main_provider() to resolve to the actual provider (e.g., 'custom:beans', 'openrouter', 'deepseek'). 2. Named custom provider names (e.g., 'beans') fell through to PROVIDER_REGISTRY which doesn't know about config.yaml entries. Now checks _get_named_custom_provider() before the registry fallback. Fixes both resolve_provider_client() and _normalize_vision_provider() so the fix covers all auxiliary tasks (vision, compression, web_extract, session_search, etc.). Adds 13 unit tests. Reported by Laura via Discord.

Users on non-aggregator providers (DeepSeek, Alibaba, ZAI, Gemini, etc.) had vision silently fail because resolve_vision_provider_client()'s auto path only iterates _VISION_AUTO_PROVIDER_ORDER (openrouter, nous, codex, anthropic, custom). Their main provider was never tried. Mirror the same non-aggregator main-provider-first check that _resolve_auto() already has for non-vision tasks. Combined with the named custom provider fix in #5978, this also covers users whose main provider is a named custom endpoint. Cherry-picked from PR #5376 by Mibay. Closes #5366.

…llback Users on non-aggregator providers (DeepSeek, Alibaba, ZAI, Gemini, etc.) had vision silently fail because resolve_vision_provider_client()'s auto path only iterates _VISION_AUTO_PROVIDER_ORDER (openrouter, nous, codex, anthropic, custom). Their main provider was never tried. Mirror the same non-aggregator main-provider-first check that _resolve_auto() already has for non-vision tasks. Combined with the named custom provider fix in #5978, this also covers users whose main provider is a named custom endpoint. Add vision-specific API fallback in call_llm: if the auto-resolved main provider returns 400/422 (model doesn't support vision), fall back through the strict vision backends which use known vision-capable models. This handles the case where the user's main model is text-only. Cherry-picked from PR #5376 by Mibay. Closes #5366.

…tive provider Simplify the vision auto-detection chain from 5 backends (openrouter, nous, codex, anthropic, custom) down to 3: 1. OpenRouter (known vision-capable default model) 2. Nous Portal (known vision-capable default model) 3. Active provider + model (whatever the user is running) 4. Stop This is simpler and more predictable. The active provider step uses resolve_provider_client() which handles all provider types including named custom providers (from #5978). Removed the complex preferred-provider promotion logic and API-level fallback — the chain is short enough that it doesn't need them. Based on PR #5376 by Mibay. Closes #5366.

…xiliary routing (NousResearch#5978) * fix(telegram): replace substring caption check with exact line-by-line match Captions in photo bursts and media group albums were silently dropped when a shorter caption happened to be a substring of an existing one (e.g. "Meeting" lost inside "Meeting agenda"). Extract a shared _merge_caption static helper that splits on "\n\n" and uses exact match with whitespace normalisation, then use it in both _enqueue_photo_event and _queue_media_group_event. Adds 13 unit tests covering the fixed bug scenarios. Cherry-picked from PR NousResearch#2671 by Dilee. * fix: extend caption substring fix to all platforms Move _merge_caption helper from TelegramAdapter to BasePlatformAdapter so all adapters inherit it. Fix the same substring-containment bug in: - gateway/platforms/base.py (photo burst merging) - gateway/run.py (priority photo follow-up merging) - gateway/platforms/feishu.py (media batch merging) The original fix only covered telegram.py. The same bug existed in base.py and run.py (pure substring check) and feishu.py (list membership without whitespace normalization). * fix(auxiliary): resolve named custom providers and 'main' alias in auxiliary routing Two bugs caused auxiliary tasks (vision, compression, etc.) to fail when using named custom providers defined in config.yaml: 1. 'provider: main' was hardcoded to 'custom', which only checks legacy OPENAI_BASE_URL env vars. Now reads _read_main_provider() to resolve to the actual provider (e.g., 'custom:beans', 'openrouter', 'deepseek'). 2. Named custom provider names (e.g., 'beans') fell through to PROVIDER_REGISTRY which doesn't know about config.yaml entries. Now checks _get_named_custom_provider() before the registry fallback. Fixes both resolve_provider_client() and _normalize_vision_provider() so the fix covers all auxiliary tasks (vision, compression, web_extract, session_search, etc.). Adds 13 unit tests. Reported by Laura via Discord. --------- Co-authored-by: Dilee <uzmpsk.dilekakbas@gmail.com>

…tive provider Simplify the vision auto-detection chain from 5 backends (openrouter, nous, codex, anthropic, custom) down to 3: 1. OpenRouter (known vision-capable default model) 2. Nous Portal (known vision-capable default model) 3. Active provider + model (whatever the user is running) 4. Stop This is simpler and more predictable. The active provider step uses resolve_provider_client() which handles all provider types including named custom providers (from NousResearch#5978). Removed the complex preferred-provider promotion logic and API-level fallback — the chain is short enough that it doesn't need them. Based on PR NousResearch#5376 by Mibay. Closes NousResearch#5366.