A prepaid balance before the first API request
§ Credit is money set aside for requests
Prepaid credit is a way to pay for API use before that use happens. You add funds, then requests draw against the available balance. It helps to think of the balance as a spending pool, not as a subscription or a fixed number of conversations.
Vana API bills per real token, with no monthly fee. That means your spending follows your usage rather than a recurring membership charge. You are paying for model requests, not reserving a monthly allowance that you need to use up.
If you are getting started, create a Vana API account and review the available payment options and current billing terms before adding funds.
§ A balance does not represent a fixed number of answers
A token is a small unit of text or other model-processed content. A short question and a brief answer usually involve less usage than a long conversation with a large response. Model prices also differ, so the same monetary balance can support different amounts of work.
For example, choosing Gemini 2.5 Flash for a small experiment does not tell you, by itself, how many requests your credit will cover. You also need the current price and the amount of input and output each request uses. Check any additional pricing categories that apply to your chosen model or features.
Conversation history matters, too. A tool may send earlier messages, instructions or file contents along with your latest question. The sentence you just typed may therefore be only a small part of the request being billed.
§ Read the balance alongside usage
Your balance answers one question: how much credit is available? Usage records answer another: where did the spending go? Looking at both is more useful than checking either alone.
As a simple illustration, suppose you add $10 and later see $9.70 remaining. That suggests a $0.30 reduction, but it does not explain which requests caused it. Those numbers are only an example, not a statement about Vana API prices or minimum payments.
- Before a test: note the available balance and the selected model.
- During the test: keep the workload small and avoid running several tools at once.
- After the test: compare the usage information with the change in balance.
Vana API provides one endpoint at https://api.vanaapi.com, with OpenAI-compatible access plus Anthropic Messages and Gemini native protocols. It works with tools such as Claude Code, Codex and Gemini CLI. Regardless of the client you choose, check which account and API key it is using when investigating charges.
§ A refund is separate from a remaining balance
Unused credit and a refundable payment are not automatically the same thing. A displayed balance tells you what is available for usage; it does not, on its own, establish whether that amount can be returned to your payment method.
Before paying, check the applicable refund terms. Useful details include eligibility, any request deadline, how partially used payments are treated, and whether fees or payment-method restrictions apply. Also check whether purchased credit expires. Do not assume that a refund is automatic, immediate or available for every payment.
If you need to ask about a refund, use the available support channel and provide the account identifier, payment date, amount and transaction reference. Never send your API key or full payment-card details. If a charge looks unexpected, identify the relevant request or usage period so it can be reviewed separately from the refund question.
§ Keep the first deposit deliberate
A practical starting point is a small test budget, within the payment options available. Run a representative task, review its cost and decide whether to add more credit. Check what happens when funds run low, including whether your client retries requests and whether any automatic funding option is enabled.
The basic distinction is simple: credit funds future usage, usage reduces the balance, and refunds follow the applicable payment policy. Keeping those three ideas separate makes prepaid API billing easier to understand.