Alexander Prendota
1bd0b8ed41
An external-process provider is an agent CLI Hermes drives over stdio rather than an HTTP endpoint. Three things about it were spelled out for one vendor, and each was a hard stop for any other: * ``resolve_provider()`` gates on ``PROVIDER_REGISTRY``. Its auto-extend from ``providers/`` covered api-key providers only, so an external-process profile never entered it and ``hermes -m <that provider>`` died with "Unknown provider" before a client was ever built. * ``resolve_runtime_provider()`` keyed the external-process branch on the literal ``"copilot-acp"``, so anything else silently fell through to the OpenRouter default instead of its own runtime. * ``resolve_external_process_provider_credentials()`` hardcoded the binary (``copilot``), the argv (``--acp --stdio``), the env var names and the placeholder api_key — so a third-party provider would have been handed another vendor's CLI. Now the profile carries what only the provider knows — ``process_command``, ``process_args``, ``process_command_env_vars``, ``process_args_env_var`` — and the three core paths key on ``auth_type == "external_process"`` instead of a name. copilot-acp's values move into its profile verbatim, so ``HERMES_COPILOT_ACP_COMMAND`` / ``COPILOT_CLI_PATH`` / ``HERMES_COPILOT_ACP_ARGS`` and its ``copilot-acp`` api_key placeholder behave exactly as before; the new tests assert that alongside the out-of-tree case at every step. The error for a missing binary now names the provider and its own env override instead of telling every user to install GitHub Copilot CLI. Co-Authored-By: Junie <junie@jetbrains.com>
Model Provider Plugins
Each subdirectory is a self-contained provider profile plugin. The
directory layout mirrors plugins/platforms/:
plugins/model-providers/
├── openrouter/
│ ├── __init__.py # registers the ProviderProfile
│ └── plugin.yaml # manifest: name, kind, version, description
├── anthropic/
│ ├── __init__.py
│ └── plugin.yaml
└── ...
How discovery works
providers/__init__.py._discover_providers() scans this directory (and
$HERMES_HOME/plugins/model-providers/) the first time anything calls
get_provider_profile() or list_providers(). Each __init__.py is
imported and expected to call providers.register_provider(profile).
User plugins at $HERMES_HOME/plugins/model-providers/<name>/ override
bundled plugins of the same name — last-writer-wins in
register_provider(). Drop a file there to replace a built-in.
Adding a new provider
-
Create
plugins/model-providers/<your_provider>/__init__.py:from providers import register_provider from providers.base import ProviderProfile my_provider = ProviderProfile( name="your-provider", aliases=("alias1", "alias2"), display_name="Your Provider", description="One-line description shown in the setup picker", signup_url="https://your-provider.example.com/keys", env_vars=("YOUR_PROVIDER_API_KEY", "YOUR_PROVIDER_BASE_URL"), base_url="https://api.your-provider.example.com/v1", default_aux_model="your-cheap-model", ) register_provider(my_provider) -
Create
plugins/model-providers/<your_provider>/plugin.yaml:name: your-provider-profile kind: model-provider version: 1.0.0 description: Short sentence about the provider author: Your Name
Nothing else needs to change. auth.py, config.py, models.py,
doctor.py, model_metadata.py, runtime_provider.py, and the
chat_completions transport all auto-wire from the registry.
Non-trivial profiles
Override the ProviderProfile hooks in a subclass for per-provider
quirks — see plugins/model-providers/openrouter/__init__.py for
build_extra_body and build_api_kwargs_extras examples, and
plugins/model-providers/gemini/__init__.py for thinking_config
translation.