Repository navigation
fix(core): don't clobber model variants supplied by earlier transforms - #59835
PranjalAgarwal01 wants to merge 4 commits into
Conversation
The late config transform re-resolves model.variants with the generic low/medium/high effort list whenever a configured model has no explicit variants or capabilities.reasoning. This overwrites variants supplied by an earlier model transform (e.g. a spec-pack plugin such as opencode-model-specs), causing custom reasoning tiers to disappear on fresh locations. Skip the re-resolution when the model already has variants and was not repackaged for a different package, so externally supplied tiers survive. Config-level variants/capabilities.reasoning still take precedence.
github-actions
Bot
added
needs:issue
needs:compliance
|
Thanks for your contribution! This PR doesn't have a linked issue. All PRs must reference an existing issue. Please:
See CONTRIBUTING.md for details. |
![opencodejr[bot]](https://avatars.githubusercontent.com/in/5497873?s=60&v=4){kind=small}
There was a problem hiding this comment.
The fix works: with this change, variants that a plugin adds to a configured custom model survive the late config transform. I checked it with a throwaway test against the base:
- On the base, an earlier model transform's
none/xhighvariants were replaced by the generated list. - With this PR, they are kept.
test/config/provider.test.ts passes on both, and typecheck:tsc passes for packages/core.
Public API: unchanged.
One regression should be fixed before merge: when config also sets the model's package, the plugin's variants are now kept even though they are spelled for the old package (see the inline comment).
Follow-up to preserve-plugin-supplied-model-variants: the guard only considered source.base when deciding whether inherited variants are stale, so a config-level package override (config.package) on a custom model (no catalog base) kept variants spelled for the old package. Treat a config package change like a repackaging.
github-actions
Bot
removed
the
needs:compliance
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |
There was a problem hiding this comment.
The earlier point is addressed: a custom model whose package config changes now gets fresh variants for the new package. The #59836 reproduction is fixed when run from source. The plugin's none/low/medium/xhigh are kept, where the base shows low/medium/high.
Public API: unchanged.
The new check breaks catalog models (see the inline comment):
test/config/provider.test.tsnow fails "keeps a moved catalog model without reasoning variants free of variants". It passes on the base.- A catalog model whose config
packageis the same package in itsaisdk:form, as the v1npmsetting migrates to, loses its catalog variants.
Use the normalized post-overlay package instead of raw config.package, and only for models without a catalog base. Raw aisdk: prefixed values never equal the normalized pre-overlay package, which rebuilt variants for catalog models that repackaged already handles and clobbered their fast variants.
There was a problem hiding this comment.
Both earlier points are addressed:
- A custom model whose package config changes gets fresh variants for the new package.
- The package check now applies only to models without a catalog base, so catalog variants and the empty-variants case are kept again.
I re-ran the #59836 reproduction from source. The plugin's none/low/medium/xhigh are kept, where the base shows low/medium/high. I also re-ran my earlier package-move and same-package cases. test/config/provider.test.ts passes 39/39, and typecheck:tsc passes for packages/core.
Public API: unchanged.
No further concerns.
Issue for this PR
Closes #59836
Type of change
What does this PR do?
OpenCode 2.2.0's late config transform (packages/core/src/config/plugin/provider.ts) re-resolves
model.variantswith the generic["low","medium","high"]effort list whenever a configured model has neitherconfig.variantsnorconfig.capabilities.reasoning. This overwrites variants supplied by an earlier model transform (e.g. a spec-pack plugin such as opencode-model-specs), so custom reasoning tiers disappear on fresh locations.This change skips the re-resolution when the model already has variants and was not repackaged for a different package, so externally supplied tiers survive. Config-level
variants/capabilities.reasoningstill take precedence.A follow-up rebuilds variants when a custom model's package changes via config (treats a config-level package override like a repackaging), so stale variants spelled for the old package are not kept. The check compares the normalized post-overlay package against the pre-overlay package and applies only to models without a catalog base;
repackagedcontinues to handle catalog models (preserves thefastvariant and the empty-variants case).How did you verify your code works?
Could not type-check the full monorepo locally (shallow clone, no node_modules). A maintainer independently reproduced the bug on 2.2.0 and latest dev, confirmed the approach fixes it, and verified that test/config/provider.test.ts passes on both the base and with this PR, and that typecheck:tsc passes for packages/core. Manually verified the symptom and the workaround (config-level variants) against a live 2.2.0 service before submitting.
Checklist
Added by the opencode bot (AI-generated).
Fixes #59836
Related: #55979