kimi-k3

日常提取、改写和短问答可以先试 low；需要多步分析时试 high；难题或复杂代码任务再比较 max 的效果。reasoning_effort 默认是 max，只提供 low、high、max 三档，没有 medium 或 none。更高档位可能产生更多思考 Token、等待更久，应结合回答质量和 usage 选择。

Kimi K3 在当前接入中始终开启思考，降低开销应先尝试 low，而不是传 thinking.type=disabled。本页不会发送 thinking、temperature 或 top_p；从其他模型迁移时，也应移除这些控制字段，使用顶层 reasoning_effort 选择档位。

模型生成的思考内容也按输出 Token 计费，所以最终回答的字数不能代表总输出量。usage.completion_tokens 已包含思考 Token；如返回 completion_tokens_details.reasoning_tokens，它是其中的明细，不要重复相加。费用按普通输入、缓存读取和输出三项分别计算，每项 Token 数除以 100 万，再乘本页对应美元单价。

不建议。下一轮 messages 应按顺序带回所需历史，并保留 API 返回的完整 assistant 消息，包括 content、返回的 reasoning_content，以及可能存在的 tool_calls。只保存最终文字会丢失 Kimi 继续思考或续接工具所需的上下文。本页 Playground 会保留返回的思考内容。

不会。模型提出调用哪个函数及其参数，工具的实际执行由你的应用负责。执行后，把原 assistant 消息和 role=tool 的结果消息加入 messages；结果中的 tool_call_id 必须对应原调用的 id，再请求 Kimi 继续回答。不要只把工具结果当作一条普通 user 消息发送。

response_format.type=json_object 用于取得 JSON，但业务字段仍需应用校验。需要约束字段和类型时，使用 response_format.type=json_schema，并提供 response_format.json_schema.schema 和 response_format.json_schema.strict=true。最终 JSON 在 choices[0].message.content 中，不能把 reasoning_content 拼进去解析；本页 JSON output 开关使用的是 json_object。

当前 HiAPI 的这个 Kimi K3 接入只开放文本输入、文本输出。官方模型具备视觉能力，并不代表本页已经开放图片或视频输入。接入时按文本 messages 构造请求，不要直接套用官方的 image_url 或 video_url 示例；以后是否开放，以本页输入能力和 Playground 控件为准。

本页 Kimi K3 当前使用 POST /v1/chat/completions，model 为 kimi-k3；Responses 尚未作为此接入的开放端点。OpenAI SDK 客户端应使用 chat.completions.create 和 messages，并调整推理字段、保留完整 assistant 历史。可以复用同一个 HiAPI API Key，但使用 Responses 的旧代码还需要调整请求与响应处理。

缓存命中是按请求实际返回的 usage.prompt_tokens_details.cached_tokens 计算的，重复文本不保证每次都命中。尽量保持开头的系统提示词、工具定义和固定上下文一致，再追加新消息；切换 reasoning_effort 也可能影响命中。cached_tokens 为 0 时，不能按缓存读取单价估算这部分输入。

不代表。上下文窗口与单次最大输出是不同的限制。本页没有用 1M 上下文推算最大输出，因此未确认的输出上限显示为“-”。可以用 max_tokens 设置本次输出预算；如果 finish_reason 返回 length，要检查是否触及输出限制，再决定缩小任务或续写。