hermes - 💡(How to fix) Fix Doc rot in agent/auxiliary_client.py — module docstring lists Native Anthropic in the auxiliary auto-detect chain, but the actual chain omits it [2 pull requests]

Summary

The module-level docstring in agent/auxiliary_client.py (lines 7–23) advertises a text-task auto-detect chain that includes Native Anthropic as step 5, but the actual chain returned by _get_provider_chain() (line 2110) does not include Anthropic. This makes the operator-facing warning at line 2976 misleading and led me to expect Anthropic fallback coverage for auxiliary tasks that I don't actually have.

Repro

Hermes 0.14.0 (commit 4d58e48cd), default config, primary provider openai-codex, primary fallback chain [anthropic / claude-opus-4-7] (auth via Claude Code OAuth). No OPENROUTER_API_KEY, no Nous login, model.base_url empty, no direct API-key providers configured.

When Codex returns HTTP 401 and is removed from the pool, auxiliary tasks (title_generation, compression, memory flush) emit:

Auxiliary auto-detect: no provider available (tried: openrouter, nous, local/custom, api-key). Compression, summarization, and memory flush will not work.

Note: the warning lists exactly the four labels returned by _get_provider_chain(). Native Anthropic is never attempted, even though resolve_anthropic_token() would succeed via the user's Claude Code credentials (~/.claude/.credentials.json).

Doc vs. code

agent/auxiliary_client.py:7-15 (docstring):

Resolution order for text tasks (auto mode):
  1. User's main provider + main model …
  2. OpenRouter  (OPENROUTER_API_KEY)
  3. Nous Portal (~/.hermes/auth.json active provider)
  4. Custom endpoint (config.yaml model.base_url + OPENAI_API_KEY)
  5. Native Anthropic
  6. Direct API-key providers (z.ai/GLM, Kimi/Moonshot, MiniMax, MiniMax-CN)
  7. None

agent/auxiliary_client.py:2110-2128 (actual chain — Step-2 only; Step-1 is the main provider handled separately above the loop):

def _get_provider_chain() -> List[tuple]:
    return [
        ("openrouter", _try_openrouter),
        ("nous", _try_nous),
        ("local/custom", _try_custom_endpoint),
        ("api-key", _resolve_api_key_provider),
    ]

There is no _try_anthropic call site between _try_custom_endpoint and _resolve_api_key_provider. The vision chain in the same docstring (lines 17–23) also lists "Native Anthropic" at step 4 — same audit needed there.

Fix options

Two reasonable directions, depending on intent:

(a) Update the docstring to match the code — drop steps 5 (text) and 4 (vision) referencing Native Anthropic; renumber. Cheap, accurate.

(b) Add Native Anthropic to _get_provider_chain() as the documented step between local/custom and api-key, using resolve_anthropic_token() from agent/anthropic_adapter.py:1089. This is the more user-friendly outcome: operators who already have working Claude Code OAuth would get free auxiliary coverage with no additional setup, which matches what the docstring promises and what the fallback_providers: [anthropic] config already does for the primary chain.

Happy to send a PR for either direction — please advise which is preferred.

Impact

Low/medium. Auxiliary failures only break optional features (title generation, compression, session search, memory flush). But the misleading docstring caused me to skip configuring an OpenRouter/Nous backstop, on the assumption that my existing Anthropic auth would cover both chains. Reading the runtime warning ("tried: …") and the docstring side-by-side is what surfaced the discrepancy.