Gemini CLI pay-as-you-go pricing on Vana API: $0.2083 per million

Agents at the terminalEN2026-11-05

§ Example workflow: one change, one address

This is an example workflow for moving Gemini CLI onto Vana API without touching the rest of a project. The example starts and finishes with a single address, https://api.vanaapi.com, which answers API requests. Vana API serves three protocols from that one address, and Gemini models travel over the Gemini native protocol, at /v1beta/models/.... Gemini models on Vana API are not OpenAI-compatible, so the OpenAI format is not part of this example at all. The scope of the workflow is deliberately narrow: change where Gemini CLI sends its requests, and leave everything else in place.

In this example, the rest of the project means the application code, the prompt files, the repository, and the scripts that already work. None of them are edited. The change sits inside Gemini CLI configuration itself, where you set the base address and supply the key. Because Gemini CLI already speaks the Gemini native protocol, pointing it at Vana API is a configuration step rather than a rewrite. The rest of the project keeps talking to Gemini CLI exactly as before, and Gemini CLI keeps sending the same request shape it always sent.

The example is also honest about boundaries. One address, three protocols, minimal setup is the whole idea, but the protocol still matters. In this example, Gemini CLI is the client, the Gemini native protocol is the protocol, and Vana API is the endpoint. That pairing is the only pairing used here, which is what keeps the migration small and predictable.

§ Example: create a key and check the balance

Keys are created in the dashboard, and the dashboard lives on the main site, https://vanaapi.com. The API address at https://api.vanaapi.com only answers API requests; it is not where you manage keys, balances, or logs. So the first step of this example is a short visit to the dashboard, where you create a key and look at the prepaid balance you intend to use.

Billing on Vana API is pay-as-you-go: you hold a prepaid balance, and calls are charged per real token, with no monthly fee. New accounts receive a gift on sign-up of $0.10 of credit, which is enough to make a first test request without deciding anything larger. In this example, say you top up once and then run this workflow every day. The balance simply decreases as real tokens are consumed, and every call is listed in the usage log in the dashboard, so the cost of the workflow is visible rather than inferred.

Open the dashboard at https://vanaapi.com and create a key.
Check the prepaid balance available to that key.
Keep the key private and treat it as the only credential you need to add.
Return to the project only to change Gemini CLI configuration.

Nothing else in the example requires an account, an extra tool, or a second endpoint. One key and one address are enough, and that is the practical meaning of minimal setup here.

§ Example: point Gemini CLI at the Vana API address

Now open the Gemini CLI configuration for the project. In this example, you set the base address to https://api.vanaapi.com and paste in the key you created in the dashboard. Gemini CLI then continues to use its own native request format, which Vana API accepts over /v1beta/models/.... No adapter layer is introduced, and no project file is rewritten to imitate a different protocol.

It is worth being precise about why this works with so little friction. Gemini CLI is already a Gemini-native client, so the protocol on the wire does not change when the destination changes. The OpenAI format at /v1/chat/completions, and the /v1/responses path used by GPT models, exist on the same Vana API address for other clients, but this example does not use them and does not ask Gemini CLI to speak them. The Gemini native protocol and Gemini CLI stay together, exactly as required.

Because the change is confined to configuration, the example remains reversible. If you need to undo it, you point Gemini CLI back at its previous base address. There is no code migration to reverse, no dependency to remove, and no data to move. That is the practical payoff of keeping the switch inside the client instead of the project.

§ Example: pick a Gemini model and read the pricing

Gemini models on Vana API are available only from Gemini CLI, over the Gemini native protocol. Within that constraint, you can choose between several Gemini models, and the price list is straightforward. Prices below are per million tokens, written as input and output, and they are the exact Vana API figures for Gemini models:

Gemini 2.5 Flash (model id gemini-2.5-flash): Vana API $0.2083 / $1.60
Gemini 3.1 Pro (model id gemini-3.1-pro): Vana API $1.39 / $7.92
Gemini 3.8 Flash (model id gemini-3.8-flash): Vana API $1.04 / $4.65
Gemini 4 Argon (model id gemini-4-argon): Vana API $1.46 / $6.88

In this example, Gemini 2.5 Flash is the default choice, because its input price of $0.2083 per million tokens is the lowest of the four Gemini entries listed here. If a task in your project needs more reasoning depth, you can switch the model id inside Gemini CLI configuration and leave the address and key untouched. The model selection is one line, and the rest of the workflow does not change.

The same simplicity applies if you use Gemini CLI for more than one project. Each project keeps its own Gemini CLI configuration, while the key and the balance live in the Vana API dashboard. One account, one address, and per-token pricing that you can read before you commit to anything.

§ Example: verify the first call in the usage log

Run one short test prompt in Gemini CLI and then open the usage log in the dashboard. The example here is a request with 1,000 input tokens and 500 output tokens on Gemini 2.5 Flash. Starting from the listed prices of $0.2083 per million input tokens and $1.60 per million output tokens, the input cost is 1,000 divided by one million times $0.2083, which is $0.0002083, and the output cost is 500 divided by one million times $1.60, which is $0.0008. Added together, that example request costs $0.0010083.

That figure is a worked example, not a promise about your own traffic. Real requests vary in length, and the usage log shows what each call actually consumed. The point of checking is simple: you can confirm that the key works, that the model id resolves, and that the balance moves by the amount you expect, all from the same dashboard where you created the key.

Once the test looks right, the workflow is finished. Gemini CLI sends requests to https://api.vanaapi.com, the Gemini native protocol carries them, and Vana API bills per real token against your prepaid balance. The project code was never opened for editing.

§ Example: plans, refunds, and referral credit

The monthly plans on Vana API are limited to Claude models only or GPT models only, so they are not part of this Gemini CLI example. For Gemini usage in this workflow, the prepaid pay-as-you-go balance is the route, with no monthly fee attached to it. That keeps the commitment proportional: you fund what you plan to use, and the usage log records the rest.

If you top up and change your mind, unused balance can be refunded within 3 days of the top-up, minus what was used and the payment processor's fee. The window is short, so the example is to check the usage log promptly after any top-up rather than assuming the balance is static.

There is also a referral program on Vana API: you receive 14% of what people you invite pay, and 5% one level further, and earnings can be withdrawn from $13.89. That is separate from the Gemini CLI setup, and it does not change the workflow described above.

Taken end to end, this example comes down to four moves: create a key in the dashboard, add credit, set one base address in Gemini CLI, and check the usage log. One address, three protocols, minimal setup, and per-token pricing that is easy to read before you start and easy to verify afterwards.