Notes on the tokens behind a short answer

You ask an AI model a short question and receive a short answer. Then you check the usage report and find more output tokens than the answer seems to contain. In some models, the difference comes from reasoning tokens: tokens used during an internal working process before, or alongside, the answer you can read.

Understanding this distinction helps explain why a brief response can take time, cost more than expected, or stop before it reaches a useful conclusion.

§ Start with ordinary tokens

A token is a small unit of text or other model input and output. In English, it might be a word, part of a word, or punctuation. Tokens are not the same as words, so counting words gives only a rough estimate of usage.

For a simple text request, input tokens cover material sent to the model, such as your instructions, conversation history, and documents. Visible output tokens cover the answer it returns. Reasoning-capable models may also generate tokens that are not included in that visible answer.

§ Reasoning tokens are working space

A useful mental picture is scratch paper. Before giving an answer, a model may use an internal process to work through a calculation, consider constraints, or check a proposed solution. Reasoning tokens represent token-based work in that process.

The analogy has limits. These tokens are not a readable transcript of a human mind, and they are not a guarantee that the answer is correct. Not every kind of internal computation is counted as a reasoning token, either. The term refers to a particular part of a model's generation and accounting, not everything happening inside it.

Depending on the model and API, you may receive a reasoning summary or usage statistics. A summary is not necessarily the underlying internal sequence. Asking the model to explain its answer does not reveal that sequence reliably.

§ A short answer can have a larger bill

Imagine a request that uses 600 input tokens. The model then uses 900 reasoning tokens and produces 150 visible answer tokens. Where reasoning is counted within output usage, the output total would be 1,050 tokens, not 150.

This is an illustration, not a fixed ratio or a pricing quote. Models differ in how they report and charge for reasoning. Some usage responses show a separate reasoning breakdown within the output total. Do not add that breakdown to the total again.

Vana API bills per real token with no monthly fee. When estimating a request's cost, check the selected model's rates and reported usage rather than judging by the length of the answer alone.

§ More reasoning is not always more useful

Additional reasoning can help with tasks that involve several dependent steps, such as debugging a subtle error or comparing a plan against multiple requirements. It may offer little benefit for extracting a date or rewriting a sentence.

More reasoning can also increase response time. A model may be working before the first visible text arrives, so a streaming response does not necessarily begin immediately.

Some models offer an effort setting, a reasoning budget, or related controls. Their names and behavior differ. A request for a concise answer controls presentation; it does not necessarily reduce internal reasoning.

§ Check limits before changing prompts

For some APIs and models, a generation limit covers both reasoning and visible output. If internal work consumes most of that allowance, little room may remain for the answer. Other models handle limits differently, so check the relevant documentation.

• Start with the model's default reasoning setting.
• Test with a few representative tasks.
• Compare correctness, response time, and total token usage.
• Increase effort only when the improvement justifies the added cost.

Vana API offers an OpenAI-compatible endpoint at https://api.vanaapi.com and also supports Anthropic Messages and Gemini native protocols. That provides familiar integration options, but reasoning controls still depend on the selected model and protocol. Create an account when you are ready to test a small set of real requests.

The useful habit is simple: evaluate the answer you receive, but measure the full token usage needed to produce it.