Skip to content
← The Workbook

No. 49 · 2026Concept

Hanzi

A Claude Code token minimizer. Translates your English prompt to Chinese before sending it to Claude, then translates the response back to English on the way out. Theoretically the dense Chinese encoding ships fewer tokens for the same meaning. The honest answer is more complicated than that, which is half the reason the experiment is worth doing.

Status
Concept
Year
2026
Stack
Claude API · Tokenizer · Translation · Cost Optimization · Multilingual · Tool

The Idea

A wrapper that sits between Claude Code (or any Claude API call) and the model. Intercepts every outbound prompt, runs it through a translator (English to Chinese), sends the Chinese version to Claude, takes the response, translates back to English, hands it back to the caller.

The pitch is simple: Chinese characters carry a lot of meaning per character, English needs a lot of words for the same point, and the assumption is that the Chinese version of any prompt should ship fewer tokens. Token count drops, cost drops, context window stretches further, life is better.

That assumption is half right and half wrong. The experiment is the point.

The Honest Token Math

Most modern tokenizers (Claude's included) are BPE-based and have absorbed enough multilingual training data that they no longer naively chop Chinese into one-character-per-token chunks. A common Chinese character is often a single token; a less common one might be two or three.

The English sentence "I would like a cup of coffee, please." is around 11 tokens. The Chinese equivalent "请给我一杯咖啡。" is around 6 to 8 tokens, depending on tokenizer and rare-character treatment.

So there IS a savings, but it's smaller than the naive "Chinese characters carry whole words!" intuition suggests. Maybe 20 to 40 percent on typical conversational prose. Less on technical English with domain-specific terminology that doesn't translate cleanly.

The savings on the OUTPUT side are larger and more reliable. A long Chinese response is meaningfully shorter in tokens than the English equivalent. Round-trip you might save 30 to 50 percent on a chat-style interaction.

But there's a catch on the input cost: the translation step itself costs tokens. If you translate locally (a small model on your machine), the cost is computational not API-token. If you translate via Claude itself, you've added a round-trip that probably eats most of the savings on short prompts.

How It Works (Honest Version)

Two paths:

Path A: local translation, both directions. A small open translation model runs on the user's machine (NLLB-200 or M2M-100, both Meta releases that fit in 8 to 12 GB of RAM). Outbound: English in, Chinese out, sent to Claude. Inbound: Chinese reply in, English out, returned to caller. Zero API-token overhead from translation. The savings on the Claude API call are pure win, modulo translation quality.

Path B: Claude-as-translator. A first cheap Claude call (Haiku) translates English to Chinese. The second call (the real one) is made in Chinese against whichever model the user actually wants. The output is run through Haiku again on the way back. Higher overhead, simpler infrastructure, only worth it if the main call is large enough that the Haiku overhead is small relative to the savings.

The wrapper exposes itself as a Claude-compatible endpoint. Drop-in replacement. Set ANTHROPIC_BASE_URL to the wrapper's address and Claude Code or any other client doesn't know it's been translated.

What Could Go Wrong

The honest list:

  • Translation drift. Technical English, code blocks, variable names, domain jargon, and proper nouns all translate badly. A prompt that asks Claude to debug a TypeScript file with embedded English comments gets noisier on the Chinese side, and the response can lose specificity on the way back.
  • Code is sacred. Code blocks must be preserved verbatim through translation. The wrapper has to detect markdown fences and structured code, exempt them from translation, and translate only the prose around them. This is non-trivial.
  • Tokenizer reality bites. The savings on technical prompts are smaller than on conversational prompts. Some prompts might end up using MORE tokens after translation if they're heavy on English jargon that Chinese has to spell out phonetically (transliteration is token-expensive).
  • Translation latency. Even local translation adds 100 to 500 ms per round-trip. For short interactive prompts, the user-perceived latency loss may exceed the cost savings.
  • Quality drift over long sessions. A long conversation translated turn-by-turn drifts. The system prompt that started in English, was translated to Chinese, and is being referenced for the tenth turn isn't quite the same prompt anymore. Context degrades faster than in monolingual sessions.
  • The novelty trap. If the savings are 25 percent but the integration takes a weekend, paying for the API directly is cheaper than the engineering time. The wrapper has to actually save enough money over enough usage to justify itself, or it's just a cute experiment.

Why Build It Anyway

Three reasons.

  1. Empirical answer. Most claims about cross-lingual token efficiency are based on intuition and old tokenizer behavior. Running a real wrapper for a month and logging actual token costs across prompt types produces real data.
  2. Use case fit. For users hitting context limits on long-document ingestion or massive code review, even a 20 percent savings matters. The wrapper is most useful where prompts are large and conversational, less so where they're tight and technical.
  3. Prepares the ground for other compression strategies. Once the wrapper exists, swapping the Chinese-translation step for any other compression (semantic summarization, structured-format conversion, custom token-efficient DSL) is trivial. The translator is just one slot in a generic prompt-compression pipeline.

What It's Actually Useful For

  • Users running Claude Code at scale where API cost is a real line item
  • Long-document analysis where the document is mostly natural-language prose
  • Educational use case: lets a user actually see how multilingual tokenization works by inspecting before-and-after prompts
  • Token-efficiency benchmarking against other compression approaches

Status

Concept. The MVP is small: a single Python or Node script that wraps the Anthropic API, runs translation through NLLB-200 locally, preserves code blocks, logs token-cost deltas. A weekend build for a v1 with no UI. Worth running for a month against real workloads to see whether the math actually pans out.

If the savings hold up at 20 percent or better on representative workloads, this is a real tool. If they don't, the experiment is still worth publishing as "we tried, here's what actually happens to your tokens when you translate prompts to Chinese."