Does non-English text cost more to process?

Usually yes. Tokenizer vocabularies are dominated by English text, so the same sentence in another language often costs more tokens — commonly two to three times for languages written in non-Latin scripts, and sometimes more where each character becomes its own token. Because you are billed per token, an identical feature can carry a materially higher unit cost in some markets than others. Measure it per language rather than assuming parity.

Is JSON more expensive than other formats for prompts?

For repeated tabular data, usually. JSON bills you for every brace, quote, colon and — critically — every key name on every record, so a thousand-row array pays for the field names a thousand times. Re-serialising the same rows as CSV or TSV with the field names declared once commonly removes a large share of the tokens with no loss of meaning. JSON remains the right choice for model output when you need reliable schema validation.

How do I count tokens before I ship a prompt?

Use the tokenizer that matches the model you are calling, or the provider's token-counting endpoint, and run your real request shapes through it in a test. Count tokens per request shape rather than per application, because a single bloated shape usually drives most of the spend. Character counts and word counts are poor proxies — shortening text can increase the token count if the shorter form falls outside the tokenizer vocabulary.

FinOps for AI · Token economics · September 2026

Tokenization: Why the Same Meaning Costs Different Amounts

Q: What is a token in AI billing?

A token is a subword fragment produced by the model's tokenizer — the unit providers meter and price. Common English words are usually a single token, while rare words, identifiers and non-Latin scripts are split into several. A useful rule of thumb for English prose is roughly four characters per token, but it is only a rule of thumb: the same meaning can cost very different numbers of tokens depending on how it is written and serialised.

By the CloudFinOpsKit team. 10 min read.

Your AI bill is denominated in tokens. You write in words. The exchange rate between the two is not fixed — and unlike an actual exchange rate, you control it. Two prompts that say exactly the same thing, to exactly the same model, can differ by a factor of three in what they cost, purely because of how the text was written and serialised. Most teams never look, because token count feels like a property of the model rather than a property of their code. It is a property of their code.

This is the layer beneath every other AI cost lever. Right-sizing the model changes the price per token. Caching changes how often you pay for a token. Tokenization changes how many tokens your meaning is worth in the first place — and it applies to every call you make, on every model, regardless of which provider you use.

What a token actually is

Models do not read characters and they do not read words. They read subword fragments drawn from a fixed vocabulary that was learned during training, using a scheme such as byte-pair encoding. The tokenizer's job is to chop your text into the longest vocabulary entries it can find.

That produces a simple but consequential rule: text the tokenizer has seen a lot of is cheap; text it has not is expensive.

A common English word — management, invoice, the — is typically one token.
An unusual word, a technical term, or a misspelling gets split into several.
A random identifier such as a UUID or a content hash has no vocabulary entries at all, so it shatters into many — often one token per two or three characters.

The familiar rule of thumb — roughly four characters per token for English prose — holds for prose and quietly stops holding for everything else. And "everything else" is most of what production systems actually send: structured records, identifiers, schemas, retrieved documents, logs.

The single most useful mental shift: stop thinking of the prompt as text you wrote and start thinking of it as a payload you serialised. Payload engineering is a discipline your team already has. It just has not been pointed at the token meter yet.

The four multipliers

In practice, four things inflate the token count of a given piece of meaning. They compound, and they are addressed in very different ways.

1. Language — the multiplier you cannot negotiate

Tokenizer vocabularies are built predominantly from English-heavy corpora. The consequence is that the same sentence, carrying the same meaning, costs more tokens in other languages — commonly two to three times as much for languages written in non-Latin scripts, and worse in cases where a character maps to its own token or is split across several.

This has a direct FinOps consequence that rarely reaches the cost report: an identical feature can have a materially different unit cost per market. If you serve the same AI assistant to customers in several languages and you charge them the same, your margin varies by geography for a reason that has nothing to do with the geography. If you are building a unit-economics model, segment cost per successful output by language before you conclude anything about which market is profitable.

You cannot negotiate the multiplier away, but you can stop being surprised by it — and you can be deliberate about which parts of the pipeline run in which language. Retrieval and reasoning over an English corpus with a final translation step sometimes costs less than doing everything in the target language, and sometimes costs more. It is measurable, so measure it.

2. Serialisation format — the multiplier nobody audits

This is the one with the fastest payback, because it is pure engineering with no quality trade-off.

When you send structured data to a model, you are billed for the syntax, not just the values. Every brace, bracket, quotation mark, colon and comma is tokens. Pretty-printed indentation is tokens. And the expensive one: in a JSON array of records, every field name is repeated on every record and billed every time.

Send a thousand rows with eight fields as a JSON array and you have paid for eight thousand field-name repetitions to communicate eight field names. The same rows as CSV or TSV declare the headers once. For repeated tabular payloads this routinely removes a large fraction of the input tokens while losing nothing a model needs — models read delimited data perfectly well.

A practical hierarchy for input payloads, cheapest first:

Delimited rows (CSV/TSV) with a header line — best for anything repeated and tabular.
Compact Markdown tables — nearly as cheap, more readable when you need the model to reason about structure.
Minified JSON — if you genuinely need nesting. Strip the indentation; it is free to remove and never free to send.
Pretty-printed, deeply nested JSON — the default that most codebases produce, and the most expensive option available.

Two important caveats, because this advice is easy to over-apply. First, this is about what you send. For what the model returns, JSON with a strict schema is usually correct — reliable parsing and validation are worth their tokens, and a malformed response that triggers a retry costs far more than the braces saved. Second, do not confuse fewer characters with fewer tokens. Abbreviating customer_identifier to cst_idntfr removes characters and can increase the token count, because the abbreviation is not in the vocabulary and shatters while the real word did not. Shorten by removing redundancy, not by mangling words.

3. Identifiers, hashes and blobs — the multiplier hiding in your data

High-entropy strings are the worst case for a tokenizer, because entropy is precisely what a learned vocabulary cannot compress. UUIDs, content hashes, session keys, signed URLs, and base64 blobs all fragment badly.

The fix is almost always the same: ask whether the model needs the identifier at all. Very often it does not. The model needs to reason about the record; your application needs the key. Replace the UUID with a short positional label (doc 1, row 7) in the prompt, keep the real key in a lookup table on your side, and map back when the model refers to it. You pay a handful of tokens instead of a few dozen, per identifier, per call.

Base64 deserves its own warning. Embedding an encoded file in a prompt is the most expensive way to move bytes through a language model — base64 inflates the payload before tokenization even starts, then tokenizes badly. Use the provider's native file or image input path rather than pasting encoded content into a text field.

4. Context you did not write — the multiplier that grows on its own

The first three multipliers are about the shape of text you deliberately composed. This one is about everything the framework adds around it, and it is usually the largest single contributor to input tokens in a mature system:

The system prompt, re-sent on every single call.
Tool and function schemas — full JSON Schema definitions for every tool the model might call, sent whether or not the step needs them. Ten tools attached "just in case" are ten schemas billed on every turn.
Retrieved chunks — a top-k of 20 when a top-k of 5 answers just as well is a four-fold input bill for the retrieval stage.
Conversation history, replayed in full on every turn, which grows without bound unless something truncates it.

These are the tokens that make average input-per-request creep upward month after month with no code change that anyone would describe as "adding cost". They are also the tokens most amenable to prompt caching, because much of the volume is a stable prefix. Caching and trimming are complements, not alternatives: trim what should not be sent at all, then cache what legitimately must be re-sent.

Measure it, or you are guessing

Everything above is unverifiable arm-waving until you put a number on it, and the number is cheap to get.

Count with the right tokenizer. Token counts are model-family specific. Use the tokenizer library matching the model you actually call, or the provider's token-counting endpoint. A count from the wrong tokenizer is worse than no count, because it feels authoritative.
Count per request shape, not per application. Almost every system has a small number of distinct prompt shapes, and almost always one or two of them dominate the bill. An application-level average hides exactly the outlier you are looking for.
Break the count into parts. System prompt, tool schemas, retrieved context, history, user input. You cannot act on "4,000 input tokens"; you can act very directly on "2,900 of those 4,000 are tool schemas for tools this step never calls".
Put it in the test suite. A test that asserts a request shape stays under a token budget catches context creep on the pull request that causes it, which is roughly a hundred times cheaper than catching it on next month's invoice.

The moves, in order of payback

Ordered by return on the effort required, highest first:

Prune tool schemas to the step. Attach only the tools the current step can actually use. Often the largest single win, and it usually improves reliability too — fewer tools means fewer wrong tool choices.
Re-serialise repeated data. JSON arrays to delimited rows; strip pretty-printing everywhere. Pure win, no quality cost.
Tighten retrieval. Lower top-k, raise the relevance threshold, and re-rank. Sending fewer, better chunks usually improves answer quality at the same time as cutting the bill.
Drop identifiers the model does not need. Positional labels in the prompt, real keys in your lookup table.
Bound conversation history. Window it or summarise it. Unbounded replay is the most common cause of a cost curve that bends upward while usage stays flat.
Cache the stable prefix. Put frozen content first, volatile content last, and mark the breakpoint so the repeated part bills at the cached rate.
Cap output. Output tokens price several times higher than input on most models, so an unbounded reply is the most expensive kind of token you can leave unmanaged.

Make it a standard, not a one-off clean-up

A tokenization clean-up delivers a step change and then decays, because the pressures that caused the bloat — a tool added here, a top-k raised there — are still operating. What sustains it is treating token count as a reviewable property of a change, the same way you already treat query count or bundle size:

A token budget per request shape, agreed and written down.
A test that fails when a shape exceeds its budget.
A line in the code review checklist: does this change add context to a hot path, and is it needed on every call or only some?
A monthly read of average input tokens per request per deployment, which is the metric that shows creep before the invoice does.

What your own estate is already telling you

You do not have to instrument anything to get the first read. Azure OpenAI, Amazon Bedrock and Vertex AI all publish token counts and request counts per deployment, which means average input tokens per request is available from your existing telemetry right now — and it is the single best indicator of whether tokenization is costing you.

That is exactly what the CloudFinOpsKit FinOps Agent reads. Its AI Workloads checks pull 30 days of real token and request metrics per deployment, price them against your actual billed cost, and flag the specific patterns this article describes — context bloat above roughly 4,000 input tokens per request, output bloat, a cold prompt cache on a deployment calling often enough to have a warm one, and premium models carrying volume that a smaller sibling could serve. No agent, no proxy, no code change: it reads what the platform already records. See the FinOps for AI framework for how those checks map to the wider practice.

FAQ

What is a token in AI billing?

A subword fragment from the model's learned vocabulary — the unit providers meter and price. Common English words are usually one token; rare words, identifiers and non-Latin scripts split into several. Roughly four characters per token is a fair rule of thumb for English prose and a poor one for everything else.

Does non-English text cost more?

Generally yes — commonly two to three times for non-Latin scripts, because tokenizer vocabularies are English-dominated. The practical consequence is that the same feature can carry a different unit cost per market, so segment your unit economics by language.

Is JSON more expensive than other formats?

For repeated tabular input, usually — you pay for every brace, quote and repeated field name. Delimited rows with a single header line say the same thing far more cheaply. For model output, keep strict JSON: reliable parsing is worth the tokens.

Will shortening my text always reduce tokens?

No, and this trips people up. Abbreviating real words can increase the count by pushing them out of the vocabulary. Remove redundancy and unnecessary structure rather than mangling words, and verify with a real tokenizer rather than a character count.