Two price rows beside the same token count

A per-token price table looks simple until two rows point in different directions. One has cheaper input; the other has cheaper output. A third column mentions caching. Before choosing a row, put the same workload beside each price and keep the billing categories separate.

Vana API bills per real token with no monthly fee. That makes the useful comparison the cost of the tokens a task actually consumes, rather than the lowest number visible in the table.

§ The displayed rate beside the billing unit

On the price-table side: a number needs a denominator. A rate of $2 per million tokens is not $2 per request, and it is not $2 per thousand tokens. Check the currency and unit before comparing rows.

On the workload side: count tokens in the same unit. At $2 per million input tokens, 10,000 input tokens cost $0.02. The calculation is token count divided by 1,000,000, multiplied by the listed rate. Use that calculation separately for every applicable category.

§ Input price beside output price

On the input side: the request can include more than the latest message. System instructions, conversation history, tool definitions, and supplied documents can all contribute. A short question attached to a long conversation is not necessarily a small input.

On the output side: the model's generated response has its own rate. A brief classification and a long explanation can have similar inputs but very different output costs. Where a model has additional billable token categories, check their definitions rather than assuming visible answer text explains the entire charge.

For a basic comparison without caching or other categories, use: request cost = input tokens × input rate + output tokens × output rate, after converting both rates to a per-token basis.

§ Two hypothetical rows beside one request

The following rates are invented arithmetic examples, not current Vana API prices. Give both rows the same workload: 10,000 input tokens and 2,000 output tokens.

• Row A: $2 per million input tokens and $8 per million output tokens. Input costs $0.020; output costs $0.016. Total: $0.036.
• Row B: $1 per million input tokens and $12 per million output tokens. Input costs $0.010; output costs $0.024. Total: $0.034.

Row B is slightly cheaper for this request, despite its higher output rate. Now hold input at 10,000 tokens and increase output to 5,000 tokens. Row A costs $0.060; Row B costs $0.070. The cheaper choice changes with the input-to-output ratio.

§ A cache rate beside a cache assumption

On the table side: a cached-input rate describes a particular billing category, not a blanket discount on repeated requests. Cache availability, eligibility, and any separate write or read charges need to be understood for the selected model.

On the request side: repeated text is not proof of a cache hit. Inspect the usage details available for the request. If cached tokens are reported separately, apply the appropriate rate without also counting those tokens as ordinary input. Until you have evidence of cache usage, avoid building a budget that assumes every repeated prompt receives a discount.

§ An estimated request beside a working session

On the estimate side: identical token counts make price rows easy to compare. In practice, different models may tokenize the same text differently or produce different answer lengths. A controlled calculation is a starting point, not a guarantee.

On the session side: retries, tool calls, and follow-up turns can create additional requests. Vana API works with Claude Code, Codex, Gemini CLI, and OpenAI SDKs, but a client session is not necessarily one billable request. Compare the total cost of completing the same task, including unsuccessful attempts.

Create a Vana API account and begin with a small, representative task. Record usage and cost, then compare those observations with the table. The reliable reading is the one that connects each listed rate to a measured category of tokens.