Resolve the -fast suffix without a model table - #14
Merged
Merged
Conversation
Model tables populate discovery and set request defaults; they are not an allowlist, and an unlisted native ID is forwarded upstream unchanged. The synthetic -fast suffix did not follow that rule. `synthetic_fast_base` required the base to be a configured key, so `gpt-5.6-luna-fast` with no `[providers.openai.models."gpt-5.6-luna"]` table fell through as a literal model name. Codex answered `400 The 'gpt-5.6-luna-fast' model is not supported when using Codex with a ChatGPT account`, naming a model nobody asked for, while the same account ran the base model fine through the Codex CLI. Dropping the `contains_key(base)` check resolves any `gpt-`-prefixed ID: the base goes upstream and the request takes the priority tier, configured or not. The `!contains_key(native)` guard stays, so an upstream ID that itself ends in -fast is still sent verbatim once it is listed, and the suffix never stacks. Discovery still lists a -fast name only for configured IDs, since that is what model tables are for. A misspelled base now reaches the provider as the base rather than as a name with the suffix glued on, which is the same failure an unlisted ID already produces.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
openai/gpt-5.6-luna-fastfailed with:while the same account ran
gpt-5.6-lunafine through the Codex CLI.Model tables populate discovery and set request defaults; they are not an allowlist, and an unlisted native ID is forwarded upstream unchanged. The synthetic
-fastsuffix did not follow that rule:synthetic_fast_baserequired the base to be a configured key, so a-fastname whose base had no[providers.openai.models."..."]table fell through as a literal model name and Codex rejected a model nobody asked for.Change
Dropped the
contains_key(base)check. Anygpt--prefixed ID now resolves: the base goes upstream and the request takes the priority tier, configured or not.Unchanged:
!contains_key(native)still wins, so an upstream ID that itself ends in-fastis sent verbatim once listed.gpt-5.4-fast-faststays literal).gpt-IDs are untouched.-fastname only for configured IDs, since that is what model tables are for.A misspelled base now reaches the provider as the base rather than as a name with the suffix glued on — the same failure an unlisted ID already produces.
Tests
fast_suffix_resolves_gpt_modelsasserts an unconfigured base resolves; the effort/tier integration test routesgpt-9-fasttogpt-9atpriority. README andtinyllm.example.tomlupdated.cargo test108 pass, clippy and fmt clean.