Codex 中转站：Vana API 接入价 2.50 元起

终端里的 AgentZH2026-11-05

§ 一个地址，三种协议，先把接入这件事说清楚

如果你在找 Codex 中转站，Vana API 的思路很直接：一个地址，三种协议，尽量少的设置。API 请求统一发往 https://api.vanaapi.com，不需要为不同模型去记住不同的入口地址。keys、余额和 usage log 则放在主站 https://vanaapi.com 的 dashboard 里，两边分工清楚。

所谓三种协议，指的是同一个地址下有三条不同的请求路径：Anthropic Messages、Gemini native protocol，以及 OpenAI 格式。选哪一条，取决于你使用的客户端和你要调用的模型，而不是取决于 Vana API 要你填多少东西。判断标准可以压缩成一句话：先看模型，再看客户端，最后才是路径。

对 Codex 来说，答案更短。GPT 模型除了在 /v1/chat/completions 上响应，也在 /v1/responses 上响应，而 Codex 使用的正是 /v1/responses。所以把地址指向 Vana API、填好 key、指定模型 id，就构成了接入 Codex 的基本路径。

§ Codex 接入：看清模型 id 和两条 GPT 路径

在 Vana API 上使用 Codex，模型 id 是需要留意的一个细节。价格表中的 GPT-6.1 Sol 对应 gpt-6.1-sol，GPT-5.6 Sol 对应 gpt-5.6-sol，GPT-6 Astra 对应 gpt-6.astra。选择时按 id 填写，不要凭显示名称自行改写。

如果你还想在同一套环境里使用 GPT 之外的模型，Vana API 也把常用客户端放在同一个地址下处理。Cursor、Cline、Roo Code、OpenCode、Cherry Studio、任意 OpenAI SDK 或 cURL，都走 OpenAI 格式的 /v1/chat/completions。这意味着 GPT、Grok、DeepSeek、GLM、Kimi、Qwen、MiniMax、MiMo 可以共用一个 base address，切换模型时主要改的是模型名。

以 GPT-6.1 Sol 为例，它的 Vana API 价格为每百万 token 输入 ¥1.00、输出 ¥6.00；对照表列出的官方标价是输入 ¥14.4、输出 ¥72。GPT-5.6 Sol 的 Vana API 价格是输入 ¥2.50、输出 ¥13.00。是否划算，取决于你实际调用的模型和 token 构成，而不是靠一句笼统的比较。

§ 协议匹配：不同模型对应不同客户端

这一步是接入教程里最需要讲清楚的部分。Claude 模型只从官方 Claude Code 或 Claude Desktop 调用，版本要求为 2.1.285 或更高，这两个客户端本身就使用 Anthropic Messages，也就是 /v1/messages。Claude 模型不适用于其他客户端、SDK、cURL 或脚本。

Gemini 模型只从 Gemini CLI 调用，走 Gemini 原生协议 /v1beta/models/...，它不是 OpenAI 兼容格式。如果你手上的工具链以 Gemini CLI 为主，那么 Vana API 上对应的模型 id 可以直接填入价格表给出的名称，例如 gemini-2.5-flash、gemini-3.1-pro、gemini-3.8-flash 和 gemini-4-argon。

其余模型走 OpenAI 格式，因此适合 Cursor、Cline、Roo Code、OpenCode、Cherry Studio、任意 OpenAI SDK 或 cURL。价格表中属于这一类的 id 包括 grok-4.7、deepseek-v4-flash、deepseek-v4-pro、glm-5.3、kimi-k3、qwen3.7-plus、qwen3.8-max、MiniMax-M3 和 MiMo-V2.6-Pro。

把三条规则放在一起，决策顺序就很自然：先确定模型属于哪一类，再确认自己的客户端是否属于该类允许的调用方式，最后把地址统一填成 https://api.vanaapi.com。Vana API 在这里承担的是统一入口与计费，而不是要求你为每个模型重做一遍配置。

§ 价格与套餐：按真实 token 结算，也能按周期选

Vana API 采用预付余额，按真实 token 计费，没有月费。注册赠送 ¥0.50 的额度，可以先用来跑通一次请求，确认地址、key 和模型 id 都填写正确，再决定充值多少。

如果你希望费用上限更直观，Vana API 也提供按 30 天计算的月度套餐，并且套餐内限定了可用模型范围：

Claude 最多 $450 / 30 天：¥466.00 for 30 days，每周上限 $140，仅限 Claude 模型。
Claude 最多 $1,050 / 30 天：¥1,106.00 for 30 days，每周上限 $320，仅限 Claude 模型。
GPT 最多 $2,750 / 30 天：¥746.00 for 30 days，每周上限 $820，仅限 GPT 模型。

对于以 Codex 为主的使用场景，第三个套餐是匹配度较高的选择，因为 Codex 使用的正是 GPT 路径上的 /v1/responses。如果你更在意按次用量而不是周期额度，按量付费则把选择权留在你手里：花多少，取决于实际消耗。

价格表里也有输入输出价差较小的模型，便于控制输出成本。MiMo V2.6 Pro 为每百万 token 输入 ¥1.50、输出 ¥2.50；Qwen3.7 Plus 为输入 ¥0.92、输出 ¥3.00；MiniMax M3 为输入 ¥1.00、输出 ¥4.00。这类模型适合输出较长、或调用频率较高的任务。

§ 余额、日志与退款：把账目放在看得见的地方

keys 在 dashboard 创建，余额和 usage log 也在 dashboard 查看。每一次调用都会被记入 usage log，因此判断费用是否合理，不需要靠估算。Vana API 的结构是：请求走 API 地址，账目看 dashboard，两者不混在一起。

退款规则也有明确边界：充值后 3 天内，未使用的余额可以退款，扣除已使用部分和支付处理方手续费。这意味着如果你还在测试阶段，可以先小额充值，把接入流程走通后再决定是否继续投入。

邀请机制同样写在规则里：你邀请的人付费后，你获得其付费金额的 14%，再下一层获得 5%，收益可以从 ¥100.00 起提取。它更像是长期使用中的附带项，而不是选择 Vana API 的前提条件。

综合来看，选择 Vana API 的判断标准可以落到几条具体的线上：地址是不是只有 https://api.vanaapi.com 一个，协议是否按模型与客户端的对应关系划分，Codex 是否直接使用 /v1/responses，计费是否按真实 token 记录，以及用量能否在 dashboard 里逐条查看。一个地址、三种协议、尽量少的设置，这三点在 Vana API 上是同一件事的三个侧面。