feat(oauth): parse support_efforts/default_effort in custom registry import - #1564
Conversation
…import - parse support_efforts / default_effort from api.json model entries - map them onto model aliases as supportEfforts / defaultEffort - treat both fields as upstream-owned in CUSTOM_REGISTRY_MODEL_FIELDS so refreshes sync and stale values are dropped
🦋 Changeset detectedLatest commit: 52340bc The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
commit: |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 03faaeefee
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| maxContextSize, | ||
| capabilities, | ||
| displayName, | ||
| ...(model.support_efforts !== undefined ? { supportEfforts: model.support_efforts } : {}), |
There was a problem hiding this comment.
When a registry model supplies support_efforts/default_effort but does not also set reasoning: true, this stores the effort levels while capabilities remains resolved without thinking because resolveCapabilities only considers the reasoning flag. Downstream thinking defaults check capabilities first, so these imported models are treated as unsupported/off despite advertising concrete efforts. Add the thinking capability when accepted support_efforts is non-empty, or ignore the effort fields unless reasoning is true.
Useful? React with 👍 / 👎.
Models declaring effort levels without reasoning: true now get the thinking capability, so their efforts are not silently ignored.
1 participant
Related Issue
No linked issue — the problem is explained below.
Problem
When adding a platform via a custom registry (api.json), model entries declaring
support_efforts/default_efforthad those fields silently dropped: the parser only recognizedtool_call,reasoning,modalities, andlimit. As a result, models imported this way never exposed thinking effort levels, even though the same fields are already honored for managed Kimi Code and open-platform imports.What changed
support_efforts(string array) anddefault_effort(non-empty string) from api.json model entries in the custom-registry import path; invalid values are ignored, matching the existing lenient handling of other optional fields.supportEfforts/defaultEffort— the same camelCase keys the managed and open-platform flows write, so the existing thinking-effort selection works without downstream changes.CUSTOM_REGISTRY_MODEL_FIELDS, making them upstream-owned: refreshes sync declared values, and stale values are dropped when upstream stops declaring them (same semantics as the managed flow).custom-registry.test.tsandmodel-alias-merge.test.ts.Checklist
gen-changesetsskill, or this PR needs no changeset.gen-docsskill, or this PR needs no doc update.