Input vs. Output vs. Reasoning Tokens Explained

Input tokens

Input tokens represent the content supplied for one request. That can include system and developer instructions, the latest user message, earlier conversation turns, retrieved documents, tool definitions, tool results, and encoded images or audio when the model accepts them.

“Input” describes the direction of the data, not who wrote it. A user may type one short sentence while the application quietly sends a much larger request around it.

Cached input is still input. Caching can change its price or the way it appears in a usage report, but it does not turn the content into output or remove it from the model’s working context.

Output tokens

Output tokens are generated during the response. Visible prose and code are output, but so are generated structures such as tool calls. Depending on the provider’s terminology, the reported output total may also include internal reasoning and other non-visible generated tokens.

This is why the text on screen is not a dependable token counter. The response may show 180 tokens of prose while the usage record reports a much larger generated total.

Reasoning tokens

Reasoning tokens, sometimes called thinking tokens, are generated internally while a reasoning model plans, checks, or works through a task. They are not extra prompt content, and they are not necessarily shown to you.

A provider may hide the reasoning, omit it, or return a summary. A summary is a presentation of the process, not proof that you received every internal reasoning token. Current OpenAI, Anthropic, and Google documentation all meter the full internal work even when the full text is not returned.

Not every model or API exposes a reasoning-token count. Some models generate an answer without a separately reported reasoning phase. Others support controls that influence reasoning effort, but those controls do not promise an exact amount of thinking unless the provider explicitly says so.

The actual distinction

The three labels answer different questions:

Token type	Defining question	Typical contents	Usually visible?	Accounting relationship
Input	What did this request send to the model?	Instructions, messages, context, tools, files	Mostly, though applications can add content	A top-level request category; cached input may be a priced subset
Output	What did the model generate?	Answer text, code, tool calls, and sometimes internal generated work	Partly	Can be an inclusive total or an answer-only field, depending on the API
Reasoning	What internal generated work helped produce the answer?	Planning, intermediate work, checks	Often hidden or summarized	Commonly a subset of generated output for billing, but sometimes reported beside output

Input and generated output are opposite sides of a request. Reasoning is a kind of generated activity. It therefore does not form a universal third bucket alongside input and output.

This distinction matters when you compare provider dashboards. OpenAI documents reasoning as a detail within an inclusive output count. Anthropic likewise describes thinking tokens as part of its authoritative output total. Google exposes candidate output and thought counts separately and says response pricing combines them. The field names differ, but all three treat reasoning as generated work.

A worked usage example

Consider this simplified request:

The instructions, user message, history, and attached context total 1,200 input tokens.
The model generates 620 reasoning tokens.
It then generates a 180-token visible answer.

One API could report:

input_tokens: 1200
output_tokens: 800
output_details.reasoning_tokens: 620

Here, output_tokens is inclusive. Do not add the 620 again. The 180-token answer is the non-reasoning portion of the 800 generated tokens.

Another API could report:

input_tokens: 1200
output_tokens: 180
thought_tokens: 620
total_tokens: 2000

Here, answer output and thought tokens are separate fields. You must include both when evaluating generated usage. The two reports describe the same simplified flow:

1,200 input + 620 reasoning + 180 visible answer = 2,000 total tokens

If all generated tokens use the provider’s output rate, the simplified cost calculation is:

(1,200 × input rate) + (800 × output rate)

Real bills can add separate rates for cached input, cache writes, batches, tools, or other features. Use the API’s usage schema and pricing rules rather than assuming every field is additive.

When each token type matters

Input tokens matter when requests carry a lot of context. Long histories, documents, tool definitions, and repeated instructions can dominate usage even when the latest user message is short. Input counts also tell you how much room remains in the context window.

Output tokens matter when responses are long or generated repeatedly. Generation happens step by step, so output commonly has different performance and pricing characteristics from input. A workflow that classifies a document into one label has a different usage shape from one that drafts a report.

Reasoning tokens matter when the task requires internal work. A short final answer can follow a large reasoning trace. That can increase cost, delay the visible answer, and consume generated-token capacity without making the displayed response longer.

For reasoning models, an output limit may cover both internal reasoning and the visible response. If reasoning consumes the allowance first, the model can return a short or incomplete answer. Check the endpoint’s documentation before treating an output limit as a promised answer length.

What people confuse

Reasoning tokens are not extra input

The model creates reasoning tokens during generation. They may become input on a later turn if the application sends preserved thinking content back, but that is a new request with a new measurement boundary.

Reasoning tokens are not always separate from output tokens

If a usage object says that reasoning is a detail within output, adding the two fields produces a double count. If it reports thoughts beside answer output, ignoring the thought field produces an undercount. Read the schema before doing arithmetic.

Output tokens are not always visible words

Tokens are not the same as words, and generated usage is not limited to displayed prose. Tool-call arguments, hidden reasoning, and provider-managed formatting can all widen the gap between what you see and what the meter records.

A short answer is not necessarily a cheap answer

Visible length is only one part of usage. A request can have a large input, substantial internal reasoning, or both. The response’s usage record is a better basis for measurement than the size of the rendered answer.

Where to go next

Read What Are Input Tokens? to understand what applications place in a request. Read What Are Output Tokens? for generated responses and limits. Read What Are Reasoning Tokens? for the provider-dependent thinking layer.