Kimi K3 reasoning variants incorrectly use budget tokens instead of effort

[BiuBiu2015]

Description

OpenCode generates generic reasoning variants (default/high/max) for Kimi K3 that use budget-token semantics rather than K3's native effort mechanism.

reasoningVariants() attempts to map max through anthropicEffort(), but the k3 API ID returns undefined. It then falls back to ProviderTransform.variants(base), which produces generic Anthropic variants:

• high → thinking: { type: "enabled", budgetTokens: 16000 }
• max → thinking: { type: "enabled", budgetTokens: 31999 }

K3 currently supports only effort max; low and high are not available yet. The default variant works because no effort is sent and Kimi maps null/undefined to max.

Expected behavior: Do not generate generic budget-token variants for K3. Only expose the native max effort variant, or rely on the default variant and its server-side max. Future effort levels should follow the capabilities declared in models.dev.

References:

• Kimi K3 official model documentation: https://www.kimi.com/code/docs/en/kimi-code/models.html
• models.dev PR review identifying the protocol mismatch: feat(moonshotai): add Kimi K3 models.dev#3285 (comment)

Plugins

No response

OpenCode version

1.18.3

Steps to reproduce

1. Authenticate with the built-in Kimi For Coding provider and refresh the model list.
2. Select kimi-for-coding/k3.
3. Open the reasoning variant selector with Ctrl+T.
4. Observe that default, high, and max are available, while the generated high and max options use Anthropic budgetTokens.

Screenshot and/or share link

No response

Operating System

macOS

Terminal

No response

[BiuBiu2015]

Update after Kimi Code exposed multiple K3 effort levels:

• The current Kimi Code documentation and models.dev metadata now declare low, high, and max for K3.
• I re-tested kimi-for-coding/k3 with OpenCode 1.18.3 after refreshing the model cache and captured only the sanitized reasoning-related request fields.

Observed OpenCode wire payloads:

• default: no thinking or effort field (server default is max)
• low: identical to default; the requested variant is silently ignored
• high: thinking: { type: "enabled", budget_tokens: 16000 }
• max: thinking: { type: "enabled", budget_tokens: 31999 }

All four calls returned successfully, but OpenCode never sent K3 native effort controls. A local explicit variant override was also tested end-to-end and produced the expected Anthropic-compatible K3 payloads:

• low: thinking: { type: "adaptive" } + output_config: { effort: "low" }
• high: thinking: { type: "adaptive" } + output_config: { effort: "high" }
• max: thinking: { type: "adaptive" } + output_config: { effort: "max" }

All three native-effort requests were accepted by the Kimi Code endpoint.

The issue therefore remains valid. The expected behavior should now be updated to expose the low / high / max variants declared by models.dev and lower them to K3 native adaptive effort, without falling back to Anthropic budget-token variants.