文本对话概览

网关地址 https://www.vibeapi.cn/v1，Authorization: Bearer <API_KEY>。文本对话有四套原生协议，按模型家族选它自己的那一套，功能最全； 跨协议调用是网关翻译的，只保证消息、流式和基本工具调用，协议特有字段（Claude 的 thinking 块、Gemini 的 thoughtSignature）会在翻译中丢失。

协议怎么选

逐个模型的推荐入口、可用入口与最后验证日期见模型与入口。

建议默认流式

请求超时上限 120 秒。非流式请求在生成完成前没有任何数据下行，单次生成一旦超过这个时间，连接会被中断。 短输出不受影响；推理型号要等整段思考结束才返回首字节，容易触发。生产环境建议默认开启流式，需要完整文本时在客户端聚合 （OpenAI SDK stream.get_final_response()、Anthropic SDK stream.get_final_message()）。

返回 200 不等于参数生效

两类情况都返回 200，只看状态码发现不了：

key 分组。 key 分 auto（可调用全部模型）和 Claude 官方满血版 两类。GPT 系在两类上实测没有差异； Claude 系在 auto 上会静默忽略提示缓存、max_tokens、stop_sequences、结构化输出，claude-sonnet-5 不返回 thinking 块。 依赖这些约束的代码必须用官方满血 key。详见 Claude Messages · 分组差异。

网关改写。 对部分模型，网关会在转发前删除或改写参数：Claude 新型号的 temperature / top_p / top_k 与 thinking.budget_tokens， Grok 的内置 web_search 工具与 reasoning.effort: none。规则写在各页的「参数改写规则」小节。

判断依据是响应体——thinking 块在不在、usage 里有没有缓存字段、输出长度是否真的受 max_tokens 约束。

国产模型

glm / kimi / qwen / deepseek / MiniMax 两套协议都能调通，工具调用全部可用；max_tokens、停止序列、结构化输出的遵循程度逐模型不同， deepseek-v4-pro 与 kimi-k3 不执行 max_tokens 却仍把结束原因报为已截断。逐项实测见模型与入口 · 国产模型的协议兼容度。

各页的固定结构

每个协议页按同一骨架组织：基本调用（curl / Python / Node.js）→ 认证与流式要求 → 请求参数（先官方定义，再「网关」实测标注）→ 响应字段与流式事件 → 参数改写规则与分组差异 → 真实响应示例 → 能力边界 → 在线调试 → 官方文档。