hermes - ✅(Solved) Fix [Feature]: Allow explicit api_mode selection for manual custom endpoints [1 pull requests, 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#13415Fetched 2026-04-22 08:06:35
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
Participants
Timeline (top)
cross-referenced ×1labeled ×1

Fix Action

Fixed

PR fix notes

PR #13423: feat(cli): persist explicit api_mode for manual custom endpoints

Description (problem / solution / changelog)

Summary

Manual custom endpoint setup now supports explicit api_mode selection.

Hermes already supports explicit transport routing such as codex_responses at runtime, but the manual custom endpoint flow did not expose that setting. It always relied on URL-based detection and cleared any explicit api_mode during save.

That made some OpenAI-compatible relays and gateways hard to configure through the CLI. A common example is CCH-style proxies: the base URL does not look like the official OpenAI/Codex endpoint, so Hermes falls back to chat_completions, while some relays only support codex_responses. Refer to Issue: https://github.com/NousResearch/hermes-agent/issues/13415

This change adds an explicit API mode prompt to the manual custom endpoint flow so users can choose the transport they need without depending entirely on URL heuristics.

Changes

  • Added an explicit API mode prompt to the manual custom endpoint flow in hermes_cli/main.py
  • Supported the following choices:
    • auto
    • chat_completions
    • codex_responses
    • anthropic_messages
  • Persisted explicit selections to model.api_mode
  • Persisted the same selection to the saved custom_providers entry for the endpoint
  • Kept auto behavior as “unset”, so existing URL-based detection continues to work as before
  • Cleared stale saved api_mode values when the same endpoint is reconfigured back to auto
  • Kept existing saved-provider behavior unchanged: no new editing UI was added for named saved providers
  • Added regression coverage in tests/cli/test_cli_provider_resolution.py for:
    • explicit codex_responses persistence
    • clearing stale api_mode when switching back to auto
    • updating an existing saved custom endpoint entry

Validation

Ran:

  • scripts/run_tests.sh tests/cli/test_cli_provider_resolution.py tests/hermes_cli/test_custom_provider_model_switch.py tests/hermes_cli/test_runtime_provider_resolution.py tests/hermes_cli/test_update_config_clears_custom_fields.py -q

Result:

  • 98 passed

Changed files

  • hermes_cli/main.py (modified, +101/-4)
  • tests/cli/test_cli_provider_resolution.py (modified, +186/-2)
RAW_BUFFERClick to expand / collapse

Problem or Use Case

When configuring a custom model through the manual custom endpoint flow, Hermes currently relies on URL-based transport detection or implicit defaults.

That works for endpoints whose wire protocol can be inferred from the base URL, but it breaks for OpenAI-compatible relays and gateways whose URLs do not reveal the actual transport they require.

A concrete example is Claude Code Hub (CCH)-style proxies:

  • the endpoint is not a direct Codex/OpenAI URL
  • Hermes falls back to chat_completions
  • some relays only support codex_responses

In those cases, users cannot successfully configure the endpoint through the CLI even though Hermes already supports explicit api_mode values at runtime.

It would be useful if the manual custom endpoint flow allowed users to explicitly choose and persist the API mode, for example:

  • auto
  • chat_completions
  • codex_responses
  • anthropic_messages

This would make custom relays and proxy-based setups usable without depending entirely on URL heuristics, while keeping the current auto-detection behavior available for simpler setups.

Proposed Solution

Add an explicit API mode prompt to the manual custom endpoint setup flow.

Suggested behavior:

  • Keep the current heuristic-based behavior as the default via an auto option
  • Let users explicitly choose one of:
    • auto
    • chat_completions
    • codex_responses
    • anthropic_messages
  • Persist explicit selections to the active model config so the chosen endpoint is routed correctly at runtime
  • Persist the same value to the saved custom provider entry so the setting is preserved when the endpoint is reused later
  • If the user switches back to auto, clear the persisted explicit value instead of leaving behind a stale override

This keeps the existing UX for users who do not need transport overrides, while making manual custom endpoint setup work for proxy and relay setups that cannot be handled reliably through URL detection alone.

Alternatives Considered

No response

Feature Type

CLI improvement

Scope

Medium (few files, < 300 lines)

Contribution

  • #13470

Debug Report (optional)

extent analysis

TL;DR

Add an explicit API mode prompt to the manual custom endpoint setup flow to allow users to choose and persist the API mode.

Guidance

  • Modify the manual custom endpoint setup flow to include an explicit API mode prompt with options for auto, chat_completions, codex_responses, and anthropic_messages.
  • Persist the user's explicit selection to the active model config and the saved custom provider entry.
  • If the user switches back to auto, clear the persisted explicit value to avoid stale overrides.
  • Update the routing logic to use the persisted API mode value at runtime.

Example

No code snippet is provided as the issue does not contain sufficient code details.

Notes

The proposed solution aims to improve the usability of custom relays and proxy-based setups by allowing users to explicitly choose the API mode. However, the implementation details may vary depending on the existing codebase and requirements.

Recommendation

Apply the proposed solution to add an explicit API mode prompt to the manual custom endpoint setup flow, as it provides a more flexible and reliable way to configure custom endpoints.

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 [Feature]: Allow explicit api_mode selection for manual custom endpoints [1 pull requests, 1 participants]