A short answer with a longer token bill
A model returns a three-sentence answer, but the usage report shows far more output tokens than those sentences contain. This can be normal. Some models generate reasoning tokens before or alongside the answer they show you. Those tokens can consume time and budget without appearing in the final text.
The useful comparison is not between a model that thinks and one that does not. It is between different parts of the request: what you send, what the model generates internally, and what your application receives.
§ Input beside reasoning beside the answer
Input tokens: These represent material supplied to the model, including instructions, conversation history, and tool results. A long document can create a large input count even when the requested answer is short.
Reasoning tokens: On models that support this mechanism, these are generated tokens used for internal processing. They may support planning, checking constraints, or working through a problem. They are not normally delivered as the complete internal reasoning text.
Visible output tokens: These make up the answer or other returned content, such as a tool call. Asking for a brief answer limits the requested presentation; it does not necessarily impose a small internal reasoning budget.
§ The same short answer, two different workloads
A straightforward extraction: Asking for the date printed on an invoice mainly requires locating information. Extra reasoning may add little value. A concise response and a modest processing budget are often sensible starting points.
A constrained decision: Asking which invoice can be paid under several contract rules may require reconciling dates, exceptions, and missing evidence. The final answer could still be one sentence, while the work behind it is considerably larger.
Answer length is therefore a poor proxy for total generated tokens. Conversely, a high reasoning-token count is not proof that an answer is correct. Validate important results against evidence or tests.
§ Usage reported beside text received
What you receive: Your application may see only the final answer, tool calls, and any supported reasoning summary. A summary is not a complete transcript of internal reasoning.
What usage reports: Depending on the model and protocol, reasoning tokens may appear as a detail within output usage, under a separate field, or without a separate breakdown. Do not add a reasoning subtotal to an output total unless the documentation says they are separate; that can double-count usage.
Vana API provides one endpoint at https://api.vanaapi.com, supporting OpenAI-compatible requests as well as Anthropic Messages and Gemini native protocols. That simplifies access, but it does not make every model's usage fields or reasoning controls identical. Inspect the response format used by your application.
§ A shorter response beside a smaller budget
Response length: Instructions such as “answer in two sentences” shape the visible answer. They are useful for interfaces, but they are not reliable cost controls by themselves.
Generation controls: Where supported, reasoning-effort settings or reasoning budgets influence internal processing. Token limits can also constrain generation, but their scope varies. Some limits cover reasoning and visible output together, leaving less room for the answer when internal processing uses much of the allowance.
Check the selected model's supported parameters rather than copying settings across models. An OpenAI-compatible request shape does not guarantee identical parameter behavior everywhere.
§ Lower latency beside better task results
For routine work: Start with conservative reasoning settings where available. Measure completion time, token usage, and whether the answer satisfies the task.
For difficult work: Increase the supported reasoning allowance only when evaluations show a benefit. More reasoning can increase latency and cost, but it does not guarantee better results.
Vana API bills per real token with no monthly fee. Check the selected model's pricing and how its reported usage maps to billable tokens before estimating costs from visible text alone. Create an account to compare a few representative requests, then keep the smallest budget that reliably meets your quality requirements.