Kimi K3 full support

[enricoros]

Add Kimi K3 full support through Moonshot's and OpenRouter servers.

Details about changes:
https://platform.kimi.ai/docs/guide/kimi-k3-quickstart

https://platform.kimi.ai/docs/pricing/chat-k3

Take a deep look at tools from-a-point-forward, limits and constants, the rne thinking effort, etc

Web search has not been good and it's being updated. Do not enable it.

[github-actions]

Triaged this and mapped the full touch-surface. Since this is a self-tracking task, here's a concrete implementation blueprint plus the non-obvious gotchas I found.

K3 specs (fetched from the docs you linked)

From platform.kimi.ai/docs/guide/kimi-k3-quickstart + .../pricing/chat-k3:

field	value
model id	kimi-k3
context	1,048,576 (1M native)
max completion	default 131,072, configurable up to 1,048,576
pricing	input (cache-miss) $3.00, output $15.00, cache-hit $0.30 / 1M
thinking	always-on, reasoning_effort only "max" available; returns reasoning_content + content
vision	native (base64/local images + video); no public image URLs
tools	custom tools + tool_choice="required", dynamic tool loading, JSON-schema strict
caching	automatic (no cache-id/TTL) -> maps to our cType: 'oai-ac'
web search	"being updated, not recommended" -> leave disabled per your note

Native Moonshot dialect - the only required change

Everything else (vendor registry, openai.access.ts dialect, listModels.dispatch.ts, id-union, sort) already exists. One entry in _knownMoonshotModels (src/modules/llms/server/openai/models/moonshot.models.ts) gets it working. K3's shape matches the K2.7-code precedent (native multimodal + always-on thinking + no temperature), so it can reuse that interface bundle:

// Kimi K3 - 1M-context flagship (native multimodal, always-on thinking @ max)
{
  idPrefix: 'kimi-k3',
  label: 'Kimi K3',
  pubDate: '20260716', // set to actual release date
  description: 'Native multimodal flagship (text, image, video inputs) with always-on thinking. 1M context.',
  contextWindow: 1048576,
  maxCompletionTokens: 131072, // API default; up to 1M
  interfaces: IF_K2_7_CODE, // Chat, Fn, Json, PromptCaching, Vision, NoTemperature, Reasoning
  // no parameterSpecs - thinking is always-on and only 'max' is available (same as k2.7-code)
  chatPrice: { input: 3.00, output: 15.00, cache: { cType: 'oai-ac', read: 0.30 } },
  benchmark: { cbaElo: 1460 + N }, // TBD
},

Then bump the header updated: date. The LlmsMoonshotModelId union and editorial type-safety update automatically.

Gotchas worth a "deep look" (the parts you flagged)

1. The rne/thinking-effort wire mapping (openai.chatCompletions.ts:174-190). For the moonshot dialect the adapter today hard-codes allowedEffort = ['none','high'] and emits payload.thinking = {enabled|disabled} - it never sends reasoning_effort (only DeepSeek/GLM-5.2 do). So:

• Path A (recommended): omit parameterSpecs entirely, exactly like kimi-k2.7-code. No reasoningEffort is set -> that whole block is skipped -> the model just always thinks at max (its documented default). Zero adapter change, zero maintenance. This is the clean fit given "thinking always enabled".
• Path B (only if empirically required): if the API turns out to require an explicit reasoning_effort: 'max' on the wire, you'd have to extend the moonshot branch (add 'max' to allowedEffort and actually set payload.reasoning_effort for k3), which is the messier route. I'd verify against the live endpoint before taking it.

2. OpenRouter 0-day injection (openrouter.models.ts:275-284) is wrong for K3. Any moonshotai/* reasoning model auto-gets llmVndMiscEffort with enumValues: ['none','high'], and via OpenRouter effort passes straight through as reasoning.effort (openai.chatCompletions.ts:328-331). For K3 that surfaces an Off/On thinking toggle that shouldn't exist (can't disable) and offers no max. Recommend special-casing kimi-k3 in that injection (skip the push, or pin enumValues: ['max']) so the OpenRouter path matches native always-on behavior. Otherwise moonshotai/kimi-k3 works out-of-the-box via the dynamic parser with no manual entry.

3. Limits/constants. 1M contextWindow and 131K maxCompletionTokens are both large jumps from the K2 series (262K / 32K). There's precedent for 1M (alibaba, zai), so no cap issue - just flagging the initial llmResponseTokens default (131K) is intentional and bigger than every other Moonshot entry.

4. Vision-URL limitation. K3 rejects public image URLs (base64/local only). Big-AGI generally inlines attachments as base64 data URIs, so this is usually a non-issue - but worth a quick check that no code path forwards raw image URLs to Moonshot. No NoImageUrl hotfix exists today if one is ever needed.

5. Tools "from-a-point-forward" + web search. Function calling is confirmed (custom tools + tool_choice="required"), covered by LLM_IF_OAI_Fn already in the bundle. Web search stays off - don't add llmVndMoonshotWebSearch/LLM_IF_Tools_WebSearch; the existing // NOT YET comment holds.

Optional follow-ups

• Editorial auto-picks (model.domains.editorial.ts): add { vendor: 'moonshot', modelId: 'kimi-k3' } (+ { vendor: 'openrouter', modelId: 'moonshotai/kimi-k3' }) above kimi-k2.6 in the relevant domains once ELO lands.
• The llms:update-models-kimi command still points at platform.moonshot.ai/docs/pricing/chat - the K3 pricing lives at a separate .../pricing/chat-k3 page, so that skill may need a second source URL.

Happy to draft the diff (Path A + the OpenRouter special-case) if useful - I'm in read-only triage mode here so I haven't pushed anything.

[enricoros]

Shipped in 63a3751. kimi-k3 on native Moonshot (1M context, 131K default output, $3/$15, $0.30 cache hit, always-on thinking) and via OpenRouter (skipped the 0-day thinking toggle injection - reasoning.enabled=false 400s upstream, thinking can't be disabled).

Probed the live API directly: temperature/top_p/n/penalties are hard-fixed (400 on any other value), omitting reasoning_effort vs sending 'max' is behaviorally identical over 39 A/B samples ('max' is both the default and the only valid level - no effort param surfaced until they ship a second level), vision is base64-only (we always inline anyway), tools / strict json_schema / caching / streaming all verified end-to-end.

The probing also surfaced that a named tool_choice 400s on every thinking-mode Kimi request ("tool_choice 'specified' is incompatible with thinking enabled") - and Claude Fable/Mythos 5 already rejected forced tool use - so the 'function_call' tools policy is retired AIX-wide in 135e6c8 (auto/any kept; the one caller now uses 'any').

Web search stays off - Moonshot is still updating it.