fix(vscode): infer custom provider reasoning efforts - #12941
Conversation
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Incremental review of commit Files Reviewed (26 files, incremental)
Previous Review Summaries (4 snapshots, latest commit d70ebd3)Current summary above is authoritative. Previous snapshots are kept for context only. Previous review (commit d70ebd3)Status: No Issues Found | Recommendation: Merge Incremental review of commit Files Reviewed (4 files, incremental)
Previous review (commit 2dc24c1)Status: No Issues Found | Recommendation: Merge Incremental review of commit Files Reviewed (2 files, incremental)
Previous review (commit 71a1c6b)Status: 1 Issue Found | Recommendation: Address before merge Overview
Issue Details (click to expand)SUGGESTION
Incremental review of commit Fix these issues in Kilo Cloud Files Reviewed (1 file, incremental)
Previous review (commit bddce1a)Status: 1 Issue Found | Recommendation: Address before merge Overview
Issue Details (click to expand)SUGGESTION
The core change is solid: fallback effort generation lives in the kilocode mirror directory with proper Fix these issues in Kilo Cloud Files Reviewed (33 files)
Reviewed by kimi-k3 · Input: 60.3K · Output: 9.9K · Cached: 918K Review guidance: REVIEW.md from base branch |
fix(vscode): infer custom provider reasoning efforts
What changed
none,low,medium,high,xhigh, andmaxwhen an explicitly configured AI SDK package has no detected reasoning variants.Why
Custom-provider reasoning controls should come from model heuristics rather than requiring users to encode provider-specific option shapes. The broad fallback keeps unknown reasoning models usable while preserving successful heuristics and explicit config overrides. Saved providers link to the config file for advanced options that are intentionally not exposed in the dialog.
How a custom model gets its variant set
The runtime first assembles the custom model from its config plus any matching provider/model metadata already in the catalog. Configured values take precedence over matching catalog values. In particular:
provider.npm, provider-levelnpm, matching catalog model package, models.dev provider package, then@ai-sdk/openai-compatible.false.The final variant set then follows this precedence:
model.variantscontains any entries{ disabled: true }are removed; other objects are preserved. An all-disabled configured set therefore produces no runtime variants.@ai-sdk/openai-compatible,@ai-sdk/openai, or@ai-sdk/anthropicnone,low,medium,high,xhigh, andmax, encoded for that package. OpenAI Responses also receives summary/encrypted-content options; Anthropic uses disabled thinking fornoneand nativeeffortotherwise.npm.Generated variants are never merged into a non-empty configured set. The final normalization only removes null/disabled entries and strips the top-level
disabledmarker from retained variant objects.Existing configured providers
kilo.json/kilo.jsoncand continue to work.@ai-sdk/openai-compatible,@ai-sdk/openai, or@ai-sdk/anthropicpackage enables heuristic inference and the broad fallback when no heuristic matches.npmretain their previous runtime variant behavior. Saving them in the current dialog writes the default@ai-sdk/openai-compatiblepackage, after which automatic generation applies only when the model has no configured variants.variants["fast"].