fix(agent-core): scope env model default capabilities#251
Conversation
🦋 Changeset detectedLatest commit: 7bdafcb The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
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: |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 357869682a
ℹ️ About Codex in GitHub
Your team has set up Codex to 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 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| : undefined; | ||
| const capabilities = parseCapabilities(env['KIMI_MODEL_CAPABILITIES']) ?? DEFAULT_CAPABILITIES; | ||
| const capabilities = | ||
| parseCapabilities(env['KIMI_MODEL_CAPABILITIES']) ?? DEFAULT_CAPABILITIES_BY_TYPE[type]; |
There was a problem hiding this comment.
Preserve image support for OpenAI o-series env models
When KIMI_MODEL_PROVIDER_TYPE=openai is used with a standard o-series model such as o3, leaving capabilities unset now makes resolveModelCapabilities rely entirely on the registry; that registry matches all /^o\d/ models to OPENAI_REASONING_CAPABILITY with image_in: false (packages/kosong/src/providers/capability-registry.ts lines 48-55 and 113-114). Since ReadMediaFileTool is only installed when modelCapabilities.image_in || modelCapabilities.video_in is true, image input becomes unavailable for OpenAI env-configured o3 unless users manually set KIMI_MODEL_CAPABILITIES, even though OpenAI documents o3 as supporting image input (https://platform.openai.com/docs/models/o3).
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Addressed in 7bdafcb: OpenAI reasoning+vision capability detection now covers o3, dated o3 snapshots, o3-pro, o4-mini, and GPT-5-family names through the provider capability registry. o3-mini remains image_in: false. Provider capability tests cover these cases.
| : undefined; | ||
| const capabilities = parseCapabilities(env['KIMI_MODEL_CAPABILITIES']) ?? DEFAULT_CAPABILITIES; | ||
| const capabilities = | ||
| parseCapabilities(env['KIMI_MODEL_CAPABILITIES']) ?? DEFAULT_CAPABILITIES_BY_TYPE[type]; |
There was a problem hiding this comment.
Don’t make /model turn detected thinking off
For env-configured OpenAI/Anthropic models where KIMI_MODEL_CAPABILITIES is omitted, this now stores capabilities: undefined; however /model bases thinkingAvailability only on the alias’ capabilities (or adaptiveThinking), not on ProviderManager’s detected capabilities. In a session using a standard thinking model such as o3 or Claude 4, simply opening /model and pressing Enter treats thinking as unsupported and performModelSwitch calls setThinking('off'), disabling thinking even though runtime detection would report it as supported.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Addressed in 7bdafcb: /model now treats missing alias capabilities as unknown rather than unsupported, so opening the selector and pressing Enter no longer forces thinking off. Provider detection remains in the runtime capability registry instead of env-model.ts.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a276622d48
ℹ️ About Codex in GitHub
Your team has set up Codex to 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 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| function isOpenAIReasoningVisionModel(modelName: string): boolean { | ||
| return modelName === 'o3' || /^o3-\d/.test(modelName); | ||
| } |
There was a problem hiding this comment.
Include other vision-capable o-series models
When users configure KIMI_MODEL_PROVIDER_TYPE=openai with o4-mini (or use the Responses provider with o3-pro), this predicate only upgrades o3 and dated o3-* snapshots. Those names fall through to isOpenAIReasoningModel, leaving image_in: false, so the env model exposes no image capability and the media tool is not installed even though OpenAI's model pages list image input for o4-mini and o3-pro (https://platform.openai.com/docs/models/o4-mini, https://platform.openai.com/docs/models/o3-pro). Please include the other vision-capable o-series model IDs rather than only o3 snapshots.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Addressed in 7bdafcb: the OpenAI reasoning+vision registry rule now includes o3-pro and o4-mini via a model-family matcher, with tests covering both providers.
| const declaredCapabilities = | ||
| parseCapabilities(env['KIMI_MODEL_CAPABILITIES']) ?? DEFAULT_CAPABILITIES_BY_TYPE[type]; | ||
| const capabilities = mergeCapabilities( | ||
| declaredCapabilities, | ||
| detectedCapabilities(type, model), |
There was a problem hiding this comment.
Keep thinking enabled for Claude 3.7 env models
For KIMI_MODEL_PROVIDER_TYPE=anthropic with a Claude 3.7 Sonnet model and no KIMI_MODEL_CAPABILITIES, this now leaves declaredCapabilities undefined and relies on the registry, whose claude-3.7-/claude-3- entry reports thinking: false. That removes the previous default thinking capability from the synthetic env alias, so /model treats Claude 3.7 as unsupported and can call setThinking('off') even though Anthropic documents extended thinking for Claude Sonnet 3.7 (https://platform.claude.com/docs/en/docs/about-claude/models/extended-thinking-models). Please special-case Claude 3.7 as thinking-capable before dropping the old default.
Useful? React with 👍 / 👎.
| const capabilities = mergeCapabilities( | ||
| declaredCapabilities, | ||
| detectedCapabilities(type, model), |
There was a problem hiding this comment.
Preserve capabilities for GPT-5 env models
With KIMI_MODEL_PROVIDER_TYPE=openai and a standard GPT-5 family name such as gpt-5 or gpt-5.1, leaving KIMI_MODEL_CAPABILITIES unset now depends on detectedCapabilities, but the OpenAI catalog only recognizes o* and older gpt-4* prefixes. That means these env models lose the previous default image_in/thinking capabilities, so image tools are not installed and /model treats thinking as unsupported even though OpenAI documents GPT-5 as a reasoning model with image input (https://platform.openai.com/docs/models/gpt-5). Please add detection for the GPT-5 family or keep the prior defaults for these known models.
Useful? React with 👍 / 👎.
a276622 to
1fedc3a
Compare
1fedc3a to
7bdafcb
Compare
Related Issue
Resolve #250
Problem
See linked issue.
What changed
KIMI_MODEL_*default capabilities by provider type, so only Kimi env models default toimage_inandthinking.capabilities, allowing provider/model capability detection to apply unless users explicitly setKIMI_MODEL_CAPABILITIES./modelfrom forcing thinking off when a model alias has unknown capabilities.Checklist
gen-changesetsskill, or this PR needs no changeset.gen-docsskill, or this PR needs no doc update.