用Gemini CLI走Vana API：按量付费怎么接
§ 先看接入面：一个地址，三种协议
对开源维护者来说，判断一个 API 中转是否值得用，通常从三件事开始：地址是否统一、协议是否匹配、配置是否够少。Vana API 把这三件事压缩到同一处。所有请求都发往 https://api.vanaapi.com，这一个地址同时承接 Anthropic Messages、Gemini 原生协议和 OpenAI 格式三种协议路径。
这意味着你不必为不同模型维护多套 base URL。切换模型时，改变的是请求走的协议和模型标识，而不是更换服务地址。对于经常在 issue 回复、文档改写、测试用例生成之间来回切换的维护者，这种「地址不变、协议切换」的结构比多地址并行更容易排查问题：出问题时，你知道该看的仍然是同一个入口。
同时要把两个界面分清。https://api.vanaapi.com 只处理 API 请求，密钥、余额、用量日志都在主站 https://vanaapi.com 的 dashboard 里管理。API 地址本身不返回网页，密钥也不是从 API 地址获取，而是在 dashboard 中创建。配置量因此很小，改动集中在少数几个字段上。
§ Gemini CLI 这一条路径怎么走
如果你用 Gemini CLI 调用 Gemini models，路径是确定的：走 Gemini 原生协议 /v1beta/models/...。这层协议由 Gemini CLI 自己发出，模型侧按原生格式响应。它不是 OpenAI 兼容格式，因此也不适合被搬到其他客户端里复用。认准这一点，可以省掉大量无效尝试。
在 Vana API 上，Gemini models 与 Gemini CLI 是成对出现的。价格表里的 Gemini 2.5 Flash（模型 id 为 gemini-2.5-flash）、Gemini 3.1 Pro（gemini-3.1-pro）、Gemini 3.8 Flash（gemini-3.8-flash）、Gemini 4 Argon（gemini-4-argon），都可以通过 Gemini CLI 在同一个地址上调用，区别只是选哪个模型 id。
把范围说完整：如果你想用 Cursor、Cline、Roo Code、OpenCode、Cherry Studio 或 OpenAI SDK 这一类客户端，对应的是 OpenAI 格式 /v1/chat/completions，覆盖 GPT、Grok、DeepSeek、GLM、Kimi、Qwen、MiniMax、MiMo 这些模型；GPT models 另外还响应 /v1/responses，Codex 使用的就是这条路径。Claude models 则只由官方 Claude Code 或 Claude Desktop 2.1.285 及以后版本调用，因为这些客户端自身讲 Anthropic Messages 协议，不能换成任意其他客户端、SDK、cURL 或脚本。
所以在动手前，先写下你实际使用的客户端和目标模型，再对照上面三行做一次匹配。Vana API 的价值不在于把所有模型塞进同一个客户端，而在于让每个协议都有一个稳定、统一的落点。
§ 费用判断：按量付费与充值规则
Vana API 采用预付余额模式，按真实 token 计费，没有月费。你充值多少，扣多少由实际用量决定；没有调用就没有消耗，余额可以在 dashboard 中查看。对于维护者这种用量波动大的场景，按量付费比先买一份固定周期额度更容易控制。
以 Gemini models 为例，按每百万 token 的输入 / 输出价格，Gemini 2.5 Flash 是 ¥1.50 / ¥11.50，Gemini 3.8 Flash 是 ¥7.50 / ¥33.50，Gemini 3.1 Pro 是 ¥10.00 / ¥57.00，Gemini 4 Argon 是 ¥10.50 / ¥49.50。举例来说，如果你每天用 Gemini CLI 跑一遍仓库的测试摘要和文档改写，那么把日常主力定在 Gemini 2.5 Flash、把较重的分析任务交给 Gemini 3.1 Pro 或 Gemini 4 Argon，是一种按需求分层的用法；具体花费仍以实际 token 计量为准。
注册时会赠送 ¥0.50 额度，可以直接用来跑通第一轮连通性验证。充值本身在主站完成，之后所有调用都从同一个余额里扣除。
§ 余额、用量记录与退款
每一次调用都会列入 dashboard 的用量日志。这条记录按调用列出，便于你回看某次批量处理到底消耗了多少，也能帮助判断某个模型 id 是否适合放进日常流程。密钥同样在 dashboard 创建，生成后填入 Gemini CLI 的配置即可。
退款规则也写得很直接：充值后 3 天内，未使用的余额可以退款，扣除已使用部分和支付处理机构的费用。也就是说，刚充值还没开始跑任务时，你仍然保留了调整方向的空间。
如果希望把一部分成本变成邀请收益，Vana API 提供两级推荐：被邀请者消费金额的 14% 归直接邀请人，再下一层为 5%；收益满 ¥100.00 后可以提现。这对维护开源项目、身边有同类开发者的人算是额外的一条通道，但它不改变主线的判断逻辑——先按真实用量选模型，再考虑推荐计划。
§ 按这份清单做决定
把上面的信息收成几个可以逐条确认的标准。第一，地址是否只有一个：Vana API 的请求地址是 https://api.vanaapi.com，dashboard 在 https://vanaapi.com，两者职责不混。第二，协议是否对得上：Gemini CLI 对应 Gemini 原生协议，Cursor、Cline 等客户端对应 OpenAI 格式，Claude Code 与 Claude Desktop 2.1.285 及以后版本对应 Anthropic Messages。
第三，计费是否清楚：预付余额、按真实 token 计费、无月费，价格表按每百万 token 的输入 / 输出列出。第四，出问题后是否查得到：每次调用都进入 dashboard 的用量日志，密钥也在同一处管理。第五，刚充值时是否有回旋余地：3 天内未使用余额可退款，扣除已用部分与支付处理机构费用。
把这五条放在一起看，Vana API 的形态是清楚的：一个地址，三种协议，配置量小，成本按真实用量结算。对于以 Gemini CLI 为主、同时偶尔需要其他模型的开源维护者，这套结构把「接哪一边」和「花多少」两个问题分得很干净。剩下的动作就是在 dashboard 创建密钥、充值，然后让 Gemini CLI 指向 https://api.vanaapi.com，先用赠送的 ¥0.50 额度跑通一次真实调用。