Notes beside a per-token price table
A per-token price table can look simple until you try to estimate a bill. One model has several prices, the units are easy to overlook, and a short question can produce a surprisingly long answer. The useful starting point is this: a listed price is a rate for a particular kind of usage, not the cost of one request.
Vana API bills per real token with no monthly fee. Reading its price table means identifying which tokens a request uses, finding the corresponding rates, and keeping the units consistent.
§ Start with the unit above the price
A token is a small piece of content that a model processes or generates. In text, it might be a word, part of a word, punctuation, or whitespace. A token is not reliably equal to one word or one character. Different models can also split the same text differently.
Before comparing any prices, read the table heading. A rate might be quoted per token, per thousand tokens, or per million tokens. The number and its unit belong together. A price of $2 per million tokens does not mean that each request costs $2.
Word counts can help you make a rough estimate, but the usage reported for a request is a better basis for checking actual token consumption.
§ Read input and output as separate charges
Input tokens are the content sent to the model. That can include your question, system instructions, conversation history, documents, and tool results. The latest message is often only part of the input.
Output tokens are the content the model generates. Their rate may differ from the input rate, so do not multiply the combined token count by just one price.
This matters in ordinary use. Asking for a brief label and asking for a detailed report may use similar input, but the report can generate far more output. Likewise, a short follow-up question may still carry a long conversation history into the next request.
§ Work through one small calculation
Imagine a table with these hypothetical rates. They are examples for arithmetic, not current Vana API prices:
- Input: $2 per million tokens.
- Output: $8 per million tokens.
- Request usage: 3,000 input tokens and 500 output tokens.
The input cost is 3,000 divided by 1,000,000, multiplied by $2: $0.006. The output cost is 500 divided by 1,000,000, multiplied by $8: $0.004. Together, the request costs $0.01 under these example rates.
The general rule is straightforward: divide each token count by the table’s unit, multiply by its matching rate, then add the charges. For repeated work, multiply a representative request cost by the expected number of requests. Treat that result as an estimate, since request lengths vary.
§ Pause at cache columns and footnotes
Some tables distinguish ordinary input from cache reads or cache writes. Caching can let supported requests reuse previously processed content, but repeated text does not automatically qualify for a discounted rate.
Read the conditions attached to each cache column. If usage separates cached and uncached input, apply the appropriate rate to each category rather than charging all input at both rates. If cache writes have a separate charge, include it according to the published rules.
Also check for notes about context length, special processing, or other billable categories. Do not assume every model has the same pricing structure just because the rows share a table.
§ Check a small request before estimating a month
Vana API provides an OpenAI-compatible endpoint at https://api.vanaapi.com and also supports the Anthropic Messages and Gemini native protocols. Whichever interface you use, match the selected model’s pricing row to the usage categories returned by your requests.
Create a Vana API account and start with a small, representative request. Inspect the reported usage, calculate its cost against the current table, and repeat with a longer example. A few realistic measurements usually make a better budget than guessing from the lowest number in a pricing row.