We measured how many tokens 'hello' costs: the word — 9, through Claude Code — 43,483

The word "Shalom" costs a language model somewhere between 2 and 10 tokens. That's it. But when we sent it through Claude Code — the coding agent we used to work on this research — it cost 43,483 tokens on the very first turn. Same word, almost 4,800x more. So we opened a terminal, hooked into the APIs of Anthropic, Google and OpenAI, and measured everything down to the single token: input, output, thinking, Hebrew vs. English, across seven models. We found a "Hebrew tax" nobody's talking about, and an entire model that thinks for 264 tokens just to answer "Shalom." Let's dive in, with all the numbers.

The bottom line: how much does "Shalom" cost in each model

Before the explanations, here are the measured numbers — how many tokens a single "Shalom" costs:

• Claude Opus 4.8 — 9 input tokens, about 26 output. Thinking: 0. It's smart enough not to think about a greeting.
• Claude Haiku 4.5 and Sonnet 4.6 — 10 input tokens, about 27 output. But turn on thinking, and Haiku jumps to 81 output tokens — 3x on the same word.
• Gemini 2.5 Flash — just 2 input tokens (!), about 11 output. But by default it thinks 31 tokens over "Shalom," and Gemini 3.5 Flash thinks 264.
• GPT-4.1 — 8 input tokens, 8 output, no reasoning. But GPT-5 thought between 64 and 192 reasoning tokens over "Shalom" — up to 24x the 8 tokens GPT-4.1 needs for the exact same word. On one single word.
• Claude Code (right here, in the terminal) — that same "Shalom" costs 43,483 input tokens on the first turn, because the giant system prompt travels along with it. Almost 4,800x the word itself.

The line that keeps repeating: the word "Shalom" costs 2 to 10 tokens. Everything else in the bill — the overhead, the thinking, the agent wrapper — that's what actually costs money.

How did we measure all this? We connected directly to all three APIs — Anthropic, Google and OpenAI. Each one has a way to count input tokens for free without actually running the model (like Anthropic's count_tokens, which matched our real billing exactly), and we read output and thinking tokens straight off the usage field of a real response. GPT we measured live against the OpenAI API — GPT-4.1 and GPT-5, including reasoning tokens.

Let's break down each finding, because behind every number there's a lesson. But first — we need to understand what we're even measuring.

What's a tokenizer, and how do you even build one?

A tokenizer is the component that converts text into numbers the model can understand. It breaks "Shalom" down into a list of token IDs (numbers), and the model itself never sees letters — only these numbers. Think of it like a dictionary that maps chunks of text to numbers.

Here's the interesting question: is a tokenizer code, or a model? The answer is both. The engine that splits text according to the dictionary is simple, fast code. But the dictionary itself — meaning, which sequence of letters gets its own token — isn't hand-written. It's learned from data, exactly like a model.

How do you train a tokenizer? The common method is called BPE (short for Byte-Pair Encoding). You start with every character as its own separate token, and then repeat one operation over and over: find the pair of adjacent tokens that appears most often in the text, and merge it into one new token. We actually ran this on a small corpus — meaning a small pile of text — of Hebrew words, and within five merges the tokenizer "learned" the word shalom:

Look at the output: first ש+ל merged into של, then של+ו into שלו, and then שלו+ם into שלום, complete. That's the whole trick: a sequence that appears a lot in the training corpus earns its own token; a rare sequence stays broken into pieces. (Gemma's and Gemini's tokenizer is built with a tool called SentencePiece, which trains a vocabulary in a slightly different way than BPE — it starts from a large vocabulary and trims it down instead of building up from scratch — but the idea that matters to us is the same: the vocabulary is learned from data, not hand-written.)

And here's exactly where the whole Hebrew tax comes from: the corpora used to train tokenizers are overwhelmingly English. So English gets tons of merges — whole words earn their own token — while Hebrew, a tiny minority in the data, gets very few merges, and its words stay broken apart and expensive.

A small glossary: corpus, vocabulary, and embedding (and why you even need them)

We paused on a couple of terms — corpus, vocabulary — and I have to actually explain them properly, because without them it's hard to understand what's happening under the hood. And let's add a third term everyone throws around and few explain: embedding. At the root of all this is one simple problem: a computer only knows how to do math on numbers, but language is text. So for a model to work at all, text has to be translated into numbers in a few stages, and each stage solves its own problem:

• Corpus is the giant pile of text the model learns from — billions of words from the internet, books, and code. The problem it solves: you can't teach a machine language with rules, because language is too messy; instead, you show it huge amounts of real text, and it learns the patterns on its own. Think of a kid learning to talk by hearing millions of sentences, not by studying grammar. And this, by the way, is where the Hebrew tax is born: the corpus is mostly English, so the machine barely "heard" Hebrew — which is exactly why Hebrew is expensive for it.
• Vocabulary (the dictionary) is the final, fixed list of every token the model knows — for example around 200,000 entries in o200k (and about 256,000 in Gemini's tokenizer). The problem it solves: there are infinite possible strings, but a model needs a finite, fixed set of building blocks to work with. Think of a Lego set with a fixed number of shapes — you build everything from it, and if a whole word isn't available as a single block, you assemble it from many small, expensive pieces (exactly what happens to Hebrew).
• Embedding is the conversion of a token — which is just an arbitrary ID number — into a list of numbers (a vector) that captures its meaning. The problem it solves: the ID 106154 (the number for "Shalom" in o200k) is completely arbitrary, it says nothing about meaning, and ID 5 and ID 9000 aren't related to each other at all. Embedding gives every token "coordinates on a meaning-map," so that similar words sit close to each other, and you can do math on meaning. Without embedding, the model has no way whatsoever to "understand" that words are related — it just has meaningless numbers.

So the full picture, end to end: our text goes through a tokenizer that splits it into tokens (numbers), each token becomes an embedding (a meaning vector), and the model works on those vectors and generates tokens back out. The tokens we're counting throughout this whole piece are the first link in that chain — which is exactly why "how many tokens" isn't a technical detail, it's the foundation of the whole bill.

Seeing it with your own eyes: how "Shalom" breaks apart

Want to see the Hebrew tax with your own eyes? Here's how the word "Shalom" breaks apart in OpenAI's two tokenizers:

• In the new tokenizer (o200k, used by GPT-4o and GPT-5): "Shalom" is one whole token. The entire word is a single Lego brick.
• In the old tokenizer (cl100k, used by GPT-4): "Shalom" is four tokens — 'ש', 'ל', and then two raw byte-fragments (like 0xd7·0x95), which aren't even a whole letter, but half a letter at the byte level.

In the old tokenizer, "Shalom" wasn't just broken into letters — it was broken into half-letters at the byte level. That's the Hebrew tax in its rawest possible form.

Hebrew vs. English — the full dataset

Now to the summary numbers, because we measured a lot more than just "Shalom." We took five pairs of sentences, Hebrew↔English, matched in meaning, then a full paragraph, and measured all of it across every tokenizer.

The sharpest finding actually came from the long paragraph — and that's also where we learned an important methodological lesson. Same paragraph, identical meaning, in Hebrew and English:

• In GPT-4o's tokenizer (o200k): 90 tokens in Hebrew vs. 67 in English — a 1.34x tax.
• In Gemini: 111 vs. 67 — a 1.66x tax.
• In Claude: 188 vs. 99 — a 1.90x tax, almost double.
• In GPT-4's old tokenizer (cl100k): 265 vs. 67 — a 3.96x tax, almost 4x.

The exact same paragraph goes from 99 to 188 tokens in Claude (1.9x), and in GPT-4's old tokenizer from 67 to 265 (nearly 4x). Hebrew simply costs more, in every single model.

Bottom line for your wallet: same text, same meaning — and whoever writes in Hebrew pays Claude almost double, and fills up half the context window for the exact same content. That's a tax we're charged purely because our native language is a minority in the training data.

And here's the methodological lesson, because we almost fell into this trap ourselves: you can't compare tokenizers on short words using raw API token counts. Claude carries a fixed overhead of roughly 7 to 8 tokens per message, which dilutes the ratio downward — on a single "Shalom," Claude looks more efficient than Gemini, and that's exactly backwards from the truth. Only on long text, without the overhead noise, do you get the correct ranking: GPT-4o is the most efficient in Hebrew, then Gemini, then Claude, and far behind, the older generation of GPT-4.

So why doesn't Claude have a public tokenizer? (And yes, I got this wrong earlier)

Here's something important we need to correct, which we checked in depth. The initial impression was "only OpenAI publishes a tokenizer" — and that's just not true. Here's the accurate picture:

• OpenAI publishes tiktoken as open source, downloadable and runnable locally.
• Google publishes Gemma's tokenizer (its open model), and according to Google, Gemma shares the same tokenizer family and vocabulary as Gemini (SentencePiece, a vocabulary of about 256,000). Meaning you can download and run locally a tokenizer that's a very good approximation of Gemini's — not necessarily byte-for-byte identical to the current version, but close enough to count with.
• Anthropic publishes nothing: no open model, no library, just the count_tokens API.

The real outlier is actually Anthropic — it's the most closed of the three, and that was a mistake on my part earlier. In my view, that's a fair criticism. So why keep it closed anyway? Three plausible reasons: the vocabulary leaks information about the training data, it contains special tokens that could be exploited for prompt injection, and not publishing gives them flexibility to upgrade between versions. And what about the suspicion that "it's wasteful on purpose to charge more"? The measurements actually disprove that: Claude is roughly twice as efficient in Hebrew as GPT-4's old tokenizer, and wasting tokens hurts Anthropic itself first — more compute per request, and the context window fills up faster. Every lab in the world is racing to build a more efficient tokenizer, not a more wasteful one.

Thinking mode — the waste crosses every provider

Thinking mode is when the model "thinks out loud" before answering — generating an internal chain of reasoning, and every one of those tokens gets billed as output. We asked: what happens if you turn on thinking for "Shalom"? The answer is unsettling, and it crosses every single provider.

In Claude Haiku 4.5, turning on thinking tripled the output (from 27 to 81 tokens) for a one-word greeting. Gemini 2.5 Flash thinks 31 tokens over "Shalom" by default, and Gemini 3.5 Flash thinks 264. And GPT-5? It generated between 64 and 192 reasoning tokens over "Shalom" — non-deterministic, but always tens to hundreds. Only Claude Opus 4.8, with its adaptive mode that decides on its own how much to think, thought 0 — it recognized that a greeting doesn't require thought, even at maximum effort.

The cross-provider rule: thinking mode, on by default, burns tens to hundreds of tokens on "Shalom" — GPT-5, Gemini and Claude, all the same. The smart Opus 4.8 is the exception.

Two layers: the LLM vs. the platform

Up to this point we measured the LLM alone. But nobody sends a bare "Shalom" straight to an API — we send it through a platform: ChatGPT, a coding agent, an app. And that's a second cost layer almost everyone ignores.

How do you measure it correctly? You need a baseline. The baseline is the naked call: just our message, no system prompt, no tools. That's the floor — "Shalom" costs 2 to 10 tokens there, depending on the model. Sitting above that floor is the platform wrapper: its system prompt, tool configs, memory and history. The difference is the platform tax.

We measured this on Claude Code — the coding agent we were working in — straight from its usage logs. Let's start with two concepts: a "naked" call is when we send the model only our message and nothing else, and a "turn" is one round of request-and-response in a conversation. Now to the numbers: that same "Shalom" that costs 9 tokens as a naked call arrived at the model wrapped in 43,483 input tokens already on the first turn. Why so much? Because with every request the agent sends the model, along with our word, it also sends the entire "operating manual": the giant system prompt (instructions on how to behave), the configs for every tool it can call (read a file, run a terminal command, etc.), any skills that were loaded, and its memory (the CLAUDE.md file). The word "Shalom" is 9 tokens out of that entire pile — everything else is the agent's fixed wrapper, and that's what inflates the first turn by almost 4,800x.

And the wrapper only grows as you keep working. The average of 119,331 input tokens per turn, which we measured across the whole session, is far higher than the first turn — because it also includes the accumulated conversation history and the content of every file the agent read along the way. In other words: this isn't a bug and it isn't specific to this project — it's simply how an agent works, it carries all of its context with it every single time. An important fairness note: about 95% of this input is read from cache (roughly a tenth of the price), so this is a big "tax" in raw token counting — but in actual money, it's significantly softened.

And what about the claim that our session wasn't "clean"? We measured that too. We ran Claude Code completely bare — no skills, no MCP, no memory — and that same "Shalom" still cost about 23,000 input tokens on the first turn. Meaning even the most minimal wrapper possible is ~2,550x the word itself; our skills and MCP added another ~20,000 on top of that baseline. Both numbers are real, and that's the range: from 23,000 tokens in a bare session up to 43,000 in a loaded session like real work. The criticism is factually fair — and it actually reinforces the point: in every configuration, the wrapper dwarfs the word.

And here's a good question worth answering: which LLM should you pick as your baseline? The practical answer is surprising — it barely matters. The gap between tokenizers ("Shalom" costs 2 tokens in Gemini vs. 9 in Claude) shrinks to nothing next to a platform tax of tens of thousands of tokens. At the platform level, the wrapper dominates the bill, not the choice of model. You can run the exact same measurement on any other agent (OpenClaw, Hermes, Codex): check how many tokens its wrapper sends, and subtract the baseline. We measured Claude Code precisely because we're running inside it; the others are probably the same order of magnitude, but we won't throw out numbers we didn't measure ourselves.

And what saves all of this from being unworkable? Cache. Roughly 95% of tokens on every turn — around 119,000 on average — are read from cache, which costs about a tenth of a regular input token. Without prompt caching, an agent carrying a wrapper of tens of thousands of tokens on every single turn simply wouldn't be economical — the cache exists precisely for that wrapper.

So what do you actually do with this? Five practical takeaways

This isn't just trivia about "Shalom" — here's what's actually worth doing with these findings:

1. Measure before you build — it's free. Every provider offers free token counting (count_tokens in Anthropic, countTokens in Gemini) that gives you the exact input count without running the model. Budget the cost up front instead of discovering it in the bill.
2. Hebrew costs more — plan for it. The same content in Hebrew costs roughly 30-90% more tokens than English, depending on the model. If cost is critical, consider writing your system prompt and context in English and saving Hebrew for user-facing content. The most efficient tokenizer for Hebrew among modern models is GPT-4o's.
3. Turn off thinking for simple tasks. Thinking mode burns tens to hundreds of tokens even on a greeting. For easy tasks — turn it off (thinkingBudget=0, low effort), or pick an adaptive model that decides on its own. Save thinking for tasks that actually need it.
4. In agents, the wrapper rules — not the model choice. The gap between tokenizers (2 vs. 9 tokens per word) shrinks to nothing against an agent's tens-of-thousands-of-token wrapper. Choose your model based on quality, and minimize the system prompt and tool configs if you're building an agent yourself.
5. Prompt caching is what makes an agent economical. About 95% of the wrapper is read from cache, at a tenth of the price. If you're building something with fixed, recurring context — make sure you're actually using the cache, or you're paying 10x more than you need to.

Bottom line

So what did we find, in one line? The word "Shalom" itself is cheap to the point of being funny — 2 to 10 tokens. What actually decides the bill is everything around it: the fixed overhead, the Hebrew tax (from 1.34x in GPT-4o up to nearly 4x in the old tokenizer, and 1.90x in Claude), thinking mode that by default burns tens to hundreds of free tokens on GPT-5 and Gemini, and a platform wrapper that outweighs the word by thousands of times. To me, the real lesson here is a habit: before you build anything on an LLM — measure, don't guess. The tools are free and take five minutes.

There's also a fair caveat: these measurements are a snapshot from July 2026, tokenizers change between versions, and the output is non-deterministic — run it again and you'll get slightly different numbers. Don't trust the single number; trust the method. All the code that ran here is in the repo, and you can run it on any word you want.

So, what about you — how many tokens do you think the most common prompt you send every single day actually costs, and when's the last time you actually measured it instead of guessing?