Skip to content

feat(gateway): per-platform default model routing via config.platform_models#15660

Open
GeorgeXu wants to merge 2 commits into
NousResearch:mainfrom
GeorgeXu:feature/platform-model-routing
Open

feat(gateway): per-platform default model routing via config.platform_models#15660
GeorgeXu wants to merge 2 commits into
NousResearch:mainfrom
GeorgeXu:feature/platform-model-routing

Conversation

@GeorgeXu

Copy link
Copy Markdown

Summary

Allow users to configure different default models per IM platform (WeChat, DingTalk, Telegram, Discord, etc.) via config.yaml.

Problem

Currently Hermes uses a single global default model for all platforms. Users who want DingTalk conversations to use DeepSeek v4 while WeChat uses Qwen 3.6 have no way to set this — they must manually /model switch in each session. When sessions expire and are recreated, the override is lost.

Solution

Adds a platform_models section to config.yaml:

platform_models:
  weixin:
    provider: bailian
    model: qwen3.6-plus
  dingtalk:
    provider: deepseek-pro
    model: deepseek-v4-pro

The gateway reads this during session/agent creation. Platform defaults only apply when no explicit /model session override is active — the user's manual override always wins.

Implementation

  • 39 lines added to gateway/run.py in GatewayRunner._create_agent_for_session()
  • Uses existing resolve_runtime_provider() for provider resolution (supports env-var expansion and credential lookup)
  • Silent no-op when platform_models field is missing from config
  • All exceptions are caught and logged at debug level — routing failures never break the gateway

…_models

Allow config.yaml to specify default model/provider per IM platform
(e.g., weixin→qwen3.6, dingtalk→deepseek-v4-pro). Platform defaults
only apply when no /model session override is active.

Config format:
  platform_models:
    weixin:
      provider: bailian
      model: qwen3.6-plus
    dingtalk:
      provider: deepseek-pro
      model: deepseek-v4-pro

Providers are resolved via resolve_runtime_provider(), supporting
env-var expansion and credential lookup for custom providers.
@alt-glitch alt-glitch added type/feature New feature or request P3 Low — cosmetic, nice to have comp/gateway Gateway runner, session dispatch, delivery area/config Config system, migrations, profiles labels Apr 25, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

Likely duplicate of #11439 — same feature: per-platform default model/provider overrides. #11439 uses platforms..extra path, this uses config.platform_models. See also feature request #14327.

@alt-glitch

Copy link
Copy Markdown
Collaborator

Likely duplicate of #11439

@nwang783

Copy link
Copy Markdown

I checked #11439. The duplicate concern is real at the feature level even though the config surface is different (config.platform_models here vs the existing platforms.<platform>.extra approach there).

From a maintainer-triage perspective, I don't think we should merge both. We should pick one configuration shape and converge the work there. Right now #11439 has the advantage of being older and already touching the surrounding gateway/session/docs surface.

5 tests covering: correct routing, session override precedence,
missing key silent noop, missing section noop, resolution failure.
All existing 12 tests continue to pass.

docs: add per-platform default model section to FAQ
@GeorgeXu

Copy link
Copy Markdown
Author

Thanks for the review @alt-glitch and @nwang783 — appreciate the careful triage.

I read through #11439 and wanted to share some perspective from a user/product angle rather than re-litigate the technical debate.

Config surface: what does the user see?

The two proposals expose different UX:

# #11439 — platforms.<platform>.extra
platforms:
  telegram:
    extra:
      model: claude-sonnet-4
      provider: anthropic
# #15660 — platform_models (this PR)
platform_models:
  weixin:
    provider: bailian
    model: qwen3.6-plus

For a user who just wants "WeChat uses Qwen, DingTalk uses DeepSeek", platform_models is self-documenting — the name tells you exactly what it does. platforms.<platform>.extra requires documentation to explain that extra happens to support model/provider routing among potentially other things. A new user looking at a config file can guess what platform_models does; they can not guess what extra does.

This matters because Hermes has 123k stars — the majority of users configure via copy-paste and YAML editing, not by reading docs first.

Scope: 39 lines vs 268

This PR is a single injection point — it resolves the platform default once at session creation and the rest of the system is unaware. #11439 threads platform awareness through 6 functions. Smaller surface means fewer future bugs when those functions change.

What I have added

  • 5 tests covering routing, precedence, silent noop, and failure degradation (all existing 12 tests continue to pass)
  • FAQ documentation on per-platform default models

I am not precious about which config shape wins — if the maintainers prefer the platforms.extra path, I am happy to update this PR to use that convention. The important thing is that the feature lands. Just wanted to make the case for a config surface that a user can understand without reading docs.

Decision is yours. Happy to iterate either way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/config Config system, migrations, profiles comp/gateway Gateway runner, session dispatch, delivery P3 Low — cosmetic, nice to have type/feature New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants