Model Provider Plugins
Model مزوّدو النماذج Plugins
Start with meaning, then move to detail.
This lesson explains Model Provider Plugins as part of Hermes internals and extension points. You will learn what it does, when it matters, and the smallest safe test that proves it works.
If you are new, do not memorize names. Focus on three questions: what problem does this solve, what access does it need, and how can you verify the result?
For practice, inspect the first example, identify its effects, run it on test data, and compare the result with the source claim.
For advanced readers, inspect How discovery works, Directory structure, Minimal example — a simple API-key provider, then verify failure modes and version compatibility.
Know Python, Git, and basic project structure before changing code.
A clear outcome before you read.
- Understand Model Provider Plugins without assumed prior knowledge.
- Separate the source description from what still needs testing in your environment.
- Read the first command and identify its inputs and outputs before copying it.
Short definitions before the details.
- Provider
- The service that runs or provides access and authentication to a model.
How to build a model provider (inference backend) plugin for Hermes Agent
What does the source say, and in what order?
- 01How discovery works
Start here to understand the core idea or structure.
- 02Directory structure
Read this after the foundation, then connect it to the previous step.
- 03Minimal example — a simple API-key provider
Read this after the foundation, then connect it to the previous step.
- 04ProviderProfile fields
Read this after the foundation, then connect it to the previous step.
- 05Overridable hooks
Read this after the foundation, then connect it to the previous step.
- 06Hook reference examples
Read this after the foundation, then connect it to the previous step.
- 07User overrides — replace a built-in without editing the repo
Read this after the foundation, then connect it to the previous step.
- 08apimode selection
Read this after the foundation, then connect it to the previous step.
- 09Auth types
Read this after the foundation, then connect it to the previous step.
- 10Discovery timing
Finish here to verify the result and special cases.
Copy only after you understand the effect.
plugins/model-providers/my-provider/
├── __init__.py # Calls register_provider(profile) at module-level
├── plugin.yaml # kind: model-provider + metadata (optional but recommended)
└── README.md # Setup instructions (optional)That's it. After dropping these two files, the following **auto-wire** with no other edits:
| Integration | Where | What it gets |
|---|---|---|
| Credential resolution | `hermes_cli/auth.py` | `PROVIDER_REGISTRY["acme-inference"]` populated from profile |
| `--provider` CLI flag | `hermes_cli/main.py` | Accepts `acme-inference` |
| `hermes model` picker | `hermes_cli/models.py` | Appears in `CANONICAL_PROVIDERS`, model list fetched from `{base_url}/models` |
| `hermes doctor` | `hermes_cli/doctor.py` | Health check for `ACME_API_KEY` + `{base_url}/models` probe |
| `hermes setup` | `hermes_c## Hook reference examples
Look at these bundled plugins for idioms:
| Plugin | Why look |
|---|---|
| `plugins/model-providers/openrouter/` | Aggregator with provider preferences, public model catalog |
| `plugins/model-providers/gemini/` | `thinking_config` translation (native + OpenAI-compat nested forms) |
| `plugins/model-providers/kimi-coding/` | `OMIT_TEMPERATURE`, `extra_body.thinking`, top-level `reasoning_effort` |
| `plugins/model-providers/qwen-oauth/` | Message normalization, `cache_control` injection, VL high-res |
| `plugins/model-providers/nous/` | Attribution tags, "omit reaRead the first command and identify its inputs and outputs before copying it.
Match every command to your installed Hermes version, review the files and accounts it can reach, and use non-sensitive data for the first test. If this explanation differs from the source, the official source wins.