模型与入口

每个模型该走哪个端点、要不要流式、哪些是网关转换出来的。找到你那一行读完就能走

网关地址 https://www.vibeapi.cn/v1，所有请求带 Authorization: Bearer <API_KEY>。

列出模型

GET /v1/models 返回当前 Key 可调用的全部模型，模型名与下方矩阵一致。

curl "https://www.vibeapi.cn/v1/models" \
  -H "Authorization: Bearer $API_KEY"

from openai import OpenAI

client = OpenAI(base_url="https://www.vibeapi.cn/v1", api_key="YOUR_API_KEY")

for m in client.models.list():
    print(m.id)

import OpenAI from "openai";

const client = new OpenAI({ baseURL: "https://www.vibeapi.cn/v1", apiKey: "YOUR_API_KEY" });

for await (const m of client.models.list()) {
  console.log(m.id);
}

流式与超时

请求超时上限是 120 秒。非流式请求在生成完成前没有任何数据下行，单次生成一旦超过这个时间，连接会被中断，表现为「调用超时」。

短输出的非流式请求正常可用，通常几秒即返回。会触发上限的是长输出与推理型模型—— 它们要等整段推理和生成结束才返回首字节。由于单次生成耗时无法预先判断，生产环境建议默认开启流式：流式从第一个事件起就有数据下行，连接不会闲置到触发超时。

需要一次性拿到完整结果时，请在客户端聚合流式事件，而不是改回非流式。

标注含义

下面每个模型最多有三行，含义是固定的：

推荐就这样写: 这个模型的原生入口，功能最全、字段保真最好。没有特殊理由就用它。
也可能用，但更差: 可以调通，但会损失一些东西——具体差在哪写在模型下面的说明里。
转换网关替你翻译: 你用 A 协议发，网关翻译成 B 协议后再发出。只保证核心功能：消息、流式、基本的工具调用。协议特有的字段（比如 Claude 的 thinking 块、Gemini 的 imageConfig）会在翻译中丢失。调用成功不代表功能等价。

标着 ⓘ 以实测为准 的模型，它们的原生协议逐个模型而异，结论是实测出来的，日期是最后一次验证的时间。没有这个标记的（OpenAI、Anthropic、Google 三家）是确定性的，不随时间变化。

两类静默失效

一、你的 key 分组会影响能力。 key 分 auto（可调用全部模型）和 Claude 官方满血版 两类。Claude 系模型在这两类上，提示缓存、服务端工具和 thinking 的实际可用性是不同的；GPT 系实测没有差异。详见 Messages 页。

二、网关会为部分模型过滤或改写参数，比如 Claude 的 thinking.budget_tokens 会被丢掉、Grok 的内置 web_search 会被移除。规则写在各自的调用页（Messages · Chat · Responses）。

两件事都返回 200，只看状态码发现不了。

国产模型的协议兼容度

国产模型两套协议都能调通，但对参数的遵循程度参差不齐。下面是逐项实测结果（auto key，最后验证 2026-09-09）：

	glm-5.3	kimi-k3	qwen3.8-max	deepseek-v4-pro	MiniMax-M3
基本调用（两协议）	✅	✅	✅	✅	✅
工具调用（两协议）	✅	✅	✅	✅	✅
`max_tokens` 是否执行	✅ 精确	❌ 不执行	✅ 精确	❌ 严重不执行	✅ 精确
`stop`（Chat 协议）	❌	✅	❌	✅	❌
`stop_sequences`（Messages）	❌	✅	✅	✅	❌
`json_object` 结构化输出	❌ 带 markdown 包裹	✅	✅	✅	✅

三条要点：

一、工具调用全部可用。 五个模型在 Chat 和 Messages 两个协议上都能正确返回 tool_calls / tool_use。做 agent 类应用可以放心用。

二、max_tokens 在两个模型上不执行，而且结束字段会误导你。 deepseek-v4-pro 要求 16 token，实际产出 1465（Chat）/ 964（Messages）； kimi-k3 要求 16，实际产出 81 / 75。这两个模型同时将 finish_reason 报为 length、 stop_reason 报为 max_tokens，与实际不符。

不要用 max_tokens 估算成本上限，也不要依据 finish_reason 判断是否截断。使用这两个模型时，以 usage 中的实际 token 数对账。

三、stop / stop_sequences 看模型，而且同一模型在两个协议上可能不同。 qwen3.8-max 在 Messages 协议上生效、在 Chat 协议上不生效。依赖停止序列的逻辑，请先在你要用的那个协议上实测一次，不要跨协议套用结论。

glm-5.3 的 json_object 会返回带 ``` 包裹的代码块，解析前要先剥离。

OpenAI

codex-auto-review建议流式

推荐POST /v1/responses

也可POST /v1/chat/completions

转换/v1/messages · /v1beta/models/{model}:generateContent

分组GPT · default

官方对新项目推荐 Responses；Chat 仍受支持但缓存命中更低、reasoning 不跨轮保留。

gpt-5.3-codex-spark建议流式

推荐POST /v1/responses

也可POST /v1/chat/completions

转换/v1/messages · /v1beta/models/{model}:generateContent

分组GPT · default

官方对新项目推荐 Responses；Chat 仍受支持但缓存命中更低、reasoning 不跨轮保留。

gpt-5.4-openai-compact建议流式

推荐POST /v1/responses

也可POST /v1/chat/completions

转换/v1/messages · /v1beta/models/{model}:generateContent

分组GPT · default

官方对新项目推荐 Responses；Chat 仍受支持但缓存命中更低、reasoning 不跨轮保留。

gpt-5.5建议流式

推荐POST /v1/responses

也可POST /v1/chat/completions

转换/v1/messages · /v1beta/models/{model}:generateContent

分组GPT · default

官方对新项目推荐 Responses；Chat 仍受支持但缓存命中更低、reasoning 不跨轮保留。

gpt-5.5-openai-compact建议流式

推荐POST /v1/responses

也可POST /v1/chat/completions

转换/v1/messages · /v1beta/models/{model}:generateContent

分组GPT · default

官方对新项目推荐 Responses；Chat 仍受支持但缓存命中更低、reasoning 不跨轮保留。

gpt-5.6-luna建议流式

推荐POST /v1/responses

也可POST /v1/chat/completions

转换/v1/messages · /v1beta/models/{model}:generateContent

分组GPT · default

官方对新项目推荐 Responses；Chat 仍受支持但缓存命中更低、reasoning 不跨轮保留。

gpt-5.6-sol建议流式

推荐POST /v1/responses

也可POST /v1/chat/completions

转换/v1/messages · /v1beta/models/{model}:generateContent

分组GPT · default

官方对新项目推荐 Responses；Chat 仍受支持但缓存命中更低、reasoning 不跨轮保留。

gpt-5.6-terra建议流式

推荐POST /v1/responses

也可POST /v1/chat/completions

转换/v1/messages · /v1beta/models/{model}:generateContent

分组GPT · default

官方对新项目推荐 Responses；Chat 仍受支持但缓存命中更低、reasoning 不跨轮保留。

gpt-6-astra建议流式

推荐POST /v1/responses

也可POST /v1/chat/completions

转换/v1/messages · /v1beta/models/{model}:generateContent

分组GPT · default

官方对新项目推荐 Responses；Chat 仍受支持但缓存命中更低、reasoning 不跨轮保留。

OpenAI · 图像

gpt-image-2非流式端点

推荐POST /v1/images/generations

分组GPT · default

同步返回，大尺寸 high 质量可能超过一分钟；客户端超时要放宽，但 120s 是上限。

gpt-image-2.5-1k非流式端点

推荐POST /v1/images/generations

分组GPT · default

同步返回，大尺寸 high 质量可能超过一分钟；客户端超时要放宽，但 120s 是上限。

gpt-image-2.5-flare非流式端点

推荐POST /v1/images/generations

分组GPT · default

同步返回，大尺寸 high 质量可能超过一分钟；客户端超时要放宽，但 120s 是上限。

gpt-image-2.5-sunburst非流式端点

推荐POST /v1/images/generations

分组GPT · default

同步返回，大尺寸 high 质量可能超过一分钟；客户端超时要放宽，但 120s 是上限。

Anthropic

claude-haiku-4-5-20251001建议流式

推荐POST /v1/messages

转换/v1/chat/completions

分组auto · Claude 官方满血版 · Claude 官方特供版 · Kiro

走 Chat 兼容协议时 thinking 块会丢，工具调用只保核心字段。

claude-opus-4-6建议流式

推荐POST /v1/messages

转换/v1/chat/completions

分组auto · Claude 官方满血版 · Claude 官方特供版 · Kiro

走 Chat 兼容协议时 thinking 块会丢，工具调用只保核心字段。

claude-opus-4-7建议流式

推荐POST /v1/messages

转换/v1/chat/completions

分组auto · Claude 官方满血版 · Claude 官方特供版 · Kiro

走 Chat 兼容协议时 thinking 块会丢，工具调用只保核心字段。

claude-opus-4-8建议流式

推荐POST /v1/messages

转换/v1/chat/completions

分组auto · Claude 官方满血版 · Claude 官方特供版 · Kiro

走 Chat 兼容协议时 thinking 块会丢，工具调用只保核心字段。

claude-opus-5建议流式

推荐POST /v1/messages

转换/v1/chat/completions

分组auto · Claude 官方满血版 · Claude 官方特供版 · Kiro

走 Chat 兼容协议时 thinking 块会丢，工具调用只保核心字段。

claude-sonnet-4-6建议流式

推荐POST /v1/messages

转换/v1/chat/completions

分组auto · Claude 官方满血版 · Claude 官方特供版 · Kiro

走 Chat 兼容协议时 thinking 块会丢，工具调用只保核心字段。

claude-sonnet-5建议流式

推荐POST /v1/messages

转换/v1/chat/completions

分组auto · Claude 官方满血版 · Claude 官方特供版 · Kiro

走 Chat 兼容协议时 thinking 块会丢，工具调用只保核心字段。