#20080: fix: resolve model aliases correctly when keyed by short name

## Summary - *Problem:* Model alias resolution was inverted when the short name was used as a configuration key, causing aliases to resolve to `anthropic/<shortname>` instead of the intended full provider/model path. - *Why it matters:* Users couldn't use short aliases (e.g., `/model flash`) if they were defined as keys in the config, leading to 404 errors. - *What changed:* Updated `buildModelAliasIndex` logic to detect if the `alias` value contains a provider slash (`/`). If it does, the indexer now correctly treats the key as the short name and the value as the full model path. - *What did NOT change:* Standard alias definitions (Model as key, alias as value) and reverse mapping for UI/Status display remain unchanged and fully functional. ## Change Type - [x] Bug fix - [ ] Feature - [ ] Refactor - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope - [ ] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [ ] Integrations - [ ] API / contracts - [x] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes #20042 ## User-visible / Behavior Changes Users can now define and use aliases in both formats: 1. `"google/gemini-2.5-flash": { "alias": "flash" }` 2. `"flash": { "alias": "google/gemini-2.5-flash" }` Both will correctly resolve `flash` to the Google Gemini model. ## Security Impact - New permissions/capabilities? (`No`) - Secrets/tokens handling changed? (`No`) - New/changed network calls? (`No`) - Command/tool execution surface changed? (`No`) - Data access scope changed? (`No`) ## Repro + Verification ### Environment - OS: Darwin (macOS) - Runtime/container: Node v22.17.0 - Model/provider: Google (Gemini) - Relevant config: `"flash": { "alias": "google/gemini-2.5-flash" }` ### Steps 1. Configure a model alias using the short name as the key. 2. Run a command using that alias (e.g., `/model flash` or `session_status`). 3. Observe the resolution logs or status. ### Expected - Alias `flash` resolves to `google/gemini-2.5-flash`. ### Actual - Alias `flash` resolves correctly after the fix (previously resolved to `anthropic/flash`). ## Evidence - [x] Trace/log snippets: Unit tests passed for both standard and inverted alias formats. ## Human Verification - Verified scenarios: Both alias-as-key and alias-as-value configurations. - Edge cases checked: Reverse mapping (`byKey`) for UI labels is maintained correctly. - What you did *not* verify: Behavior with CLI-only providers (out of scope). ## Compatibility / Migration - Backward compatible? (`Yes`) - Config/env changes? (`No`) - Migration needed? (`No`) ## Failure Recovery - How to disable/revert this change quickly: Revert changes in `src/agents/model-selection.ts`. - Files/config to restore: `src/agents/model-selection.ts`. ## Risks and Mitigations - *Risk:* Potential edge case if an alias itself contains a slash (though unconventional). - *Mitigation:* The fix explicitly checks for valid provider parsing before applying the inverted logic. <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR fixes `buildModelAliasIndex` to support an inverted alias config format where the short name is the key and the full `provider/model` path is the alias value (e.g., `"flash": { "alias": "google/gemini-2.5-flash" }`). The fix detects if the alias value contains a `/` and, if so, treats the key as the short name and the value as the model reference. - **Allowlist functions not updated**: `buildConfiguredAllowlistKeys` and `buildAllowedModelSet` still parse config keys via `parseModelRef(key, defaultProvider)` without awareness of the inverted format. With a config like `"flash": { "alias": "google/gemini-2.5-flash" }`, the allowlist will contain `anthropic/flash` while the alias resolves to `google/gemini-2.5-flash`, causing an allowlist mismatch that will likely reject the model downstream. - **Display label inconsistency**: The `alias` property stored in the `byAlias` map entry is the full model path in the inverted case, but consumers expect it to be the short display name. This would cause redundant display messages. - **No tests added**: The new inverted-alias code path has no unit tests covering it, and the existing test suite only covers the standard format. <h3>Confidence Score: 2/5</h3> - This PR fixes alias resolution but introduces an allowlist mismatch that will likely cause the inverted alias to be rejected as "not allowed" in downstream checks. - The core alias resolution logic in buildModelAliasIndex is correct, but the change is incomplete: buildConfiguredAllowlistKeys and buildAllowedModelSet are not updated to handle the inverted format, causing the resolved model to fail allowlist validation. Additionally, the alias display label is semantically wrong for the new path, and no tests cover the new behavior. - src/agents/model-selection.ts — the allowlist functions (buildConfiguredAllowlistKeys at line 173, buildAllowedModelSet at line 365) need matching updates for the inverted alias format. _{Last reviewed commit: a3c8557} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->