← Back to PRs

#11198: fix(models): strip @profile suffix from model selection

by mcaxtr open 2026-02-07 14:47 View on GitHub →
agents size: S trusted-contributor experienced-contributor
Fixes #10882 #### Summary When using `/model provider/model@profile:name` syntax, the `@profile` suffix was included in the model name during allowlist lookup, causing a "model not allowed" error even when the model is properly configured. #### Repro Steps 1. Configure an allowlist with `nvidia/moonshotai/kimi-k2.5` 2. Send `/model nvidia/moonshotai/kimi-k2.5@nvidia:default` 3. Result: "model not allowed" error because the key becomes `nvidia/moonshotai/kimi-k2.5@nvidia:default` instead of `nvidia/moonshotai/kimi-k2.5` #### Root Cause `resolveModelRefFromString()` in `src/agents/model-selection.ts` passed the full input (including `@profile` suffix) to `parseModelRef()`. The inline directive path (`extractModelDirective()` in `src/auto-reply/model.ts`) already strips `@profile` before calling resolution, but the session reset path (`applyResetModelOverride()` → `buildSelectionFromExplicit()`) does not — it calls `resolveModelRefFromString()` with the raw token. Fixing at the `resolveModelRefFromString()` level ensures all code paths that resolve model refs correctly strip the `@profile` suffix, regardless of whether the caller pre-strips it. #### Behavior Changes - `resolveModelRefFromString()` now strips `@profile` suffix before alias lookup and `parseModelRef()` call - No change to `parseModelRef()` itself (profile stripping is an application-level concern, not a model-ref concern) - Existing callers that already strip `@profile` (inline directive path) are unaffected — double-stripping is safe #### Codebase and GitHub Search - Searched for all callers of `resolveModelRefFromString` — confirmed session reset path and directive handling path both benefit - Searched for `@` handling in model resolution — `extractModelDirective()` already strips but `resolveModelRefFromString` did not - No existing PRs or claims on #10882 #### Tests 4 new tests in `src/agents/model-selection.test.ts` — all 4 fail before fix, pass after: - [x] Strip `@profile` suffix from `provider/model` input (`nvidia/moonshotai/kimi-k2.5@nvidia:default`) - [x] Strip `@profile` suffix from single-segment model input (`gpt-5@myprofile`) - [x] Strip `@profile` suffix with colon in profile name (`google/gemini-flash-latest@google:bevfresh`) - [x] Resolve alias with `@profile` suffix (`kimi@nvidia:default`) Full test suite: 220 tests pass across 36 files. Build and lint clean. lobster-biscuit **Sign-Off** - Models used: Claude Opus 4.6 - Submitter effort: autonomous (TDD) - Agent notes: Fix applied at deepest shared layer (`resolveModelRefFromString`) to benefit all code paths. The inline directive path already handled this correctly; the session reset path did not. <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR updates `resolveModelRefFromString()` to strip a trailing `@profile` suffix from model tokens before alias lookup and `parseModelRef()` parsing, fixing allowlist key mismatches when users specify `/model provider/model@profile:name`. It also adds unit tests covering provider/model inputs, single-segment inputs, aliases, and profile names containing colons to ensure all resolution paths behave consistently. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk. - Change is narrowly scoped to stripping `@profile` suffixes before alias lookup/parsing, with added unit tests covering the affected cases. No other resolution logic is altered, and the new behavior is consistent across callers. - No files require special attention <!-- greptile_other_comments_section --> <!-- /greptile_comment -->

Most Similar PRs