You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(core): resolve reasoning variants for GitLab Duo models - #51082
Variant.resolve only builds variants for packages listed in PROTOCOLS. gitlab-ai-provider wasn't listed, so every GitLab model resolved to [] and lost the reasoning_options declared in models.dev.
This adds a gitlab protocol that routes on the model's backend and emits settings in the shape gitlab-ai-provider reads from providerOptions.gitlab (the option key already resolves to gitlab in aisdk.ts):
Claude (adaptive, e.g. Opus 4.8+/5.x, Sonnet 5, Fable):thinking: { type: "adaptive", effort }, which the provider serializes to thinking: { type: "adaptive", display: "summarized" } + output_config.effort. The toggle "off" state is thinking: { type: "disabled" }. Always-thinking models (Fable) get no toggle, same as anthropicMessages.
Claude (manual, ≤ 4.5): budget variants using thinking: { type: "enabled", budgetTokens }. Unlike direct Anthropic Opus 4.5, no effort is sent, because the provider's thinking config can't combine the two.
GPT / Codex:reasoningEffort via openaiChat. The provider maps this to reasoning_effort (Chat) or reasoning.effort (Responses) itself.
duo-workflow-*: no variants (server-side agent).
Which GitLab models get variants is still controlled by models.dev reasoning_options. Models with an empty list stay empty.
How did you verify your code works?
Added spells GitLab Duo variants for gitlab-ai-provider routes to packages/core/test/variant.test.ts. The variant, GitLab plugin, models-dev, provider, and aisdk tests pass, and bun run typecheck in packages/core is clean.
Ran Variant.resolve against the live https://models.dev/api.json GitLab catalog. For example, duo-chat-opus-5-5 → low…max with {"thinking":{"type":"adaptive","effort":"max"}}, duo-chat-sonnet-5 → none,low…max, duo-chat-gpt-6-sol → none,low…max with {"reasoningEffort":"max"}, and models with reasoning_options = [] → none.
Rebased onto current v2. The only conflict was the @ai-sdk/cohere entry in PROTOCOLS, which went away when Cohere moved to the native provider (#52633). The variant logic is unchanged.
I re-checked it against the bundled models.dev snapshot on v2. Without this change, all 30 GitLab models resolve to no variants. With it, the 15 that declare reasoning_options get them. That now includes the new duo-chat-sonnet-5-5 and duo-chat-gpt-6-1-sol, which become selectable with the gitlab-ai-provider 6.19.0 bump in #53352. bun typecheck passes, and the variant, GitLab plugin and aisdk tests give 71 pass, 0 fail.
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
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.
Issue for this PR
Closes #51081
Type of change
What does this PR do?
Variant.resolveonly builds variants for packages listed inPROTOCOLS.gitlab-ai-providerwasn't listed, so every GitLab model resolved to[]and lost thereasoning_optionsdeclared in models.dev.This adds a
gitlabprotocol that routes on the model's backend and emits settings in the shapegitlab-ai-providerreads fromproviderOptions.gitlab(the option key already resolves togitlabinaisdk.ts):thinking: { type: "adaptive", effort }, which the provider serializes tothinking: { type: "adaptive", display: "summarized" }+output_config.effort. The toggle "off" state isthinking: { type: "disabled" }. Always-thinking models (Fable) get no toggle, same asanthropicMessages.thinking: { type: "enabled", budgetTokens }. Unlike direct Anthropic Opus 4.5, noeffortis sent, because the provider's thinking config can't combine the two.reasoningEffortviaopenaiChat. The provider maps this toreasoning_effort(Chat) orreasoning.effort(Responses) itself.duo-workflow-*: no variants (server-side agent).Which GitLab models get variants is still controlled by models.dev
reasoning_options. Models with an empty list stay empty.How did you verify your code works?
spells GitLab Duo variants for gitlab-ai-provider routestopackages/core/test/variant.test.ts. The variant, GitLab plugin, models-dev, provider, and aisdk tests pass, andbun run typecheckinpackages/coreis clean.Variant.resolveagainst the livehttps://models.dev/api.jsonGitLab catalog. For example,duo-chat-opus-5-5→low…maxwith{"thinking":{"type":"adaptive","effort":"max"}},duo-chat-sonnet-5→none,low…max,duo-chat-gpt-6-sol→none,low…maxwith{"reasoningEffort":"max"}, and models withreasoning_options = []→ none.Screenshots / recordings
N/A (no UI change)
Checklist