fix(hermes): register cliproxy as a proper provider

[shunkakinoki]

Problem

The Hermes config had providers: {} which means no inference providers registered. The custom_providers section at the bottom of the config doesn't register providers for model routing. Every request failed with:

Primary provider auth failed: No inference provider configured.

This caused every request to fall back from deepseek-v4-flash to deepseek-v4-pro, wasting tokens.

Fix

Changed providers: {} to a proper cliproxy provider definition:

providers:
  cliproxy:
    base_url: https://cliproxy.shunkakinoki.com/v1
    api_key: __CLIPROXY_API_KEY__
    api_mode: chat_completions

After merge

Re-hydrate config and restart gateway. deepseek-v4-flash should work as the primary model.

---

Summary by cubic

Registers cliproxy as an inference provider in Hermes so the default deepseek-v4-flash model works without falling back to pro. Fixes “No inference provider configured” errors and stops token waste.

• Bug Fixes

  • Replaced providers: {} with a proper cliproxy provider (base_url, __CLIPROXY_API_KEY__, api_mode: chat_completions) in both Hermes config templates.
  • Primary model now authenticates via cliproxy; fallback to deepseek-v4-pro only if needed.

• Migration

  • Re-hydrate the Hermes config and restart the gateway.
  • Ensure __CLIPROXY_API_KEY__ is set.

^{Written for commit 94b2b51. Summary will update on new commits.}

[indent-zero]

Warning

Indent Zero is shutting down on August 7th. Please migrate over to Indent 2.0 to continue getting PR reviews.

PR Summary

Registers cliproxy as a top-level entry under providers: in both config/hermes/config.template.yaml and config/hermes/config.tpl.yaml, replacing the previously empty providers: {}. The stated goal is to fix a "No inference provider configured" startup failure and stop deepseek-v4-flash from falling back to deepseek-v4-pro.

• providers: {} → providers: { cliproxy: { base_url, api_key: __CLIPROXY_API_KEY__, api_mode: chat_completions } } in config.template.yaml
• Same change mirrored in config.tpl.yaml (with __DEEPSEEK_*__ placeholders untouched)
• Pre-existing custom_providers: list entry for cliproxy (bottom of the file) is left in place, so the endpoint is now declared in two sections

Issues

2 potential issues found:

• Commit message misdiagnoses the failure: it says providers: {} being empty caused "No inference provider configured", but Hermes' runtime resolver (_get_named_custom_provider in hermes_cli/runtime_provider.py) reads providers: then falls through to custom_providers:, and the pre-existing custom_providers: entry already registered cliproxy with the same base_url/api_key/api_mode. The real trigger is more likely a missing CLIPROXY_API_KEY (hydrate.sh silently exits on || true) or the v22→v34 config migration — worth verifying before assuming this PR fixes the underlying issue. → Autofix
• cliproxy is now defined in both providers: (this PR) and the pre-existing custom_providers: list at the bottom of the file; Hermes dedupes them today by (name, base_url, model), but any future single-copy edit (base_url, api_mode, models, headers) will silently diverge with only the providers: entry taking effect. Pick one source of truth — either drop the custom_providers: block or revert to using it alone. → Autofix

CI Checks

Waiting for CI checks...

---

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: c061ab21-de0f-4185-88e3-0dafed06d8c8

📥 Commits

Reviewing files that changed from the base of the PR and between cf54e90 and 94b2b51.

📒 Files selected for processing (2)

• config/hermes/config.template.yaml
• config/hermes/config.tpl.yaml

Disabled knowledge base sources:

• Linear integration is disabled

You can enable these sources in your CodeRabbit configuration.

---

📝 Walkthrough

Summary by CodeRabbit

• New Features
  • Added preconfigured Cliproxy provider settings, including its service URL, API key field, and chat-completions mode.
  • Updated configuration templates to support provider-based AI service setup.

Walkthrough

The Hermes configuration templates now define a cliproxy provider with its base URL, API-key placeholder, and chat_completions API mode.

Changes

CLIProxy provider configuration

Layer / File(s)	Summary
Add CLIProxy provider settings config/hermes/config.template.yaml, config/hermes/config.tpl.yaml	Both templates replace the empty providers map with the cliproxy endpoint, credential placeholder, and chat_completions API mode.

Estimated code review effort: 1 (Trivial) | ~3 minutes

Poem

I’m a rabbit with config to share,
CLIProxy settings now sit there.
URLs aligned, keys tucked away,
Chat completions guide the way.
Hop, hop—Hermes is ready today!

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/hermes-cliproxy-provider

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[indent-zero]

Duplicate cliproxy definition — the same endpoint is still declared under custom_providers: at lines 329-333 of this file (and the equivalent block in config.tpl.yaml). Upstream hermes_cli/config.get_compatible_custom_providers reads both providers: and custom_providers: and dedupes them by (name, base_url, model), so today they collapse to a single entry — but this is a latent hazard: if either copy gets an edit (base_url, api_mode swap, models list, extra_headers, context_length, enabled: false), the two definitions silently diverge and only the copy the resolver hits first (providers:) wins. Pick a single source of truth — either drop the custom_providers: block below or revert to using it alone (which was already sufficient, see the misdiagnosis note on the commit message).