← Back to PRs

#16104: fix: implement model aliases for /model command

by MisterGuy420 open 2026-02-14 08:34 View on GitHub →
stale size: S trusted-contributor
## Summary Adds support for a top-level `aliases` config key as a convenience alternative to `agents.defaults.models.*.alias`. This allows users to define model shortcuts in a more intuitive format. ## Changes - Added `aliases` property to `OpenClawConfig` type - Added legacy migration to convert top-level `aliases` to `agents.defaults.models.*.alias` - Added legacy rule for deprecation warning - Added unit tests for the new migration ## Testing - All 382 existing tests pass - Added 5 new tests specifically for the aliases migration - Build completes successfully ## Example Usage Users can now define aliases like: ```json { "aliases": { "fast": "ollama/minimax-m2.5:cloud", "deep": "ollama/kimi-k2.5:cloud" } } ``` Then use `/model fast` instead of `/model ollama/minimax-m2.5:cloud`. The aliases are automatically migrated to the internal format on load, so the existing implementation continues to work. Fixes openclaw/openclaw#16074 <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR adds a top-level `aliases` config key as a shorthand for defining model aliases, which are then auto-migrated to the canonical `agents.defaults.models.*.alias` format on config load. The implementation includes a new legacy migration, a deprecation rule, a type definition update, and thorough tests. - The migration correctly handles existing aliases (no overwrite), invalid values (non-string/empty), and preserves surrounding config. - One edge case: the migration reports a change and deletes `raw.aliases` even when **all** entries are invalid, causing an unnecessary config rewrite. A `migrated` flag would fix this. - Test coverage is solid with 5 new cases covering the happy path, conflict preservation, empty input, invalid values, and config preservation. <h3>Confidence Score: 4/5</h3> - This PR is safe to merge with low risk; the flagged edge case only causes a spurious no-op config rewrite, not data loss. - The migration logic is straightforward and follows established patterns in the codebase. The one issue found (reporting a change when all entries are invalid) is a minor correctness bug that won't cause data loss — it just triggers an unnecessary config file rewrite. Tests are thorough but miss this specific edge case. - `src/config/legacy.migrations.part-2.ts` — the aliases migration has an edge case where all-invalid entries still trigger a config rewrite. <sub>Last reviewed commit: 7e590eb</sub> <!-- greptile_other_comments_section --> <!-- /greptile_comment -->

Most Similar PRs