Why a token count is not the same as an API bill

A tokenizer answers “how does this content segment?” An invoice answers “what did this provider process under this API contract?” Those are connected measurements, not interchangeable ones.

Start by declaring the measurement boundary

TokenCalculator.dev reports a preflight input measurement for pasted text, locally extracted file text, and supported image formulas. It cannot observe server-injected instructions, provider file conversion, tool-call serialization, internal routing, or the output a model has not generated yet. The result therefore describes client-visible content under a disclosed method.

Input overhead that raw text does not contain

• Message framing: roles, separators, and conversation templates.
• Tools and schemas: function names, descriptions, JSON Schema, and tool results.
• Hosted file processing: extraction, OCR, chunking, citations, or retrieval wrappers.
• Images: provider resizing and visual-token budgets.
• System and product instructions: additional text applied outside the visible prompt.

One token can have more than one rate

Providers can price uncached input, cached input, output, batch processing, and long-context tiers differently. Some reasoning models expose billed or usage tokens beyond visible output. A correct input count multiplied by the wrong price tier still produces a wrong budget.

Use a two-stage reconciliation loop

1. Preflight: measure locally before sending data, verify context fit, and compare models without uploading the content.
2. Postflight: record provider usage metadata and the applicable price schedule.
3. Delta: compute provider input usage minus local content input. Track that delta by API, model, tool set, and modality.

This turns disagreement into an engineering signal instead of hiding it behind an unjustified “exact” badge. Read the calculation methodology or start with the multimodal calculator.