hermes - ✅(Solved) Fix [Bug]: auxiliary runtime does not normalize github-copilot provider slugs [1 pull requests, 1 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#15017Fetched 2026-04-25 06:25:07
View on GitHub
Comments
1
Participants
1
Timeline
8
Reactions
0
Author
Participants
Timeline (top)
labeled ×4cross-referenced ×2closed ×1commented ×1

When GitHub Copilot is selected through Hermes' normal provider-resolution path, runtime code can end up persisting the models.dev slug github-copilot. Later, agent.auxiliary_client.resolve_provider_client() treats that slug as unknown instead of normalizing it back to Hermes' runtime slug copilot.

This makes provider resolution inconsistent between the switch/persistence layer and the runtime layer.

Root Cause

When GitHub Copilot is selected through Hermes' normal provider-resolution path, runtime code can end up persisting the models.dev slug github-copilot. Later, agent.auxiliary_client.resolve_provider_client() treats that slug as unknown instead of normalizing it back to Hermes' runtime slug copilot.

This makes provider resolution inconsistent between the switch/persistence layer and the runtime layer.

Fix Action

Fixed

PR fix notes

PR #15019: fix(aux): normalize GitHub Copilot provider slugs

Description (problem / solution / changelog)

Summary

  • normalize github-copilot, github-models, and related Copilot ACP aliases inside agent.auxiliary_client
  • normalize the resolved main provider before runtime lookup so persisted github-copilot config values keep working
  • add regression coverage for direct alias normalization and provider=main when the configured provider is github-copilot

Fixes #15017.

Test plan

  • /home/csh/.hermes/hermes-agent/venv/bin/pytest -q /home/csh/.hermes/hermes-agent/tests/agent/test_auxiliary_client.py /home/csh/.hermes/hermes-agent/tests/agent/test_auxiliary_named_custom_providers.py

🤖 Generated with Claude Code

Changed files

  • agent/auxiliary_client.py (modified, +10/-3)
  • tests/agent/test_auxiliary_client.py (modified, +12/-0)
  • tests/agent/test_auxiliary_named_custom_providers.py (modified, +20/-0)

Code Example

resolve_provider_client: unknown provider 'github-copilot'
RAW_BUFFERClick to expand / collapse

Summary

When GitHub Copilot is selected through Hermes' normal provider-resolution path, runtime code can end up persisting the models.dev slug github-copilot. Later, agent.auxiliary_client.resolve_provider_client() treats that slug as unknown instead of normalizing it back to Hermes' runtime slug copilot.

This makes provider resolution inconsistent between the switch/persistence layer and the runtime layer.

Reproduction

  1. Configure Hermes to use GitHub Copilot.
  2. Switch to a Copilot model through the normal runtime flow so the selected provider is stored as github-copilot (for example, via resolve_provider_full("copilot") / switch_model(..., explicit_provider="copilot")).
  3. Later, resolve the provider through agent.auxiliary_client.resolve_provider_client("github-copilot", model="gpt-5.4").

Actual

Hermes logs:

resolve_provider_client: unknown provider 'github-copilot'

and returns (None, None).

The same happens when auxiliary routing resolves provider=main and the configured main provider is github-copilot.

Expected

github-copilot and related GitHub Copilot aliases should normalize to the runtime provider slug copilot, so resolve_provider_client("github-copilot", ...) behaves the same as resolve_provider_client("copilot", ...).

Notes

hermes_cli.providers.resolve_provider_full("copilot") can legitimately produce the models.dev canonical slug github-copilot, so the runtime layer needs to accept that canonical form.

extent analysis

TL;DR

Update the agent.auxiliary_client.resolve_provider_client() function to normalize the github-copilot slug to copilot for consistent provider resolution.

Guidance

  • Verify that the resolve_provider_client function is correctly handling the github-copilot slug by checking its implementation and any related configuration.
  • Consider adding a normalization step in the resolve_provider_client function to map github-copilot to copilot.
  • Test the resolve_provider_client function with both github-copilot and copilot as input to ensure consistent behavior.
  • Review the Hermes configuration to ensure that the copilot provider is correctly set up and referenced.

Example

def resolve_provider_client(provider_slug, model):
    # Normalize github-copilot to copilot
    if provider_slug == "github-copilot":
        provider_slug = "copilot"
    # Rest of the function implementation

Notes

This solution assumes that the github-copilot slug is the only alias that needs to be normalized to copilot. If there are other aliases, they may need to be handled similarly.

Recommendation

Apply workaround: update the resolve_provider_client function to normalize the github-copilot slug to copilot, as this will ensure consistent provider resolution without requiring any changes to the underlying configuration or dependencies.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - ✅(Solved) Fix [Bug]: auxiliary runtime does not normalize github-copilot provider slugs [1 pull requests, 1 comments, 1 participants]