[BUG] All custom model configurations vanished after v0.13.0 update #25272

Yet again, we find ourselves with another broken Herms. After one of your updates, it's completely wiped out our model list, which was very specific, which is now completely broken. Everything that we do is broken, so this would be another day of fixing your software because somebody has approved a release which doesn't work. It hasn't been tested, and you are releasing dangerous code. It's like amateur hour and worse than Openclaw.

Linking to the Hermes Masterclass Roadmap umbrella — this issue covers the environment hygiene / duplicate installs theme.

• Umbrella issue: Roadmap: operationalize Hermes masterclass checklist #33418
• Roadmap doc: docs/plans/2026-05-27-hermes-masterclass-roadmap.md

See the checklist in #33418 for full scope and cross-references.

Thanks for flagging this — losing a configured model setup during an update is exactly the kind of thing that shouldn't happen, and I'd rather fix the actual cause than guess at it.

First, a possible recovery path: Hermes writes a snapshot of your home directory before applying an update. Check ~/.hermes/backups/ (or $HERMES_HOME/backups/ if you use a custom home) for a pre-update-*.zip dated around your v0.13.0 update — the config.yaml inside it should still contain your original model setup and can be restored.

To pin down the root cause and ship a targeted fix, could you share a few details (redact any API keys/tokens)?

1. Is the data gone from disk, or just not shown? Open ~/.hermes/config.yaml and check whether your custom models still appear under the providers: (or custom_providers:) section. Pasting that section (keys redacted) tells us whether the file was actually rewritten or whether the loader simply isn't surfacing your entries.
2. How were the models configured — hand-edited providers: entries, the hermes setup wizard, or imported via hermes claw migrate from a previous setup?
3. What does "only 2 models remain" refer to — the model picker / hermes models list, or the providers menu?
4. Versions and update path: the version you upgraded from and to (hermes --version), and how you updated (pip, uv tool, Docker image, or install.sh).
5. Environment: your OS and Python version.

The most useful single artifact is a comparison of your current on-disk config.yaml against the copy inside the pre-update backup — with both we can reproduce the exact loss path and write a migration that preserves (or recovers) your model setup.

Fixed on main in PR #40573 (commit 887295b), salvaged from @rodboev's PR #40410 with authorship preserved.

Root cause: The v11→v12 config migration converted legacy custom_providers entries into the new providers: dict but only carried over name / api_key / default_model / transport — it silently dropped the entire models: map. A provider configured with N custom models came out with none, which is the "only 2 models remain / custom models gone" symptom.

Fix: A new _custom_provider_entry_to_provider_config() helper now copies models, context_length, rate_limit_delay, discover_models, and extra_body through the migration, adds an api base_url fallback, and uses a collision-safe key suffix loop. Regression tests added in tests/hermes_cli/test_config.py and tests/tools/test_docker_config_migrate.py.

Verified: Ran a real v11 config with a 4-model custom provider through migrate_config() — all 4 models, the API key, default model, and per-model metadata survive intact.

If you already lost data before upgrading to the fixed build, Hermes writes a pre-update snapshot — check ~/.hermes/backups/pre-update-*.zip (or $HERMES_HOME/backups/) for the config.yaml with your original model setup.

Closing as resolved. Thanks @rodboev for the fix.