TraptureIQ Guides Token economics
The tokens nobody reads are the ones you pay most for
Token pricing looks like arithmetic: rate times volume. Then a reasoning model quietly produces 3,000 invisible tokens per turn at output rates, a cheaper model turns out to cost more than the expensive one, and the arithmetic stops matching the invoice. The mechanics are knowable. They are just not on the pricing page.
Every model provider publishes a price per million tokens, and every team plans against it. Then the first real invoice arrives and it is two or three times the estimate. Nothing was mispriced. The estimate simply counted the tokens that a human can see.
Where the tokens in a real run actually went
Those are measured figures from a four-call run, not an illustration: 3,042 thinking tokens out of 5,044 total. The response text a user actually read was the smallest of the three segments.
This is the part of token economics that breaks intuition. You can read every prompt and every response in a conversation, add up what you see, and still be wrong about the bill by a factor of two, because the largest line item never appears in the transcript.
Four asymmetries that decide your bill
1. Output costs more than input. Usually several times more. Which means the cheapest optimisation available is almost never a shorter prompt. It is a shorter answer. "Reply in at most three sentences" moves money in a way that trimming a system prompt does not.
2. Thinking bills as output. A reasoning model that thinks for 3,000 tokens per turn is a different product decision than one that thinks for 300, and the difference does not show up anywhere in the conversation. If you enable extended reasoning globally because it improved one hard case, you have repriced every easy case too.
3. Context accumulates. Conversation state is resent as input each turn, so a long session costs more per turn as it goes, for identical user input. Cost per call hides this completely; cost per session shows it immediately.
4. Retries are invisible and paid. A retried call is a second billed call. In a trace it looks like two model calls, which is easy to misread as the agent legitimately asking twice.
Why model comparison by price table goes wrong
The standard way teams choose a model is to put the published rates side by side and pick the cheaper one. This is reliably wrong for agents, because the rate is one of four terms and the other three are properties of the model's behaviour rather than its price.
The number that matters is cost per completed task: what it costs to get an outcome you would ship, including the reasoning, the retries and the extra context a weaker model needs to reach the same answer. A model at half the rate that reasons three times as long, or fails a case once in five and gets retried, is more expensive in the only unit that pays your bill.
The measurement you actually need
Run the same eval set against both models and compare total spend at equal quality, not tokens, not rate, and not one hand-picked prompt. This is the point where cost work and evaluation stop being separate activities: an eval run is itself a series of billed calls, so the quality comparison and the cost comparison are the same experiment.
Making it visible without instrumenting anything
For Google ADK agents, the token data is already being emitted. ADK writes token usage onto its OpenTelemetry spans as a matter of course, which means the question is not "how do I instrument this" but "where do those spans go".
export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT="https://api.traptureiq.com/v1/traces" export OTEL_EXPORTER_OTLP_LOGS_ENDPOINT="https://api.traptureiq.com/v1/logs" export OTEL_EXPORTER_OTLP_HEADERS="x-api-key=tiq_..."
One thing to check on day one, because it fails silently: a model with no row in your pricing catalogue prices at zero rather than erroring. We found exactly this with non-Gemini models: token counts arrived correctly, the dashboard rendered perfectly, and every cost figure was 0.00. A zero in a cost column should always be treated as a missing price until proven otherwise.
What to do with the numbers
- Cap the reasoning you are not using. Enable extended thinking per task, not globally. The easy cases are the majority and they do not need it.
- Constrain output length explicitly. The most expensive tokens are the ones you did not ask for.
- Watch cost per session, not per call. Per-call cost is flat and reassuring while per-session cost climbs with conversation length.
- Separate development from production spend. Load tests and local experiments inflate the number you report to a budget holder unless environment is declared, and it cannot be auto-detected. See ADK agent cost for why.
Questions people actually ask
What are thinking tokens and do I pay for them?
Thinking or reasoning tokens are produced by the model while working out an answer and are not returned in the response text. They are billed at output rates, which are typically several times the input rate. They can easily be the largest single line in an agent bill despite being invisible in the transcript.
Why did switching to a cheaper model increase my bill?
Published rates are per million tokens; your bill is rate times tokens. A cheaper model that reasons for longer, retries more often, or needs more few-shot context can consume enough extra tokens to overwhelm a lower rate. Compare measured cost per completed task, not the price table.
Why does cost per turn grow during a long conversation?
Most agent frameworks resend prior conversation state as input on each turn, so input tokens grow with conversation length. Turn twenty is more expensive than turn two for identical user input. Measure cost per session, not per call, or this is invisible.
How can I see token usage for an ADK agent without changing code?
ADK emits OpenTelemetry spans that already carry token usage per model call. Pointing the standard OTLP exporter at a collector that reads those spans gives token and cost data with no change to agent.py.