anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Agent variant incorrectly applied to all models, causing errors with OpenAI-compatible providers #8106

New Issue
Closed
opened 2026-02-16 18:09:11 -05:00 by yindo · 1 comment
yindo commented 2026-02-16 18:09:11 -05:00
Owner
Copy Link
Copy Source

Originally created by @neavo on GitHub (Jan 31, 2026).

Originally assigned to: @rekram1-node on GitHub.

Bug Description

When configuring an agent with a specific variant (e.g., xhigh for reasoning effort), the variant is incorrectly applied to all models used by that agent, not just the model it was configured for. This causes API errors when switching to models that don't support the variant parameter.

Steps to Reproduce

  1. Configure an agent with a model and variant: 
    {
  "agent": {
    "plan": {
      "model": "openai/gpt-5.2",
      "variant": "xhigh"
    }
  }
}
  2. Use the agent with its configured model (works fine)
  3. Switch to a different model (e.g., opencode/kimi-k2.5-free) while still using the same agent
  4. The variant xhigh is still sent to the API, causing: 
    Extra inputs are not permitted, field: 'variant', value: 'xhigh'

Expected Behavior

The variant should only be applied when using the specific model it was configured for. When switching to a different model, the variant should not be sent.

Root Cause

The variant field is currently treated as an unknown key and gets merged into agent.options, which is then passed to all API calls regardless of which model is actually being used.

Environment

  • OpenCode version: latest
  • Provider: OpenAI-compatible (opencode/zen)
  • Model: kimi-k2.5-free (and other non-OpenAI models)

Related

This issue affects any OpenAI-compatible provider that doesn't support the variant parameter, including Kimi, GLM, and other models accessed through the opencode provider.

Originally created by @neavo on GitHub (Jan 31, 2026). Originally assigned to: @rekram1-node on GitHub. ## Bug Description When configuring an agent with a specific `variant` (e.g., `xhigh` for reasoning effort), the variant is incorrectly applied to **all models** used by that agent, not just the model it was configured for. This causes API errors when switching to models that don't support the variant parameter. ## Steps to Reproduce 1. Configure an agent with a model and variant: ```json { "agent": { "plan": { "model": "openai/gpt-5.2", "variant": "xhigh" } } } ``` 2. Use the agent with its configured model (works fine) 3. Switch to a different model (e.g., `opencode/kimi-k2.5-free`) while still using the same agent 4. The variant `xhigh` is still sent to the API, causing: ``` Extra inputs are not permitted, field: 'variant', value: 'xhigh' ``` ## Expected Behavior The `variant` should only be applied when using the **specific model** it was configured for. When switching to a different model, the variant should not be sent. ## Root Cause The `variant` field is currently treated as an unknown key and gets merged into `agent.options`, which is then passed to all API calls regardless of which model is actually being used. ## Environment - OpenCode version: latest - Provider: OpenAI-compatible (opencode/zen) - Model: kimi-k2.5-free (and other non-OpenAI models) ## Related This issue affects any OpenAI-compatible provider that doesn't support the `variant` parameter, including Kimi, GLM, and other models accessed through the opencode provider.
yindo added the zen label 2026-02-16 18:09:11 -05:00
yindo closed this issue 2026-02-16 18:09:11 -05:00
yindo commented 2026-02-16 18:09:11 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 31, 2026):

This issue might be a duplicate of existing issues or related to broader parameter handling problems. Please check:

  • #7138: [FEATURE] Support default variant configuration per agent - Related to variant configuration in agents
  • #11320: [BUG] Kimi K2 Rejects 'permissions' Field in Agent Frontmatter - Similar issue where agent-level fields cause API errors with OpenAI-compatible providers (Kimi K2)
  • #5674: Custom OpenAI-compatible provider options not being passed to API calls - Related to configuration fields not being properly handled for OpenAI-compatible providers
  • #4386: Extra inputs are not permitted, field: 'promptCacheKey' - Similar pattern of extra fields causing errors with providers using OpenAI SDK

The root cause appears to be a broader issue where OpenCode doesn't properly isolate model/provider-specific parameters. Fields like 'variant', 'permissions', and 'promptCacheKey' are being passed to all models/providers instead of being filtered based on provider compatibility.

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Jan 31, 2026): This issue might be a duplicate of existing issues or related to broader parameter handling problems. Please check: - #7138: [FEATURE] Support default variant configuration per agent - Related to variant configuration in agents - #11320: [BUG] Kimi K2 Rejects 'permissions' Field in Agent Frontmatter - Similar issue where agent-level fields cause API errors with OpenAI-compatible providers (Kimi K2) - #5674: Custom OpenAI-compatible provider options not being passed to API calls - Related to configuration fields not being properly handled for OpenAI-compatible providers - #4386: Extra inputs are not permitted, field: 'promptCacheKey' - Similar pattern of extra fields causing errors with providers using OpenAI SDK The root cause appears to be a broader issue where OpenCode doesn't properly isolate model/provider-specific parameters. Fields like 'variant', 'permissions', and 'promptCacheKey' are being passed to all models/providers instead of being filtered based on provider compatibility. Feel free to ignore if none of these address your specific case.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label zen
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#8106
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?