Chat Completions

POST /v1/chat/completions  compatible  语义操作 generate  契约修订 1

状态语义：stateless; an Idempotency-Key adds a 24 hour record of the key, its request fingerprint and how far the request got, and no part of the request or the answer

查看原始契约偏差（英文）

这些是源码契约中的逐条证据。日常接入先看本页示例、字段表和 Profile 覆盖矩阵；排查兼容性边界时 再展开核对原文。

• gateway routes model names; provider-owned chat state is not exposed
• unknown request fields are rejected before provider I/O
• provider-specific unsupported fields are rejected before provider I/O
• Idempotency-Key is optional and buys at-most-once execution upstream, not response replay: a repeat of a key whose request finished answers 409 idempotency_completed rather than the original answer, because the answer is not stored
• a repeat while the first request is still running, or after one whose outcome nobody can determine, answers 409 idempotency_in_progress; it is a refusal rather than a wait, because holding a socket against another request’s outcome is not something this gateway does
• the same key with a different request body answers 409 idempotency_conflict, and keys are scoped to one Project so two Projects may use the same external key
• a request with no Idempotency-Key behaves exactly as before and writes nothing durable; the key is what buys the record
• a request the gateway refuses on its own — a capability filter, a token limit, a Project budget — never reached the upstream and gives its key back, so a retry is answered by the limit it broke rather than by a conflict about a call nobody made
• a key is remembered for 24 hours, whatever state its request ended in, after which the same key is free again — including for a different request
• a streaming repeat is refused before the stream opens, as an ordinary HTTP error rather than an event inside a stream the caller has been told is starting

请求示例

curl

curl https://halro.example.com/v1/chat/completions \
  -H "Authorization: Bearer $HALRO_GATEWAY_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "model": "chat", "max_tokens": 256,
        "messages": [{"role": "user", "content": "你好"}] }'

Python

import os
from openai import OpenAI

client = OpenAI(base_url="https://halro.example.com/v1", api_key=os.environ["HALRO_GATEWAY_KEY"],
                timeout=60.0, max_retries=0)
response = client.chat.completions.create(
    model="chat", max_tokens=256,
    messages=[{"role": "user", "content": "你好"}],
)
print(response.choices[0].message.content)

Node.js

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://halro.example.com/v1", apiKey: process.env.HALRO_GATEWAY_KEY,
  timeout: 60_000, maxRetries: 0,
});
const response = await client.chat.completions.create({
  model: "chat", max_tokens: 256,
  messages: [{ role: "user", content: "你好" }],
});
console.log(response.choices[0].message.content);

SDK 默认会自动重试

官方 SDK 默认会重试 2 次。Halro 在发出上游请求之前就把预算预留落盘，因此客户端的 静默重试会产生多次独立的预留与结算。示例把它关掉，由你自己决定重试策略 —— 见重试、超时与幂等。

请求头

• Authorization
• Content-Type
• Idempotency-Key

请求字段

怎么读这张表

第 2 列沉默不等于支持 —— 契约只记录已声明的限制，没列出的 Profile 是「未声明限制」， 不是「已验证支持」。第 3 列是组合级限制：某些拒绝规则在字段粒度上表达不出来 （例如某个 Profile 拒绝「带工具的流式请求」，而 tools 与 stream 单看都支持）。 字段的类型、是否必填与语义说明当前不在契约里，见页脚说明。

请求字段

字段	不支持该字段的 Provider Profile	组合级限制
model	—	1 见脚注 1
messages	—	—
messages[].name	openai.responses.v1、anthropic.messages.2023-06-01、anthropic.subscription.messages.v1、bigmodel.cn.chat-embeddings.v1、bigmodel.global.chat.v1、bigmodel.cn.coding.chat.v1、bigmodel.global.coding.chat.v1、gemini.generate-content.text.v1beta、bedrock.runtime.converse.text.v1、bedrock.mantle.responses.v1、bedrock.mantle.openai.responses.v1、bedrock.mantle.anthropic.messages.v1、minimax.anthropic.messages.v1、minimax.responses.v1、kimi.anthropic.messages.v1、kimi.responses.v1、minimax.cn.subscription.anthropic.messages.v1、minimax.global.subscription.anthropic.messages.v1、kimi.code.anthropic.messages.v1	—
messages[].content[].image_url	—	—
messages[].content[].detail	anthropic.messages.2023-06-01、anthropic.subscription.messages.v1、bigmodel.cn.chat-embeddings.v1、bigmodel.global.chat.v1、bigmodel.cn.coding.chat.v1、bigmodel.global.coding.chat.v1、bedrock.mantle.anthropic.messages.v1、minimax.anthropic.messages.v1、kimi.anthropic.messages.v1、minimax.cn.subscription.anthropic.messages.v1、minimax.global.subscription.anthropic.messages.v1、kimi.code.anthropic.messages.v1	—
stream	—	2 见脚注 2
stream_options	—	—
temperature	kimi.chat.v1、kimi.anthropic.messages.v1、kimi.responses.v1、kimi.code.openai.chat.v1、minimax.cn.subscription.anthropic.messages.v1、minimax.global.subscription.anthropic.messages.v1、kimi.code.anthropic.messages.v1	3 见脚注 3
top_p	kimi.chat.v1、kimi.anthropic.messages.v1、kimi.responses.v1、kimi.code.openai.chat.v1、minimax.cn.subscription.anthropic.messages.v1、minimax.global.subscription.anthropic.messages.v1、kimi.code.anthropic.messages.v1	4 见脚注 4
max_tokens	minimax.chat.v1、kimi.chat.v1、kimi.responses.v1、kimi.code.openai.chat.v1、minimax.cn.subscription.openai.chat.v1、minimax.global.subscription.openai.chat.v1	5 见脚注 5
max_completion_tokens	deepseek.chat.v1	6 见脚注 6
n	openai.responses.v1、anthropic.messages.2023-06-01、anthropic.subscription.messages.v1、deepseek.chat.v1、bigmodel.cn.chat-embeddings.v1、bigmodel.global.chat.v1、bigmodel.cn.coding.chat.v1、bigmodel.global.coding.chat.v1、bedrock.runtime.converse.text.v1、bedrock.mantle.responses.v1、bedrock.mantle.openai.responses.v1、bedrock.mantle.anthropic.messages.v1、minimax.anthropic.messages.v1、minimax.chat.v1、minimax.responses.v1、kimi.chat.v1、kimi.anthropic.messages.v1、kimi.responses.v1、kimi.code.openai.chat.v1、minimax.cn.subscription.anthropic.messages.v1、minimax.global.subscription.anthropic.messages.v1、minimax.cn.subscription.openai.chat.v1、minimax.global.subscription.openai.chat.v1、kimi.code.anthropic.messages.v1	7 见脚注 7
stop	openai.responses.v1、bigmodel.cn.chat-embeddings.v1、bigmodel.global.chat.v1、bigmodel.cn.coding.chat.v1、bigmodel.global.coding.chat.v1、bedrock.mantle.responses.v1、bedrock.mantle.openai.responses.v1、minimax.anthropic.messages.v1、minimax.chat.v1、minimax.responses.v1、kimi.chat.v1、kimi.responses.v1、kimi.code.openai.chat.v1、minimax.cn.subscription.anthropic.messages.v1、minimax.global.subscription.anthropic.messages.v1、minimax.cn.subscription.openai.chat.v1、minimax.global.subscription.openai.chat.v1	8 见脚注 8
seed	openai.responses.v1、anthropic.messages.2023-06-01、anthropic.subscription.messages.v1、deepseek.chat.v1、bigmodel.cn.chat-embeddings.v1、bigmodel.global.chat.v1、bigmodel.cn.coding.chat.v1、bigmodel.global.coding.chat.v1、gemini.generate-content.text.v1beta、bedrock.runtime.converse.text.v1、bedrock.mantle.responses.v1、bedrock.mantle.openai.responses.v1、bedrock.mantle.anthropic.messages.v1、minimax.anthropic.messages.v1、minimax.chat.v1、minimax.responses.v1、kimi.chat.v1、kimi.anthropic.messages.v1、kimi.responses.v1、kimi.code.openai.chat.v1、minimax.cn.subscription.anthropic.messages.v1、minimax.global.subscription.anthropic.messages.v1、minimax.cn.subscription.openai.chat.v1、minimax.global.subscription.openai.chat.v1、kimi.code.anthropic.messages.v1	—
tools	bigmodel.cn.chat-embeddings.v1、bigmodel.global.chat.v1、bigmodel.cn.coding.chat.v1、bigmodel.global.coding.chat.v1、gemini.generate-content.text.v1beta、bedrock.runtime.converse.text.v1、bedrock.mantle.responses.v1、bedrock.mantle.openai.responses.v1	9 见脚注 9
tool_choice	bigmodel.cn.chat-embeddings.v1、bigmodel.global.chat.v1、bigmodel.cn.coding.chat.v1、bigmodel.global.coding.chat.v1、gemini.generate-content.text.v1beta、bedrock.runtime.converse.text.v1、kimi.chat.v1、kimi.code.openai.chat.v1	10 见脚注 10
parallel_tool_calls	deepseek.chat.v1、bigmodel.cn.chat-embeddings.v1、bigmodel.global.chat.v1、bigmodel.cn.coding.chat.v1、bigmodel.global.coding.chat.v1、gemini.generate-content.text.v1beta、bedrock.runtime.converse.text.v1、minimax.chat.v1、minimax.responses.v1、kimi.chat.v1、kimi.responses.v1、kimi.code.openai.chat.v1、minimax.cn.subscription.openai.chat.v1、minimax.global.subscription.openai.chat.v1	11 见脚注 11
response_format	anthropic.messages.2023-06-01、anthropic.subscription.messages.v1、deepseek.chat.v1、bigmodel.cn.chat-embeddings.v1、bigmodel.global.chat.v1、bigmodel.cn.coding.chat.v1、bigmodel.global.coding.chat.v1、gemini.generate-content.text.v1beta、bedrock.runtime.converse.text.v1、bedrock.mantle.anthropic.messages.v1、minimax.anthropic.messages.v1、minimax.chat.v1、minimax.responses.v1、kimi.anthropic.messages.v1、kimi.code.openai.chat.v1、minimax.cn.subscription.anthropic.messages.v1、minimax.global.subscription.anthropic.messages.v1、minimax.cn.subscription.openai.chat.v1、minimax.global.subscription.openai.chat.v1、kimi.code.anthropic.messages.v1	12 见脚注 12
reasoning_effort	openai.responses.v1、anthropic.messages.2023-06-01、anthropic.subscription.messages.v1、deepseek.chat.v1、gemini.generate-content.text.v1beta、bedrock.runtime.converse.text.v1、bedrock.mantle.responses.v1、bedrock.mantle.openai.responses.v1、bedrock.mantle.anthropic.messages.v1、minimax.anthropic.messages.v1、minimax.responses.v1、kimi.chat.v1、kimi.anthropic.messages.v1、kimi.responses.v1、kimi.code.openai.chat.v1、minimax.cn.subscription.anthropic.messages.v1、minimax.global.subscription.anthropic.messages.v1、kimi.code.anthropic.messages.v1	13 见脚注 13
user	anthropic.messages.2023-06-01、anthropic.subscription.messages.v1、bigmodel.cn.chat-embeddings.v1、bigmodel.global.chat.v1、bigmodel.cn.coding.chat.v1、bigmodel.global.coding.chat.v1、gemini.generate-content.text.v1beta、bedrock.runtime.converse.text.v1、bedrock.mantle.anthropic.messages.v1、minimax.anthropic.messages.v1、minimax.chat.v1、minimax.responses.v1、kimi.chat.v1、kimi.anthropic.messages.v1、kimi.responses.v1、kimi.code.openai.chat.v1、minimax.cn.subscription.anthropic.messages.v1、minimax.global.subscription.anthropic.messages.v1、minimax.cn.subscription.openai.chat.v1、minimax.global.subscription.openai.chat.v1、kimi.code.anthropic.messages.v1	—

响应字段

id object created model choices usage

流事件

chat.completion.chunk [DONE] error

Provider Profile 契约覆盖与本构建可用性

端点成熟度不提升单个 Profile

顶部的 compatible 徽章说的是端点，不是下面每一行。每行的成熟度取自该 Profile 自己的覆盖记录。

本页存在成熟度分歧

bigmodel.cn.chat-embeddings.v1 的成熟度是 experimental，低于端点的 compatible。 bigmodel.global.chat.v1 的成熟度是 experimental，低于端点的 compatible。 bigmodel.cn.coding.chat.v1 的成熟度是 experimental，低于端点的 compatible。 bigmodel.global.coding.chat.v1 的成熟度是 experimental，低于端点的 compatible。 kimi.code.openai.chat.v1 的成熟度是 experimental，低于端点的 compatible。 minimax.cn.subscription.anthropic.messages.v1 的成熟度是 experimental，低于端点的 compatible。 minimax.global.subscription.anthropic.messages.v1 的成熟度是 experimental，低于端点的 compatible。 minimax.cn.subscription.openai.chat.v1 的成熟度是 experimental，低于端点的 compatible。 minimax.global.subscription.openai.chat.v1 的成熟度是 experimental，低于端点的 compatible。 kimi.code.anthropic.messages.v1 的成熟度是 experimental，低于端点的 compatible。

有契约，不代表本构建可创建

bedrock.runtime.converse.text.v1、kimi.responses.v1、minimax.cn.subscription.anthropic.messages.v1、minimax.global.subscription.anthropic.messages.v1 已实现且保留在兼容性契约中，但被 Halro 08af8c8b0b10 的 served Profile matrix 隐藏，Admin 写路径也会拒绝创建。 新实例不能把这些 Profile 配置成 Deployment；已有记录只保留启动与删除通道。

Provider Profile 契约覆盖与本构建可用性

Provider Profile	成熟度	本构建	不支持的请求字段
openai.chat-embeddings.v1	compatible	可创建	未声明
openai.responses.v1	compatible	可创建	messages[].name、n、stop、seed、reasoning_effort
anthropic.messages.2023-06-01	compatible	可创建	messages[].name、n、seed、response_format、reasoning_effort、user、messages[].content[].detail
anthropic.subscription.messages.v1	compatible	默认关闭：需 provider_subscriptions.anthropic_claude	messages[].name、n、seed、response_format、reasoning_effort、user、messages[].content[].detail
azure-openai.chat-embeddings.v1	compatible	可创建	未声明
deepseek.chat.v1	compatible	可创建	n、seed、max_completion_tokens、parallel_tool_calls、response_format、reasoning_effort
bigmodel.cn.chat-embeddings.v1	experimental	可创建	messages[].name、n、seed、parallel_tool_calls、tools、response_format、stop、tool_choice、user、messages[].content[].detail
bigmodel.global.chat.v1	experimental	可创建	messages[].name、n、seed、parallel_tool_calls、tools、response_format、stop、tool_choice、user、messages[].content[].detail
bigmodel.cn.coding.chat.v1	experimental	可创建	messages[].name、n、seed、parallel_tool_calls、tools、response_format、stop、tool_choice、user、messages[].content[].detail
bigmodel.global.coding.chat.v1	experimental	可创建	messages[].name、n、seed、parallel_tool_calls、tools、response_format、stop、tool_choice、user、messages[].content[].detail
openai-compatible.chat-embeddings.v1	compatible	可创建	未声明
gemini.generate-content.text.v1beta	compatible	可创建	messages[].name、seed、tools、tool_choice、parallel_tool_calls、response_format、reasoning_effort、user
bedrock.runtime.converse.text.v1	compatible	withheld（不可创建）	messages[].name、n、seed、tools、tool_choice、parallel_tool_calls、response_format、reasoning_effort、user
bedrock.mantle.chat.v1	compatible	可创建	未声明
bedrock.mantle.openai.chat.v1	compatible	可创建	未声明
bedrock.mantle.responses.v1	compatible	可创建	messages[].name、n、stop、seed、tools、reasoning_effort
bedrock.mantle.openai.responses.v1	compatible	可创建	messages[].name、n、stop、seed、tools、reasoning_effort
bedrock.mantle.anthropic.messages.v1	compatible	可创建	messages[].name、n、seed、response_format、reasoning_effort、user、messages[].content[].detail
minimax.anthropic.messages.v1	compatible	可创建	messages[].name、n、seed、stop、response_format、reasoning_effort、user、messages[].content[].detail
minimax.chat.v1	compatible	可创建	n、seed、stop、response_format、parallel_tool_calls、user、max_tokens
minimax.responses.v1	compatible	可创建	messages[].name、n、seed、stop、response_format、parallel_tool_calls、reasoning_effort、user
kimi.chat.v1	compatible	可创建	temperature、top_p、n、seed、parallel_tool_calls、user、max_tokens、reasoning_effort、stop、tool_choice
kimi.anthropic.messages.v1	compatible	可创建	temperature、top_p、messages[].name、n、seed、response_format、reasoning_effort、user、messages[].content[].detail
kimi.responses.v1	compatible	withheld（不可创建）	temperature、top_p、messages[].name、n、seed、stop、max_tokens、parallel_tool_calls、reasoning_effort、user
kimi.code.openai.chat.v1	experimental	可创建	max_tokens、n、parallel_tool_calls、reasoning_effort、response_format、seed、stop、temperature、tool_choice、top_p、user
minimax.cn.subscription.anthropic.messages.v1	experimental	withheld（不可创建）	messages[].content[].detail、messages[].name、n、reasoning_effort、response_format、seed、stop、temperature、top_p、user
minimax.global.subscription.anthropic.messages.v1	experimental	withheld（不可创建）	messages[].content[].detail、messages[].name、n、reasoning_effort、response_format、seed、stop、temperature、top_p、user
minimax.cn.subscription.openai.chat.v1	experimental	可创建	n、seed、stop、response_format、parallel_tool_calls、user、max_tokens
minimax.global.subscription.openai.chat.v1	experimental	可创建	n、seed、stop、response_format、parallel_tool_calls、user、max_tokens
kimi.code.anthropic.messages.v1	experimental	可创建	temperature、top_p、messages[].name、n、seed、response_format、reasoning_effort、user、messages[].content[].detail

已声明的变换

openai.responses.v1

• 操作结论：Halro 会把 Chat messages 转换到 stateless Responses input items；调用方继续使用北向字段，并按目标 Profile 的字段矩阵核对转换损失。 原始契约：Chat messages are mapped to stateless Responses input items
• 操作结论：Halro 始终向该 Provider 发送 store=false；客户端不能依赖上游保存或续接 Response。 原始契约：store=false is always sent upstream
• 操作结论：该 Profile 没有流式 primitive；stream=true 时 Halro 会在 Provider I/O 前排除该目标，请配置其他流式目标或改为非流式。 原始契约：this profile binds no stream primitive, so a streaming request is routed away rather than refused by field

anthropic.messages.2023-06-01

• 操作结论：Halro 会把 portable Chat content 转换到 Anthropic Messages blocks；调用方继续使用北向字段，并按目标 Profile 的字段矩阵核对转换损失。 原始契约：portable Chat content is mapped to Anthropic Messages blocks
• 操作结论：经 Anthropic 形状传图时，detail 只能省略或设为 auto；其他值会在 Provider I/O 前拒绝，不会静默丢弃。 原始契约：an Anthropic image source is base64, url, or file and has no member for the OpenAI fidelity hint, so detail is rejected before provider I/O at any value other than auto rather than dropped from a request that paid for it
• 操作结论：Anthropic Profile 只接受 response_format=json_schema 和 reasoning_effort=low/medium/high/xhigh/max；json_object 或其他 effort 会在 Provider I/O 前排除该目标。 原始契约：response_format and reasoning_effort are declared unsupported at field granularity because support is value-dependent: json_schema maps to output_config.format and the low/medium/high/xhigh/max ladder maps to output_config.effort, while json_object and any effort outside that ladder have no Anthropic representation and are routed away before provider I/O

anthropic.subscription.messages.v1

• 操作结论：Halro 会把 portable Chat content 转换到 Anthropic Messages blocks；调用方继续使用北向字段，并按目标 Profile 的字段矩阵核对转换损失。 原始契约：portable Chat content is mapped to Anthropic Messages blocks
• 操作结论：经 Anthropic 形状传图时，detail 只能省略或设为 auto；其他值会在 Provider I/O 前拒绝，不会静默丢弃。 原始契约：an Anthropic image source is base64, url, or file and has no member for the OpenAI fidelity hint, so detail is rejected before provider I/O at any value other than auto rather than dropped from a request that paid for it
• 操作结论：Anthropic Profile 只接受 response_format=json_schema 和 reasoning_effort=low/medium/high/xhigh/max；json_object 或其他 effort 会在 Provider I/O 前排除该目标。 原始契约：response_format and reasoning_effort are declared unsupported at field granularity because support is value-dependent: json_schema maps to output_config.format and the low/medium/high/xhigh/max ladder maps to output_config.effort, while json_object and any effort outside that ladder have no Anthropic representation and are routed away before provider I/O

deepseek.chat.v1

• 操作结论：DeepSeek 只接受本页 Profile 矩阵列出的字段；删除其无对应项的字段，否则会在 Provider I/O 前拒绝。 原始契约：DeepSeek speaks this wire format but accepts a smaller member list, so the fields it has no place for are rejected before provider I/O rather than sent and ignored
• 操作结论：北向 user 会映射为 DeepSeek user_id；可用于该 Provider 支持的用户归因，但不要放入敏感身份信息。 原始契约：user is carried as DeepSeek’s user_id
• 操作结论：Anthropic Profile 只接受 reasoning_effort 的 low/medium/high/xhigh/max 和带 schema 的 response_format=json_schema；json_object 或其他 effort 会排除该目标。 原始契约：reasoning_effort and response_format are declared unsupported at field granularity because support is value-dependent: none maps to thinking.type=disabled and the low and high rungs map to thinking.reasoning_effort with thinking enabled, while minimal, medium and xhigh have no DeepSeek rung; json_object maps to response_format and json_schema has no DeepSeek counterpart
• 操作结论：DeepSeek 仅在未开启 thinking 且未同时传 max_tokens 时接受 max_completion_tokens；其他组合会在 Provider I/O 前拒绝。 原始契约：max_completion_tokens is value-dependent too: it counts reasoning tokens and DeepSeek’s max_tokens does not, so it is carried as max_tokens on a request with thinking off and rejected before provider I/O on one with thinking on, or on one that already carries max_tokens
• 操作结论：n 只接受省略或 1，parallel_tool_calls 只接受省略或 true；多结果或强制串行工具调用会排除该 Profile。 原始契约：n and parallel_tool_calls are value-dependent in the same way: n=1 and parallel_tool_calls=true are what omitting the member already means, and only n>1 and a request to run tools one at a time are rejected

bigmodel.cn.chat-embeddings.v1

• 操作结论：BigModel 使用专门的 Chat 请求渲染器；不要依赖仅 OpenAI 支持的成员被转发。 原始契约：BigModel’s smaller Chat request is rendered explicitly; OpenAI-only members are never forwarded
• 操作结论：user 会映射为 BigModel 的 user_id。 原始契约：user is renamed to user_id
• 操作结论：n=1 和 parallel_tool_calls=true 与默认行为等价，发送上游时省略。 原始契约：n=1 and parallel_tool_calls=true are omitted as equivalent defaults
• 操作结论：function tools 按文档最多传递 128 个；不要超过该上限。 原始契约：function tools are carried up to the documented limit of 128
• 操作结论：json_object 会保留，json_schema 会拒绝；不要把两种结构化输出能力等同。 原始契约：json_object is preserved while json_schema is rejected
• 操作结论：流式 usage 来自上游最后一个 chunk，不需要向它发送 stream_options。 原始契约：stream usage is returned by the final provider chunk without sending stream_options
• 操作结论：采样边界、reasoning effort 和 max_tokens 按字段值与确切调用目标在 Provider I/O 前校验。 原始契约：sampling bounds, reasoning effort and max_tokens are checked against field values and the exact invocation target before provider I/O

bigmodel.cn.coding.chat.v1

• 操作结论：GLM Coding Plan 使用独立 /api/coding/paas/v4 路径和订阅密钥，沿用显式渲染的 BigModel Chat 方言。 原始契约：the GLM Coding Plan uses the same explicitly rendered BigModel Chat dialect on its own /api/coding/paas/v4 path and its own subscription key
• 操作结论：产品会按套餐权益选择实际模型档位；以响应中的模型为准，不从请求标识推断实际模型。 原始契约：the product routes every published model identifier onto the tier its plan entitles, so the model that answers is read back from the response rather than assumed from the request
• 操作结论：user 会映射为 BigModel 的 user_id。 原始契约：user is renamed to user_id
• 操作结论：n=1 和 parallel_tool_calls=true 与默认行为等价，发送上游时省略。 原始契约：n=1 and parallel_tool_calls=true are omitted as equivalent defaults
• 操作结论：function tools 按文档最多传递 128 个；不要超过该上限。 原始契约：function tools are carried up to the documented limit of 128
• 操作结论：json_object 会保留，json_schema 会拒绝；不要把两种结构化输出能力等同。 原始契约：json_object is preserved while json_schema is rejected
• 操作结论：流式 usage 来自上游最后一个 chunk，不需要向它发送 stream_options。 原始契约：stream usage is returned by the final provider chunk without sending stream_options
• 操作结论：采样边界、reasoning effort 和 max_tokens 按字段值与确切调用目标在 Provider I/O 前校验。 原始契约：sampling bounds, reasoning effort and max_tokens are checked against field values and the exact invocation target before provider I/O

bigmodel.global.coding.chat.v1

• 操作结论：国际 GLM Coding Plan 使用 Z.AI 的独立 /api/coding/paas/v4 路径及 BigModel Chat 方言。 原始契约：the international GLM Coding Plan uses the documented Z.AI /api/coding/paas/v4 path and the same explicitly rendered BigModel Chat dialect
• 操作结论：user 会映射为 BigModel 的 user_id。 原始契约：user is renamed to user_id
• 操作结论：n=1 和 parallel_tool_calls=true 与默认行为等价，发送上游时省略。 原始契约：n=1 and parallel_tool_calls=true are omitted as equivalent defaults
• 操作结论：function tools 按文档最多传递 128 个；不要超过该上限。 原始契约：function tools are carried up to the documented limit of 128
• 操作结论：国际 Coding 端点尚未实测结构化输出；请求 json_object 或 json_schema 都会排除该目标。 原始契约：json_object and json_schema are both routed away until the international Coding endpoint is measured
• 操作结论：流式支持来自官方 coding-agent 契约；订阅响应未捕获前，流式 usage 核算仍为 unknown。 原始契约：streaming is declared from the official coding-agent contract, but stream usage accounting remains unknown until a subscription response is captured
• 操作结论：采样边界、reasoning effort 和 max_tokens 按字段值与确切调用目标在 Provider I/O 前校验。 原始契约：sampling bounds, reasoning effort and max_tokens are checked against field values and the exact invocation target before provider I/O

bigmodel.global.chat.v1

• 操作结论：Z.AI 在独立国际接入面使用显式渲染的 BigModel Chat 方言，不能混用地区凭据。 原始契约：Z.AI uses the same explicitly rendered BigModel Chat dialect on an isolated global surface
• 操作结论：user 会映射为 BigModel 的 user_id。 原始契约：user is renamed to user_id
• 操作结论：n=1 和 parallel_tool_calls=true 与默认行为等价，发送上游时省略。 原始契约：n=1 and parallel_tool_calls=true are omitted as equivalent defaults
• 操作结论：function tools 按文档最多传递 128 个；不要超过该上限。 原始契约：function tools are carried up to the documented limit of 128
• 操作结论：json_object 会保留，json_schema 会拒绝；不要把两种结构化输出能力等同。 原始契约：json_object is preserved while json_schema is rejected
• 操作结论：流式 usage 来自上游最后一个 chunk，不需要向它发送 stream_options。 原始契约：stream usage is returned by the final provider chunk without sending stream_options
• 操作结论：采样边界、reasoning effort 和 max_tokens 按字段值与确切调用目标在 Provider I/O 前校验。 原始契约：sampling bounds, reasoning effort and max_tokens are checked against field values and the exact invocation target before provider I/O

gemini.generate-content.text.v1beta

• 操作结论：developer message 会并入 Gemini system_instruction；不要依赖多个 developer message 在上游保持独立。 原始契约：developer messages are merged into Gemini system_instruction

bedrock.runtime.converse.text.v1

• 操作结论：Halro 把 Bedrock stop reason 归一化为 OpenAI finish_reason；客户端不要依赖 Bedrock 原始枚举。 原始契约：Bedrock stop reasons are normalized to OpenAI finish reasons

bedrock.mantle.responses.v1

• 操作结论：Halro 会把 Chat messages 转换到 stateless Responses input items；调用方继续使用北向字段，并按目标 Profile 的字段矩阵核对转换损失。 原始契约：Chat messages are mapped to stateless Responses input items
• 操作结论：Halro 始终向该 Provider 发送 store=false；客户端不能依赖上游保存或续接 Response。 原始契约：store=false is always sent upstream
• 操作结论：不要组合 stream=true 与 tools；该 Profile 会在 Provider I/O 前拒绝这类请求。 原始契约：streaming requests with tools are rejected before provider I/O

bedrock.mantle.openai.responses.v1

• 操作结论：Halro 会把 Chat messages 转换到 stateless Responses input items；调用方继续使用北向字段，并按目标 Profile 的字段矩阵核对转换损失。 原始契约：Chat messages are mapped to stateless Responses input items
• 操作结论：Halro 始终向该 Provider 发送 store=false；客户端不能依赖上游保存或续接 Response。 原始契约：store=false is always sent upstream
• 操作结论：不要组合 stream=true 与 tools；该 Profile 会在 Provider I/O 前拒绝这类请求。 原始契约：streaming requests with tools are rejected before provider I/O

bedrock.mantle.anthropic.messages.v1

• 操作结论：Halro 会把 portable Chat content 转换到 Bedrock Mantle Anthropic Messages blocks；调用方继续使用北向字段，并按目标 Profile 的字段矩阵核对转换损失。 原始契约：portable Chat content is mapped to Bedrock Mantle Anthropic Messages blocks
• 操作结论：经 Anthropic 形状传图时，detail 只能省略或设为 auto；其他值会在 Provider I/O 前拒绝，不会静默丢弃。 原始契约：an Anthropic image source is base64, url, or file and has no member for the OpenAI fidelity hint, so detail is rejected before provider I/O at any value other than auto rather than dropped from a request that paid for it
• 操作结论：Bedrock Anthropic 图片只接受 base64/data URL；HTTP(S) image_url 会在 Provider I/O 前被拒绝。 原始契约：Anthropic states that only base64-encoded image sources are available on Amazon Bedrock, so an image_url naming an address to fetch is rejected before provider I/O while a data URL is carried as a base64 source

minimax.anthropic.messages.v1

• 操作结论：Halro 会把 portable Chat content 转换到 MiniMax’s Anthropic Messages blocks；调用方继续使用北向字段，并按目标 Profile 的字段矩阵核对转换损失。 原始契约：portable Chat content is mapped to MiniMax’s Anthropic Messages blocks
• 操作结论：经 Anthropic 形状传图时，detail 只能省略或设为 auto；其他值会在 Provider I/O 前拒绝，不会静默丢弃。 原始契约：an Anthropic image source is base64, url, or file and has no member for the OpenAI fidelity hint, so detail is rejected before provider I/O at any value other than auto rather than dropped from a request that paid for it
• 操作结论：该 MiniMax Profile 不接受 reasoning_effort；必须省略，Halro 会另行明确关闭 thinking。 原始契约：reasoning_effort is unsupported at any value because MiniMax’s reasoning switch is the thinking member and it accepts no output_config; a request that asks for no depth still reaches MiniMax with thinking disabled, because the portable mapper emits that member on its own and MiniMax spells it the same way
• 操作结论：MiniMax 不可靠执行 stop/stop_sequences，因此不要携带该字段；Halro 会在 Provider I/O 前拒绝，避免付费后越过停止边界。 原始契约：stop is rejected before provider I/O rather than sent: MiniMax documents stop_sequences as ignored, so sending it would return 200 for a completion that ran past a boundary the caller set and paid for
• 操作结论：该 MiniMax Profile 没有 response_format 对应字段；必须省略，若需要 json_object 请改用已验证的 Chat Profile。 原始契约：response_format has no counterpart on this face at all: MiniMax accepts no output_config, and its Chat face was later measured serving json_object while this one was not

minimax.chat.v1

• 操作结论：MiniMax 只接受本页 Profile 矩阵列出的字段；不要依赖上游“忽略未知参数”，Halro 会在 Provider I/O 前拒绝。 原始契约：MiniMax speaks this wire format but accepts a smaller member list, so the fields it has no place for are rejected before provider I/O rather than sent and ignored — this upstream documents its unsupported parameters as ignored, not refused
• 操作结论：MiniMax 将 reasoning_effort=none 映射为关闭 thinking，其他档位都只映射为 adaptive；不要假设深度档位被保留。 原始契约：reasoning_effort is carried as MiniMax’s thinking member: none reaches thinking.type=disabled and every other rung reaches thinking.type=adaptive, because MiniMax’s switch has one on state and no depth ladder, so depth is not preserved
• 操作结论：未请求 reasoning 时 Halro 会向 MiniMax 明确发送 thinking=disabled；不要按 MiniMax 默认开启 reasoning 来估算输出或费用。 原始契约：a request that asks for no reasoning is sent with thinking explicitly disabled rather than left to MiniMax’s own default, which is on
• 操作结论：启用 reasoning 时 Halro 同时发送 reasoning_split，推理内容会进入独立字段；客户端不要从回答正文中解析推理。 原始契约：reasoning_split is sent alongside an enabled switch so reasoning returns in its own member instead of inline in the answer
• 操作结论：MiniMax 可直接使用 max_completion_tokens；max_tokens 仅在 thinking 关闭且两者未同时出现时可映射，否则该目标会被排除。 原始契约：max_completion_tokens is carried as itself and max_tokens is carried into it only while thinking is off, because MiniMax’s single output bound counts reasoning; max_tokens is value-dependent for that reason — a request that also thinks, or that carries both members, is routed away by field before provider I/O rather than refused after the budget is reserved
• 操作结论：n 只接受省略或 1，parallel_tool_calls 只接受省略或 true；多结果或强制串行工具调用会排除该 Profile。 原始契约：n and parallel_tool_calls are value-dependent: n=1 and parallel_tool_calls=true are what omitting the member already means
• 操作结论：MiniMax Chat 只验证过 json_object；text 等同省略，json_schema 未验证且会在 Provider I/O 前拒绝。 原始契约：response_format is value-dependent: json_object was measured against a real account on 2026-08-31 and is carried, text is dropped because it means what omitting the member already means, and the schema mode has never been sent and is rejected before provider I/O

minimax.responses.v1

• 操作结论：Halro 会把 Chat messages 转换到 stateless Responses input items；调用方继续使用北向字段，并按目标 Profile 的字段矩阵核对转换损失。 原始契约：Chat messages are mapped to stateless Responses input items
• 操作结论：Halro 始终向该 Provider 发送 store=false；客户端不能依赖上游保存或续接 Response。 原始契约：store=false is always sent upstream
• 操作结论：该 Profile 没有流式 primitive；stream=true 时 Halro 会在 Provider I/O 前排除该目标，请配置其他流式目标或改为非流式。 原始契约：this profile binds no stream primitive, so a streaming request is routed away rather than refused by field — MiniMax itself documents stream on /v1/responses, so this is a Halro scope decision and not an upstream limit
• 操作结论：该 Responses Profile 无法无损返回 reasoning item；请求中必须省略 reasoning，需要推理时改用支持它的 Chat Profile。 原始契约：reasoning is unsupported here and supported on the MiniMax Chat profile: the canonical response mapper cannot preserve the reasoning items this endpoint returns

kimi.chat.v1

• 操作结论：Kimi 使用模型固定采样参数；必须省略 temperature、top_p 和 n，否则请求会在 Provider I/O 前被拒绝。 原始契约：Kimi speaks this wire format but does not model the sampling parameters at all: temperature, top_p and n are absent from its request schema, and its parameter reference pins each to one value per model and answers any other with an error, so they are rejected before provider I/O rather than sent or silently replaced with the pinned value
• 操作结论：Kimi 对 temperature 和 top_p 使用模型固定值；请求中必须省略这两个字段，否则该 Profile 不可用。 原始契约：temperature and top_p are rejected at any value rather than only at the wrong one, because the pinned value varies by model and a field rule is keyed by profile with no target in hand; carrying the pinned value is a capability-model change rather than a platform registration
• 操作结论：Kimi 的 max_tokens 仅适用于未开启 reasoning 且未同时传 max_completion_tokens 的请求；否则该目标会在 Provider I/O 前被排除。 原始契约：max_tokens is value-dependent: Kimi has one output bound and it counts reasoning, so an answer-only bound is the same tokens exactly while nothing is thinking — which is the ordinary case, because a request that names no depth is sent with reasoning switched off. A request that does ask for depth, or that carries both output members, is routed away before provider I/O
• 操作结论：Kimi reasoning_effort 只允许 none、low、high；minimal、medium、xhigh、max 会排除该 Profile。 原始契约：reasoning_effort is value-dependent: none, low and high are carried, and minimal, medium, xhigh and Kimi’s own max are routed away because the portable ladder and Kimi’s do not share those rungs
• 操作结论：reasoning_effort 的可用值取决于具体模型；Route 必须按模型目录拆分并只发送原始契约列出的档位，不能按 Profile 名统一推断。 原始契约：the reasoning member itself depends on the model named: kimi-k3 reads a top-level reasoning_effort while the K2.x line reads thinking, and the renderer follows Kimi’s own OpenAPI discriminator over exact model identifiers rather than inferring a family from a name
• 操作结论：K2.x 只有 reasoning 开关，没有深度档位；非关闭 effort 只保证开启，不保留原档位。 原始契约：K2.x has one on state and no depth ladder, so an effort routed to those models is honored as on rather than preserved
• 操作结论：未指定 reasoning depth 时 Halro 会明确关闭 Kimi reasoning；kimi-k2.7-code 无关闭态，不能用该 Profile 保证无推理输出。 原始契约：a request that names no depth is sent with reasoning explicitly switched off rather than left to Kimi’s default, which is on: measured 2026-09-01, kimi-k3 and kimi-k2.6 both accept the off switch, and leaving it out returned a 64-token budget spent entirely on reasoning with an empty answer. kimi-k2.7-code has no off state and keeps reasoning, which is a per-model fact this profile-scoped declaration cannot express
• 操作结论：Kimi 的 stop 最多五项、每项最多 32 字节；超出时在 Provider I/O 前排除目标。 原始契约：stop is value-dependent: Kimi documents it as honored and it is carried, but only within its published bounds of five sequences of at most 32 bytes each, and a request outside them is routed away before provider I/O rather than refused while the body is encoded
• 操作结论：Kimi 与 reasoning 同用时不要指定命名工具；required 仅在 kimi-k3 可与 depth 同用，K2.x 会在预留后拒绝，生产 Route 应按模型能力拆分。 原始契约：tool_choice is value-dependent, and the two ways of forcing a tool call are not the same value: a named function together with a depth is refused by every Kimi model measured and is routed away before provider I/O, while required together with a depth is refused by the K2.x line and accepted by kimi-k3, which answers with a tool call and a reasoning span in one response. That second half is a per-model limit this profile-scoped declaration cannot express, so it is refused after the reservation rather than routed away with the kimi-k3 request that works

kimi.anthropic.messages.v1

• 操作结论：Halro 会把 portable Chat content 转换到 Kimi’s Anthropic Messages blocks；调用方继续使用北向字段，并按目标 Profile 的字段矩阵核对转换损失。 原始契约：portable Chat content is mapped to Kimi’s Anthropic Messages blocks
• 操作结论：经 Anthropic 形状传图时，detail 只能省略或设为 auto；其他值会在 Provider I/O 前拒绝，不会静默丢弃。 原始契约：an Anthropic image source is base64, url, or file and has no member for the OpenAI fidelity hint, so detail is rejected before provider I/O at any value other than auto rather than dropped from a request that paid for it
• 操作结论：该 Kimi Profile 不接受 reasoning_effort；必须省略，Halro 会关闭 thinking 以保证响应可解码。 原始契约：reasoning_effort is unsupported at any value on this face, and that is what makes the face usable at all: a request naming no depth reaches Kimi with thinking disabled and comes back with no thinking block, which the portable decoder can read, while a request naming a depth comes back with one, which it refuses outright after the upstream has already been paid
• 操作结论：Kimi 对 temperature 和 top_p 使用模型固定值；请求中必须省略这两个字段，否则该 Profile 不可用。 原始契约：temperature and top_p are rejected because Kimi pins each per model and answers any other value with an error
• 操作结论：该 Kimi Profile 只接受带 schema 的 response_format；不支持无 schema 的 json_object。 原始契约：response_format is value-dependent: output_config.format takes a json_schema and enforces it, and there is no schema-less mode
• 操作结论：此 Profile 已实测执行 stop；不要把该结论套到忽略该字段的 MiniMax Profile。 原始契约：stop is carried: measured honored on this face, unlike MiniMax’s, which documents the member as ignored

kimi.responses.v1

• 操作结论：Halro 会把 Chat messages 转换到 stateless Responses input items；调用方继续使用北向字段，并按目标 Profile 的字段矩阵核对转换损失。 原始契约：Chat messages are mapped to stateless Responses input items
• 操作结论：Kimi 使用模型固定采样参数；必须省略 temperature、top_p 和 n，否则请求会在 Provider I/O 前被拒绝。 原始契约：Kimi does not model the sampling parameters on this face either, so temperature and top_p are rejected before provider I/O
• 操作结论：该 Profile 没有流式 primitive；stream=true 时 Halro 会在 Provider I/O 前排除该目标，请配置其他流式目标或改为非流式。 原始契约：this profile binds no stream primitive, so a streaming request is routed away rather than refused by field — Kimi itself documents stream on /v1/responses, so this is a Halro scope decision and not an upstream limit
• 操作结论：该 Kimi Responses Profile 只接受 json_schema，不接受无 schema 的 json_object；后者需改用 Kimi Chat Profile。 原始契约：the schema-less json_object mode is unavailable here and available on the Kimi Chat profile: this endpoint models structured output as text.format and accepts the json_schema type alone, so a json_object request is routed away by the absent json_object capability rather than by field
• 操作结论：该 Responses Profile 无法无损返回 reasoning item；请求中必须省略 reasoning，需要推理时改用支持它的 Chat Profile。 原始契约：reasoning is unsupported here and supported on the Kimi Chat profile: the canonical response mapper cannot preserve the reasoning items this endpoint returns
• 操作结论：此端点仅服务 kimi-k3；以逐模型目录为准，不能从 Profile 声明扩大到其他模型。 原始契约：this endpoint serves kimi-k3 alone, which the model catalog records per model rather than this profile-scoped declaration

kimi.code.openai.chat.v1

• 操作结论：Kimi Code 的 OpenAI 兼容面使用专用请求渲染器；协议形状相同不表示接受全部 OpenAI 成员。 原始契约：Kimi Code’s OpenAI-compatible face is rendered by its own request renderer, not the OpenAI one: the shared wire shape does not extend to the accepted member list
• 操作结论：未请求 reasoning depth 时明确关闭 reasoning；此产品默认推理并计费，不能依赖上游默认值。 原始契约：reasoning is switched off explicitly on every request that asks for no depth, because each model this product serves reasons by default and bills for it
• 操作结论：输出总上限包含 reasoning；只有未开启 thinking 时，才能把 max_tokens 当作纯回答上限传递。 原始契约：the single output bound counts reasoning, so an answer-only max_tokens is carried only while nothing is thinking
• 操作结论：只接受此面发布的 low/high/max 深度；上游不强制这些档位，不能假定保留深度，未发布值会被拒绝。 原始契约：the published depth ladder is low/high/max and the upstream enforces none of it, so a depth this face does not publish is refused rather than served as the product’s default depth

minimax.cn.subscription.anthropic.messages.v1

• 操作结论：MiniMax Subscription Access 在独立产品面复用 Messages 渲染器；按量账号的 fixture 不作为订阅证据。 原始契约：MiniMax Subscription Access reuses the Anthropic Messages wire renderer on its isolated product surface; no metered-account fixture is credited to this profile
• 操作结论：Halro 会把便携请求转换到原始契约指明的 Provider primitive；只使用字段矩阵能保留的语义，需原样传递时改用原生模式。 原始契约：portable optional fields remain fail-closed until a subscription-key fixture establishes their behavior

minimax.global.subscription.anthropic.messages.v1

• 操作结论：MiniMax Subscription Access 在独立产品面复用 Messages 渲染器；按量账号的 fixture 不作为订阅证据。 原始契约：MiniMax Subscription Access reuses the Anthropic Messages wire renderer on its isolated product surface; no metered-account fixture is credited to this profile
• 操作结论：Halro 会把便携请求转换到原始契约指明的 Provider primitive；只使用字段矩阵能保留的语义，需原样传递时改用原生模式。 原始契约：portable optional fields remain fail-closed until a subscription-key fixture establishes their behavior

minimax.cn.subscription.openai.chat.v1

• 操作结论：MiniMax Subscription Access 在独立产品面复用 Chat 渲染器；按量账号的 fixture 不作为订阅证据。 原始契约：MiniMax Subscription Access reuses the OpenAI Chat wire renderer on its isolated product surface; no metered-account fixture is credited to this profile
• 操作结论：依值决定的可选字段在订阅密钥 fixture 建立证据前保持失败关闭，不能按协议相同推定支持。 原始契约：value-dependent optional fields remain fail-closed until a subscription-key fixture establishes their behavior

minimax.global.subscription.openai.chat.v1

• 操作结论：MiniMax Subscription Access 在独立产品面复用 Chat 渲染器；按量账号的 fixture 不作为订阅证据。 原始契约：MiniMax Subscription Access reuses the OpenAI Chat wire renderer on its isolated product surface; no metered-account fixture is credited to this profile
• 操作结论：依值决定的可选字段在订阅密钥 fixture 建立证据前保持失败关闭，不能按协议相同推定支持。 原始契约：value-dependent optional fields remain fail-closed until a subscription-key fixture establishes their behavior

kimi.code.anthropic.messages.v1

• 操作结论：Kimi Code 在独立会员接入面复用 Messages 渲染器；Kimi 开放平台 fixture 不作为会员产品证据。 原始契约：Kimi Code reuses the Anthropic Messages wire renderer on its isolated membership surface; no Kimi Open Platform fixture is credited to this profile
• 操作结论：可移植请求未指定深度时发送 thinking disabled；已在 k3、k3-256k、kimi-for-coding 的流式和非流式请求实测。 原始契约：thinking disabled is sent on every portable request that asks for no depth, and was measured honoured on k3, k3-256k and kimi-for-coding, non-streaming and streaming alike
• 操作结论：此面接受 temperature、top_k 并返回 200 却不能证明生效，因此 Halro 拒绝这些字段。 原始契约：temperature and top_k are refused here because this face accepts them and answers 200 without establishing that either was read, where the Chat face refuses them outright
• 操作结论：stop_sequences 已实测执行，但截断结果返回 stop_reason=end_turn 和空 stop_sequence，不要依赖命中的序列名。 原始契约：stop_sequences is carried and was measured honoured, but a cut answer reports stop_reason end_turn with a null stop_sequence rather than naming the sequence

证据

已验证的证据：gateway_contract、provider_transport_fixture、sdk_blackbox

SDK 黑盒协议桩矩阵

openai-go、openai-node、openai-python

警告

该矩阵只证明这些 SDK 版本能序列化请求、并消费 Halro 声明的响应与流形状。它跑的是协议桩， 不经过真实 Runtime 路由、Gateway Key 认证、路由选择、能力过滤、脱敏与预算核算， 不能被引为端到端网关或真实 Provider 的证据。

最佳实践

路由容灾、预算与流式中断的组合方式见最佳实践案例库。

---

本页的字段表、覆盖矩阵与偏差列表由 Halro 08af8c8b0b10 的兼容性契约生成 （scripts/generate-api-pages.mjs，当前副本摘要 db249a88ce62e5b7…）。

字段的类型、是否必填与语义说明尚未进入契约，因此本页只列字段名。

Footnotes

1. model 的组合级限制：

   • kimi.chat.v1：Kimi 使用模型固定采样参数；必须省略 temperature、top_p 和 n，否则请求会在 Provider I/O 前被拒绝。 原始契约：Kimi speaks this wire format but does not model the sampling parameters at all: temperature, top_p and n are absent from its request schema, and its parameter reference pins each to one value per model and answers any other with an error, so they are rejected before provider I/O rather than sent or silently replaced with the pinned value
   • kimi.chat.v1：Kimi 对 temperature 和 top_p 使用模型固定值；请求中必须省略这两个字段，否则该 Profile 不可用。 原始契约：temperature and top_p are rejected at any value rather than only at the wrong one, because the pinned value varies by model and a field rule is keyed by profile with no target in hand; carrying the pinned value is a capability-model change rather than a platform registration
   • kimi.chat.v1：Kimi 与 reasoning 同用时不要指定命名工具；required 仅在 kimi-k3 可与 depth 同用，K2.x 会在预留后拒绝，生产 Route 应按模型能力拆分。 原始契约：tool_choice is value-dependent, and the two ways of forcing a tool call are not the same value: a named function together with a depth is refused by every Kimi model measured and is routed away before provider I/O, while required together with a depth is refused by the K2.x line and accepted by kimi-k3, which answers with a tool call and a reasoning span in one response. That second half is a per-model limit this profile-scoped declaration cannot express, so it is refused after the reservation rather than routed away with the kimi-k3 request that works
   • kimi.anthropic.messages.v1：Kimi 对 temperature 和 top_p 使用模型固定值；请求中必须省略这两个字段，否则该 Profile 不可用。 原始契约：temperature and top_p are rejected because Kimi pins each per model and answers any other value with an error
   • kimi.responses.v1：Kimi 使用模型固定采样参数；必须省略 temperature、top_p 和 n，否则请求会在 Provider I/O 前被拒绝。 原始契约：Kimi does not model the sampling parameters on this face either, so temperature and top_p are rejected before provider I/O
   • kimi.responses.v1：该 Kimi Responses Profile 只接受 json_schema，不接受无 schema 的 json_object；后者需改用 Kimi Chat Profile。 原始契约：the schema-less json_object mode is unavailable here and available on the Kimi Chat profile: this endpoint models structured output as text.format and accepts the json_schema type alone, so a json_object request is routed away by the absent json_object capability rather than by field
   ↩

2. stream 的组合级限制：

   • openai.responses.v1：该 Profile 没有流式 primitive；stream=true 时 Halro 会在 Provider I/O 前排除该目标，请配置其他流式目标或改为非流式。 原始契约：this profile binds no stream primitive, so a streaming request is routed away rather than refused by field
   • bedrock.mantle.responses.v1：不要组合 stream=true 与 tools；该 Profile 会在 Provider I/O 前拒绝这类请求。 原始契约：streaming requests with tools are rejected before provider I/O
   • bedrock.mantle.openai.responses.v1：不要组合 stream=true 与 tools；该 Profile 会在 Provider I/O 前拒绝这类请求。 原始契约：streaming requests with tools are rejected before provider I/O
   • minimax.responses.v1：该 Profile 没有流式 primitive；stream=true 时 Halro 会在 Provider I/O 前排除该目标，请配置其他流式目标或改为非流式。 原始契约：this profile binds no stream primitive, so a streaming request is routed away rather than refused by field — MiniMax itself documents stream on /v1/responses, so this is a Halro scope decision and not an upstream limit
   • kimi.responses.v1：该 Profile 没有流式 primitive；stream=true 时 Halro 会在 Provider I/O 前排除该目标，请配置其他流式目标或改为非流式。 原始契约：this profile binds no stream primitive, so a streaming request is routed away rather than refused by field — Kimi itself documents stream on /v1/responses, so this is a Halro scope decision and not an upstream limit
   ↩

3. temperature 的组合级限制：

   • kimi.chat.v1：Kimi 使用模型固定采样参数；必须省略 temperature、top_p 和 n，否则请求会在 Provider I/O 前被拒绝。 原始契约：Kimi speaks this wire format but does not model the sampling parameters at all: temperature, top_p and n are absent from its request schema, and its parameter reference pins each to one value per model and answers any other with an error, so they are rejected before provider I/O rather than sent or silently replaced with the pinned value
   • kimi.chat.v1：Kimi 对 temperature 和 top_p 使用模型固定值；请求中必须省略这两个字段，否则该 Profile 不可用。 原始契约：temperature and top_p are rejected at any value rather than only at the wrong one, because the pinned value varies by model and a field rule is keyed by profile with no target in hand; carrying the pinned value is a capability-model change rather than a platform registration
   • kimi.anthropic.messages.v1：Kimi 对 temperature 和 top_p 使用模型固定值；请求中必须省略这两个字段，否则该 Profile 不可用。 原始契约：temperature and top_p are rejected because Kimi pins each per model and answers any other value with an error
   • kimi.responses.v1：Kimi 使用模型固定采样参数；必须省略 temperature、top_p 和 n，否则请求会在 Provider I/O 前被拒绝。 原始契约：Kimi does not model the sampling parameters on this face either, so temperature and top_p are rejected before provider I/O
   • kimi.code.anthropic.messages.v1：此面接受 temperature、top_k 并返回 200 却不能证明生效，因此 Halro 拒绝这些字段。 原始契约：temperature and top_k are refused here because this face accepts them and answers 200 without establishing that either was read, where the Chat face refuses them outright
   ↩

4. top_p 的组合级限制：

   • kimi.chat.v1：Kimi 使用模型固定采样参数；必须省略 temperature、top_p 和 n，否则请求会在 Provider I/O 前被拒绝。 原始契约：Kimi speaks this wire format but does not model the sampling parameters at all: temperature, top_p and n are absent from its request schema, and its parameter reference pins each to one value per model and answers any other with an error, so they are rejected before provider I/O rather than sent or silently replaced with the pinned value
   • kimi.chat.v1：Kimi 对 temperature 和 top_p 使用模型固定值；请求中必须省略这两个字段，否则该 Profile 不可用。 原始契约：temperature and top_p are rejected at any value rather than only at the wrong one, because the pinned value varies by model and a field rule is keyed by profile with no target in hand; carrying the pinned value is a capability-model change rather than a platform registration
   • kimi.anthropic.messages.v1：Kimi 对 temperature 和 top_p 使用模型固定值；请求中必须省略这两个字段，否则该 Profile 不可用。 原始契约：temperature and top_p are rejected because Kimi pins each per model and answers any other value with an error
   • kimi.responses.v1：Kimi 使用模型固定采样参数；必须省略 temperature、top_p 和 n，否则请求会在 Provider I/O 前被拒绝。 原始契约：Kimi does not model the sampling parameters on this face either, so temperature and top_p are rejected before provider I/O
   ↩

5. max_tokens 的组合级限制：

   • deepseek.chat.v1：DeepSeek 仅在未开启 thinking 且未同时传 max_tokens 时接受 max_completion_tokens；其他组合会在 Provider I/O 前拒绝。 原始契约：max_completion_tokens is value-dependent too: it counts reasoning tokens and DeepSeek’s max_tokens does not, so it is carried as max_tokens on a request with thinking off and rejected before provider I/O on one with thinking on, or on one that already carries max_tokens
   • minimax.chat.v1：MiniMax 可直接使用 max_completion_tokens；max_tokens 仅在 thinking 关闭且两者未同时出现时可映射，否则该目标会被排除。 原始契约：max_completion_tokens is carried as itself and max_tokens is carried into it only while thinking is off, because MiniMax’s single output bound counts reasoning; max_tokens is value-dependent for that reason — a request that also thinks, or that carries both members, is routed away by field before provider I/O rather than refused after the budget is reserved
   • kimi.chat.v1：Kimi 的 max_tokens 仅适用于未开启 reasoning 且未同时传 max_completion_tokens 的请求；否则该目标会在 Provider I/O 前被排除。 原始契约：max_tokens is value-dependent: Kimi has one output bound and it counts reasoning, so an answer-only bound is the same tokens exactly while nothing is thinking — which is the ordinary case, because a request that names no depth is sent with reasoning switched off. A request that does ask for depth, or that carries both output members, is routed away before provider I/O
   ↩

6. max_completion_tokens 的组合级限制：

   • deepseek.chat.v1：DeepSeek 仅在未开启 thinking 且未同时传 max_tokens 时接受 max_completion_tokens；其他组合会在 Provider I/O 前拒绝。 原始契约：max_completion_tokens is value-dependent too: it counts reasoning tokens and DeepSeek’s max_tokens does not, so it is carried as max_tokens on a request with thinking off and rejected before provider I/O on one with thinking on, or on one that already carries max_tokens
   • minimax.chat.v1：MiniMax 可直接使用 max_completion_tokens；max_tokens 仅在 thinking 关闭且两者未同时出现时可映射，否则该目标会被排除。 原始契约：max_completion_tokens is carried as itself and max_tokens is carried into it only while thinking is off, because MiniMax’s single output bound counts reasoning; max_tokens is value-dependent for that reason — a request that also thinks, or that carries both members, is routed away by field before provider I/O rather than refused after the budget is reserved
   ↩

7. n 的组合级限制：

   • deepseek.chat.v1：n 只接受省略或 1，parallel_tool_calls 只接受省略或 true；多结果或强制串行工具调用会排除该 Profile。 原始契约：n and parallel_tool_calls are value-dependent in the same way: n=1 and parallel_tool_calls=true are what omitting the member already means, and only n>1 and a request to run tools one at a time are rejected
   • kimi.chat.v1：Kimi 使用模型固定采样参数；必须省略 temperature、top_p 和 n，否则请求会在 Provider I/O 前被拒绝。 原始契约：Kimi speaks this wire format but does not model the sampling parameters at all: temperature, top_p and n are absent from its request schema, and its parameter reference pins each to one value per model and answers any other with an error, so they are rejected before provider I/O rather than sent or silently replaced with the pinned value
   ↩

8. stop 的组合级限制：

   • minimax.anthropic.messages.v1：MiniMax 不可靠执行 stop/stop_sequences，因此不要携带该字段；Halro 会在 Provider I/O 前拒绝，避免付费后越过停止边界。 原始契约：stop is rejected before provider I/O rather than sent: MiniMax documents stop_sequences as ignored, so sending it would return 200 for a completion that ran past a boundary the caller set and paid for
   • kimi.chat.v1：Kimi 的 stop 最多五项、每项最多 32 字节；超出时在 Provider I/O 前排除目标。 原始契约：stop is value-dependent: Kimi documents it as honored and it is carried, but only within its published bounds of five sequences of at most 32 bytes each, and a request outside them is routed away before provider I/O rather than refused while the body is encoded
   ↩

9. tools 的组合级限制：

   • deepseek.chat.v1：n 只接受省略或 1，parallel_tool_calls 只接受省略或 true；多结果或强制串行工具调用会排除该 Profile。 原始契约：n and parallel_tool_calls are value-dependent in the same way: n=1 and parallel_tool_calls=true are what omitting the member already means, and only n>1 and a request to run tools one at a time are rejected
   • bedrock.mantle.responses.v1：不要组合 stream=true 与 tools；该 Profile 会在 Provider I/O 前拒绝这类请求。 原始契约：streaming requests with tools are rejected before provider I/O
   • bedrock.mantle.openai.responses.v1：不要组合 stream=true 与 tools；该 Profile 会在 Provider I/O 前拒绝这类请求。 原始契约：streaming requests with tools are rejected before provider I/O
   ↩

10. tool_choice 的组合级限制：

    • kimi.chat.v1：Kimi 与 reasoning 同用时不要指定命名工具；required 仅在 kimi-k3 可与 depth 同用，K2.x 会在预留后拒绝，生产 Route 应按模型能力拆分。 原始契约：tool_choice is value-dependent, and the two ways of forcing a tool call are not the same value: a named function together with a depth is refused by every Kimi model measured and is routed away before provider I/O, while required together with a depth is refused by the K2.x line and accepted by kimi-k3, which answers with a tool call and a reasoning span in one response. That second half is a per-model limit this profile-scoped declaration cannot express, so it is refused after the reservation rather than routed away with the kimi-k3 request that works
    ↩

11. parallel_tool_calls 的组合级限制：

    • deepseek.chat.v1：n 只接受省略或 1，parallel_tool_calls 只接受省略或 true；多结果或强制串行工具调用会排除该 Profile。 原始契约：n and parallel_tool_calls are value-dependent in the same way: n=1 and parallel_tool_calls=true are what omitting the member already means, and only n>1 and a request to run tools one at a time are rejected
    ↩

12. response_format 的组合级限制：

    • anthropic.messages.2023-06-01：Anthropic Profile 只接受 response_format=json_schema 和 reasoning_effort=low/medium/high/xhigh/max；json_object 或其他 effort 会在 Provider I/O 前排除该目标。 原始契约：response_format and reasoning_effort are declared unsupported at field granularity because support is value-dependent: json_schema maps to output_config.format and the low/medium/high/xhigh/max ladder maps to output_config.effort, while json_object and any effort outside that ladder have no Anthropic representation and are routed away before provider I/O
    • anthropic.subscription.messages.v1：Anthropic Profile 只接受 response_format=json_schema 和 reasoning_effort=low/medium/high/xhigh/max；json_object 或其他 effort 会在 Provider I/O 前排除该目标。 原始契约：response_format and reasoning_effort are declared unsupported at field granularity because support is value-dependent: json_schema maps to output_config.format and the low/medium/high/xhigh/max ladder maps to output_config.effort, while json_object and any effort outside that ladder have no Anthropic representation and are routed away before provider I/O
    • minimax.chat.v1：MiniMax Chat 只验证过 json_object；text 等同省略，json_schema 未验证且会在 Provider I/O 前拒绝。 原始契约：response_format is value-dependent: json_object was measured against a real account on 2026-08-31 and is carried, text is dropped because it means what omitting the member already means, and the schema mode has never been sent and is rejected before provider I/O
    ↩

13. reasoning_effort 的组合级限制：

    • anthropic.messages.2023-06-01：Anthropic Profile 只接受 response_format=json_schema 和 reasoning_effort=low/medium/high/xhigh/max；json_object 或其他 effort 会在 Provider I/O 前排除该目标。 原始契约：response_format and reasoning_effort are declared unsupported at field granularity because support is value-dependent: json_schema maps to output_config.format and the low/medium/high/xhigh/max ladder maps to output_config.effort, while json_object and any effort outside that ladder have no Anthropic representation and are routed away before provider I/O
    • anthropic.subscription.messages.v1：Anthropic Profile 只接受 response_format=json_schema 和 reasoning_effort=low/medium/high/xhigh/max；json_object 或其他 effort 会在 Provider I/O 前排除该目标。 原始契约：response_format and reasoning_effort are declared unsupported at field granularity because support is value-dependent: json_schema maps to output_config.format and the low/medium/high/xhigh/max ladder maps to output_config.effort, while json_object and any effort outside that ladder have no Anthropic representation and are routed away before provider I/O
    • kimi.chat.v1：Kimi reasoning_effort 只允许 none、low、high；minimal、medium、xhigh、max 会排除该 Profile。 原始契约：reasoning_effort is value-dependent: none, low and high are carried, and minimal, medium, xhigh and Kimi’s own max are routed away because the portable ladder and Kimi’s do not share those rungs
    ↩