Skip to content

fix(vscode): infer custom provider reasoning efforts - #12941

Merged
chrarnoldus merged 11 commits into
mainfrom
pentagonal-storm
Aug 10, 2026
Merged

fix(vscode): infer custom provider reasoning efforts#12941
chrarnoldus merged 11 commits into
mainfrom
pentagonal-storm

Conversation

@chrarnoldus

@chrarnoldus chrarnoldus commented Aug 6, 2026

Copy link
Copy Markdown
Collaborator

What changed

  • Remove manual variant configuration controls from the VS Code custom-provider setup screen.
  • Preserve existing hand-written variant objects when editing a provider.
  • Add a localized link from saved custom providers to the global JSON/JSONC config for advanced editing.
  • Expose none, low, medium, high, xhigh, and max when 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:

  • The AI SDK package resolves in this order: model-level provider.npm, provider-level npm, matching catalog model package, models.dev provider package, then @ai-sdk/openai-compatible.
  • The reasoning capability resolves from the configured model, then matching catalog model metadata, then defaults to false.
  • Existing catalog variants are not copied into the custom model. Variant resolution runs again against the assembled model so the selected package and custom model/API IDs determine the option shape.

The final variant set then follows this precedence:

Priority Condition Result
1. Config model.variants contains any entries Use the configured set as authoritative and skip all inference. Entries with top-level { disabled: true } are removed; other objects are preserved. An all-disabled configured set therefore produces no runtime variants.
2. Capability gate No configured variants and the assembled model is not marked as reasoning-capable Produce no variants.
3. Heuristics No configured variants and the model is reasoning-capable Infer variants from the assembled model ID, API ID, AI SDK package, release metadata, and provider-specific rules. A non-empty heuristic result wins as the complete set.
4. Broad fallback Heuristics return nothing and the model or provider explicitly configures @ai-sdk/openai-compatible, @ai-sdk/openai, or @ai-sdk/anthropic Expose none, low, medium, high, xhigh, and max, encoded for that package. OpenAI Responses also receives summary/encrypted-content options; Anthropic uses disabled thinking for none and native effort otherwise.
5. No supported explicit package Heuristics return nothing and the package is absent, inherited/defaulted, or unsupported Produce no variants. This preserves the previous behavior of older custom-provider configs without an explicit 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 disabled marker from retained variant objects.

Existing configured providers

  • Upgrading does not rewrite or delete existing provider configuration. Variants created with the old UI remain in kilo.json/kilo.jsonc and continue to work.
  • Opening and saving a provider preserves each existing variant object verbatim, including provider-specific and otherwise unknown fields. Variants can no longer be added, edited, or removed in the dialog; those changes can be made through the advanced JSON config link.
  • Existing configured variants are authoritative. When a model has any configured variants, no heuristic or fallback variants are added. Disabled configured variants continue to be omitted at runtime.
  • For reasoning models without configured variants, an explicit @ai-sdk/openai-compatible, @ai-sdk/openai, or @ai-sdk/anthropic package enables heuristic inference and the broad fallback when no heuristic matches.
  • Older provider configs without an explicit npm retain their previous runtime variant behavior. Saving them in the current dialog writes the default @ai-sdk/openai-compatible package, after which automatic generation applies only when the model has no configured variants.
  • As before, turning off Reasoning and saving removes that model variant configuration. Invalid hand-written variant names block saving and are reported using the exact config entry, such as variants["fast"].

@chrarnoldus chrarnoldus self-assigned this Aug 6, 2026
@kilo-code-bot

kilo-code-bot Bot commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Incremental review of commit ed63f985d9 ("feat(vscode): link custom providers to config"). The duplicated openConfigFile message construction was extracted into a shared configMessage utility (verified 1:1 label parity with OpenConfigFileRequest), and the edit-mode provider dialog now links to the global JSON config — the correct scope, since saveCustomProvider always writes via global.config.update. All 21 webview locales gained the provider.custom.edit.advanced key with none missed. The new unit test exercises the real implementation without mocks, and the changeset is user-facing. No memory-leak concerns: no timers, subscriptions, or listeners added, and labels resolve at click time so a locale switch cannot leave stale strings. The two previous suggestions on CustomProviderModelCard.tsx were both marked fixed by the author and that file is unchanged in this increment, so nothing carries forward.

Files Reviewed (26 files, incremental)
  • .changeset/broad-custom-provider-efforts.md
  • packages/kilo-vscode/tests/unit/open-config-message.test.ts
  • packages/kilo-vscode/webview-ui/src/components/settings/CustomProviderDialog.tsx
  • packages/kilo-vscode/webview-ui/src/components/settings/Settings.tsx
  • packages/kilo-vscode/webview-ui/src/utils/open-config.ts
  • packages/kilo-vscode/webview-ui/src/i18n/ locale files (21): ar.ts, br.ts, bs.ts, da.ts, de.ts, en.ts, es.ts, fa.ts, fr.ts, it.ts, ja.ts, ko.ts, nl.ts, no.ts, pl.ts, ru.ts, th.ts, tr.ts, uk.ts, zh.ts, zht.ts
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 d70ebd3191 ("fix(cli): prefer configured custom variants"). Configured variants are now authoritative: the shared provider.ts call site skips heuristic/fallback generation whenever raw config variants exist (correctly covering the all-disabled edge case), and customProviderVariants early-returns non-empty model variants before any inference. The change to call generate(model) instead of generate({ ...model, variants: {} }) is behavior-preserving because generation is now only reachable when variants are already empty. The shared-file edit stays inside the existing kilocode_change markers, and the new logic lives in the kilocode mirror file. Tests exercise the real implementation: the unit test proves inference is skipped via a throwing generate callback, and the integration test runs the full Provider layer against a mixed disabled/enabled config. No memory-leak concerns (pure function; no timers, subscriptions, or listeners added).

Files Reviewed (4 files, incremental)
  • packages/opencode/src/kilocode/provider/provider.ts
  • packages/opencode/src/provider/provider.ts
  • packages/opencode/test/kilocode/custom-provider-variants.test.ts
  • packages/opencode/test/kilocode/provider-reasoning-options.test.ts

Previous review (commit 2dc24c1)

Status: No Issues Found | Recommendation: Merge

Incremental review of commit 2dc24c1cfd. The previous findings are resolved: variant validation errors now identify the exact immutable config entry (e.g. variants["fast"]: Duplicate value) and render as an accessible inline alert on the affected model card. The config-sourced name is embedded via JSON.stringify and rendered through SolidJS text interpolation, so there is no injection vector. No memory-leak concerns in the new code (no timers, subscriptions, or listeners added). Test assertions cover empty, whitespace-only, and duplicate variant names against the real implementation.

Files Reviewed (2 files, incremental)
  • packages/kilo-vscode/webview-ui/src/components/settings/CustomProviderValidation.ts
  • packages/kilo-vscode/tests/unit/custom-provider-dialog-validate.test.ts

Previous review (commit 71a1c6b)

Status: 1 Issue Found | Recommendation: Address before merge

Overview

Severity Count
CRITICAL 0
WARNING 0
SUGGESTION 1
Issue Details (click to expand)

SUGGESTION

File Line Issue
packages/kilo-vscode/webview-ui/src/components/settings/CustomProviderModelCard.tsx 138 Variant validation alert shows a bare "Required"/"Duplicate" with no indication of which variant failed, and variant names are no longer visible or editable in the UI

Incremental review of commit 71a1c6bc3d. The previous finding is resolved: variant-name validation errors now surface as an accessible inline alert on the affected model card, and the validation-to-save chain (checkModel -> validateCustomProvider -> setErrors(reconcile(...)) -> ModelCard) is correctly wired end to end. No memory-leak vectors in the new code (no timers, subscriptions, or listeners added).

Fix these issues in Kilo Cloud

Files Reviewed (1 file, incremental)
  • packages/kilo-vscode/webview-ui/src/components/settings/CustomProviderModelCard.tsx - 1 issue

Previous review (commit bddce1a)

Status: 1 Issue Found | Recommendation: Address before merge

Overview

Severity Count
CRITICAL 0
WARNING 0
SUGGESTION 1
Issue Details (click to expand)

SUGGESTION

File Line Issue
packages/kilo-vscode/webview-ui/src/components/settings/CustomProviderModelCard.tsx 43 Variant-name validation errors (empty/duplicate names from hand-written configs) no longer surface anywhere, so Save silently no-ops with no user feedback

The core change is solid: fallback effort generation lives in the kilocode mirror directory with proper kilocode_change markers at the shared-file injection point, heuristic variants and explicit config overrides are preserved, opaque variant round-tripping is covered by tests at the validation, sanitize, and save boundaries, and the i18n cleanup leaves no dangling key references. No memory-leak vectors introduced (no new timers, subscriptions, or listeners).

Fix these issues in Kilo Cloud

Files Reviewed (33 files)
  • .changeset/broad-custom-provider-efforts.md
  • packages/kilo-vscode/src/shared/custom-provider.ts
  • packages/kilo-vscode/tests/unit/custom-provider-dialog-validate.test.ts
  • packages/kilo-vscode/tests/unit/custom-provider.test.ts
  • packages/kilo-vscode/tests/unit/provider-actions-save.test.ts
  • packages/kilo-vscode/webview-ui/src/components/settings/CustomProviderDialog.tsx
  • packages/kilo-vscode/webview-ui/src/components/settings/CustomProviderModelCard.tsx - 1 issue
  • packages/kilo-vscode/webview-ui/src/components/settings/CustomProviderValidation.ts
  • packages/kilo-vscode/webview-ui/src/i18n/ar.ts
  • packages/kilo-vscode/webview-ui/src/i18n/br.ts
  • packages/kilo-vscode/webview-ui/src/i18n/bs.ts
  • packages/kilo-vscode/webview-ui/src/i18n/da.ts
  • packages/kilo-vscode/webview-ui/src/i18n/de.ts
  • packages/kilo-vscode/webview-ui/src/i18n/en.ts
  • packages/kilo-vscode/webview-ui/src/i18n/es.ts
  • packages/kilo-vscode/webview-ui/src/i18n/fa.ts
  • packages/kilo-vscode/webview-ui/src/i18n/fr.ts
  • packages/kilo-vscode/webview-ui/src/i18n/it.ts
  • packages/kilo-vscode/webview-ui/src/i18n/ja.ts
  • packages/kilo-vscode/webview-ui/src/i18n/ko.ts
  • packages/kilo-vscode/webview-ui/src/i18n/nl.ts
  • packages/kilo-vscode/webview-ui/src/i18n/no.ts
  • packages/kilo-vscode/webview-ui/src/i18n/pl.ts
  • packages/kilo-vscode/webview-ui/src/i18n/ru.ts
  • packages/kilo-vscode/webview-ui/src/i18n/th.ts
  • packages/kilo-vscode/webview-ui/src/i18n/tr.ts
  • packages/kilo-vscode/webview-ui/src/i18n/uk.ts
  • packages/kilo-vscode/webview-ui/src/i18n/zh.ts
  • packages/kilo-vscode/webview-ui/src/i18n/zht.ts
  • packages/opencode/src/kilocode/provider/provider.ts
  • packages/opencode/src/provider/provider.ts
  • packages/opencode/test/kilocode/custom-provider-variants.test.ts
  • packages/opencode/test/kilocode/provider-reasoning-options.test.ts

Reviewed by kimi-k3 · Input: 60.3K · Output: 9.9K · Cached: 918K

Review guidance: REVIEW.md from base branch main

@chrarnoldus
chrarnoldus merged commit 0267f00 into main Aug 10, 2026
31 checks passed
@chrarnoldus
chrarnoldus deleted the pentagonal-storm branch August 10, 2026 09:42
t7tran pushed a commit to t7tran/kilocode that referenced this pull request Aug 14, 2026
fix(vscode): infer custom provider reasoning efforts
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants