Files
hermes-agent/agent
teknium1 f6f6befbcf fix(fallback): a bare llama.cpp alias resolves only to the live managed server
Completes the managed-endpoint rung for every caller that resolves a bare
llamacpp / llama.cpp / llama-cpp alias outside the main ladder:

- The rung moves from _resolve_custom_branch to the resolve_provider_client
  entry and to _get_cached_client, via agent/auxiliary_local_runtime.py.
  The `main_runtime is None` gate is gone: the cached auxiliary path always
  passes a normalized dict, so the rung never ran there, and a task pinned to
  llamacpp inherited a foreign main runtime's URL instead.
- No running server now means (None, None) — the same answer the main ladder's
  _resolve_llamacpp_runtime gives — instead of continuing into
  _try_custom_endpoint / _resolve_api_key_provider, which posted the local GGUF
  slug (and, for compression, the conversation) to whichever cloud provider held
  a key (#119227) or to the primary's own endpoint. OPENAI_BASE_URL is not
  consulted either: the alias table entry (b7e0d715be) exists for explicit
  base_url lanes, and the main ladder never reads it for a bare alias.
- The cached client keys on the live endpoint (base_url + key), read at call
  time, so a server restarted on a new port/key gets a fresh client and a
  stopped one resolves to nothing instead of a stale client.
- The endpoint is resolved with the calling profile's config (load_config() at
  call time), matching the main ladder; a configured provider entry named like
  the alias still wins.
- Vision keeps the raw provider name for its final resolve so the alias is not
  flattened to bare `custom` first.
- The aux "unavailable" message names the stopped local server instead of an
  invented LLAMACPP_API_KEY.

Co-authored-by: Gille <4317663+helix4u@users.noreply.github.com>
2026-10-02 16:44:56 -07:00
..
…