Shift note: output tokens are driving the bill

The reply is also a metered resource

A model request has two sides: the material you send and the material the model generates. Both can be billable, but they do not necessarily have the same price. On many models, output tokens cost more per token than input tokens. That makes the reply an easy place for spending to grow unnoticed.

Output does not dominate every workload. Large documents, long conversation histories, caching, and model-specific pricing can change the balance. Still, if your application produces detailed answers repeatedly, the output line deserves an early check when the bill rises.

Tokens measure text, not requests

A token is a small unit used to represent text. It might be a word, part of a word, punctuation, or another character sequence. The exact breakdown depends on the model and the language. A request is therefore not a fixed-price unit: two successful requests can generate very different charges.

Input tokens include instructions, the user's message, and any supplied context. Output tokens cover generated content under the service's billing rules. Depending on the model, billable generation can also include reasoning tokens that are not shown as ordinary reply text. Check the usage fields and pricing documentation rather than counting visible words alone.

A longer answer can outweigh a shorter prompt

Imagine a small classification task. You send a short description and need one category back. If the model instead writes an explanation, a summary, and suggested next steps, you are paying for work the application never needed.

The same pattern appears in coding assistants, support tools, and automated reports. A helpful-sounding instruction such as “be comprehensive” can turn a compact result into several screens of text. Across repeated calls, that extra generation accumulates.

For standard per-token billing, the basic calculation is input tokens multiplied by the input rate, plus output tokens multiplied by the output rate. If rates are quoted per million tokens, divide each token count by one million first. Account separately for any caching categories, tool charges, or other fees the service lists.

Set the answer shape before raising the limit

The first control is not a cheaper model. It is a clearer definition of the result you actually need.

• Ask for a specific format, such as three sentences, five bullet points, or a JSON object containing only required fields.
• Remove default requests for introductions, repeated context, and closing summaries when the application does not use them.
• Set an appropriate generation limit using the parameter supported by your chosen model and endpoint.
• Test what happens when the limit is reached, because a truncated response may be unusable and trigger another paid request.
• Offer expanded explanations on demand instead of generating them for every user automatically.

A generation limit is a ceiling, not a promise of a complete answer or a target the model must reach. For models with reasoning budgets, check how those budgets interact with the limit.

Read usage records beside the application result

Log the model, input usage, output usage, completion status, and whether the result passed your application's checks. Include retries and follow-up calls. One inexpensive-looking response can belong to a costly workflow if the application keeps asking for repairs.

Compare cost per usable result rather than response length alone. A shorter answer that omits necessary information is not a saving if it creates another request. Likewise, evaluate models such as Claude Haiku 4.5 or Gemini 2.5 Flash on your own representative tasks, using current rates rather than assuming a price from the name.

Keep the billing check in the relay workflow

If you want to evaluate multiple model families through one pay-as-you-go relay desk, Relay365 is a practical option to consider. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDK clients. Its API base is https://api.api365relay.com; OpenAI clients add /v1. Verify supported features, current rates, and usage reporting for your selected model.

Create a Relay365 account when you are ready to test a small, representative workload. Start with measured output limits and inspect the usage before scaling. The useful shift note is simple: pay for the answer your application needs, not the extra paragraphs nobody reads.