A 1200 word system prompt, 200 word query, 150 word reply on GPT-5.5. Estimate the token cost, then name what doubles it.

Short answer·Medium·4.0 · 0·~3 min·Asked atCohere Intuit Palantir·Relevant atOpenAI

Attempt it

Free · 2 AI evals / day

Start with the rough numbers. English on o200k_base (GPT-4o, GPT-5, GPT-5.5) tokenizes at about 1.3 tokens per word. So for this ticket: - Input: (1200 + 200) words * 1.3 = about 1,820 tokens - Output: 150 words * 1.3 = about 195 tokens Multiply by published GPT-5.5 input and output prices and you get the per-ticket cost. Five things can double that cost in production. **1. Tool schemas.** If the agent has 10 tools with JSON schemas, the schemas are rendered into the prompt on every call. Easily 1,000 to 3,000 extra input tokens per request. **2. Conversation history.** Multi-turn support tickets re-send prior turns on every call. By turn 5, input tokens are several times the original. **3. Non-English input.** Hindi, Arabic, or Mandarin user messages tokenize at 2 to 3 tokens per word on o200k_base, well above the English 1.3. **4. JSON system context.** If the system prompt embeds account data, order history, or preferences as JSON, the keys and punctuation push fertility up. The same content as prose is cheaper. **5. Structured output.** If you ask for JSON, citations, or chain-of-thought, the reply grows beyond 195 tokens. Always validate the estimate by running a real production-shape prompt through tiktoken. The 1.3 multiplier is a starting point, not a billing primitive.

**Per-ticket estimate.** English on o200k_base averages roughly 1.3 tokens per word. - Input: (1200 + 200) * 1.3 = **~1,820 tokens** - Output: 150 * 1.3 = **~195 tokens** Multiply by GPT-5.5's published per-million input and output prices. Validate against tiktoken on a real prompt before trusting the number. **Five doublers in production.** 1. **Tool/function-call schemas.** OpenAI's chat completions API renders declared tools as structured text in every prompt. A non-trivial 10-tool set runs 1,000 to 3,000 tokens. Adding tools to the ticket doubles input cost on its own. 2. **Conversation history.** Multi-turn support flows resend prior turns. Turn 5 input is 5x turn 1 input. Truncation strategies (sliding window, summarization) bound this; without one, costs scale quadratically with turn count. 3. **Non-English user content.** Hindi at roughly 2.5 tokens/word, Arabic at roughly 2 tokens/word, Mandarin at roughly 1.5 tokens/word on o200k_base. A 200-word Hindi message is 500 tokens, not 260. 4. **JSON-formatted system data.** Repetitive keys, brackets, and quotes drive token count above the equivalent prose representation. A flat JSON dump of user context can be 2x the cost of the same content as a paragraph. 5. **Structured or CoT output.** Asking for JSON output, citation blocks, or chain-of-thought reasoning pushes the reply well past 150 words. JSON output specifically can be 2 to 4x prose equivalent, and CoT can 5x the visible answer length. **Validation discipline.** Pipe a representative production prompt through `tiktoken.get_encoding('o200k_base')` once and use that count as the baseline. Re-validate quarterly because tokenizer behavior can drift with model versions. For cost models that drive budget decisions, sample 200 to 500 real prompts and record actual usage from response.usage rather than estimating from input alone.

TL;DR

Roughly 1,820 input plus 195 output tokens at 1.3 tokens/word on o200k_base. Doublers: tool schemas, conversation history, non-English input, JSON system data, CoT output. Validate with tiktoken.

Memory aid

Easy to grasp

Think of tokens like syllables a language model has to read or speak. English breaks into roughly 1.3 syllables per word in this model's dictionary. A 1,400-word prompt is about 1,820 syllables in, a 150-word reply is about 195 out. Multiply by the per-syllable price and you get your bill. But the real world adds five things that quietly double the count. Tools the model can call cost extra reading every time. Multi-turn conversations replay everything you said before on every reply. Hindi and Arabic users speak in many more syllables per word than English ones do. Structured data shoved into the prompt as JSON is wordier than the same content as prose. And if you ask the model to think out loud or reply in JSON, the answer balloons. Estimate with the heuristic, then check with the real counter before you trust the number.

Key concepts

Tokens per wordo200k_basetiktoken

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Token cost estimation is one of the most common back of the envelope tasks for an LLM engineer, and it is one of the most frequently underestimated. The headline number is easy: words times a multiplier times the published price. The production reality is that five factors compound to make the actual cost 2 to 4 times the headline estimate, and missing them is how teams end up with bills that surprise their finance team.

The right framing is that the per-ticket cost is a baseline plus five doublers. The baseline is the user-visible prompt at the per-language fertility multiplier. The doublers are tool schemas, conversation history, non-English content, JSON-formatted system data, and structured output. Each one is a reason the actual bill comes in higher than the estimate.

The rest of this explanation walks the baseline arithmetic, then each of the five doublers in detail, then the validation discipline that separates estimates you can bill from estimates that get you fired.

Baseline arithmetic and the per-language multiplier

Modern English text on o200k_base (the tokenizer for GPT-4o, GPT-5, and GPT-5.5) averages about 1.3 tokens per word. So a 1,200-word system prompt plus a 200-word user message is roughly (1,200 + 200) * 1.3 = 1,820 input tokens. A 150-word reply is roughly 195 output tokens. Multiply by the published GPT-5.5 input and output prices and the per-ticket cost falls out.

The 1.3 multiplier is an aggregate. The actual ratio varies with content type. Plain English prose tokenizes closer to 1.2; English code closer to 1.5; English JSON closer to 1.8; English with many technical terms or proper nouns closer to 1.4. The number is a starting point, not a constant.

For o200k_base specifically, OpenAI doubled the vocabulary size compared to cl100k_base (200K versus 100K tokens), which improved fertility across the board but especially for non-English text and code. The multiplier on cl100k_base for English was closer to 1.5; on o200k_base it dropped to 1.3 thanks to richer English merges and dedicated CJK/Devanagari coverage.

A rough but useful rule: estimate with 1.3 for prose-heavy English, 1.5 for mixed English+technical, 2.5 for Hindi, 2.0 for Arabic, 1.5 for Mandarin. These multipliers are good enough for budget planning. They are not good enough for billing; for that, run the actual prompts through tiktoken.

Doubler 1: tool and function-call schemas

Doubler 2: conversation history

Doubler 3: non-English user input and per-language fertility

Doubler 4 and 5: JSON-formatted system data and structured output

Validation discipline and the production cost-model loop

Situations where this technique stops working.

2–4 min · Everything important, quickly.

python

import tiktoken

enc = tiktoken.get_encoding('o200k_base')  # GPT-4o/GPT-5/GPT-5.5

system_prompt = open('support_system.md').read()  # ~1200 words
user_msg = 'My order #12345 has not shipped, can you check?'  # ~200 words
assistant_reply = generate_reply(...)  # measured at runtime

n_input = len(enc.encode(system_prompt + user_msg))
n_output = len(enc.encode(assistant_reply))
print(f'input={n_input}, output={n_output}')

# Validate against actual API response
response = client.chat.completions.create(...)
print(response.usage.prompt_tokens, response.usage.completion_tokens)
# Drift between tiktoken count and response.usage indicates
# you missed the tool-schema or chat-template overhead.

Real products, models, and research that use this idea.

OpenAI's tiktoken library exposes get_encoding('o200k_base') for GPT-4o, GPT-5, and GPT-5.5 token counting; the per-language fertility numbers come from running it on representative samples.
Anthropic's Claude messages.count_tokens and OpenAI's response.usage both expose actual input and output token counts post-request, which production teams reconcile against estimates nightly.

What an interviewer would ask next. Try answering before peeking at the approach.

QHow does OpenAI's prompt caching change the cost picture for a long static system prompt?

Cached prefix tokens bill at a discounted rate (usually around half on input). For a 1,200-word system prompt that is identical across thousands of tickets, the cache hit rate dominates the cost. Track cache_hits per request in response.usage.prompt_tokens_details. Order the prompt so the static part comes first (system, then tools, then user message) to maximize cache reuse.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Estimating from user-visible prompt length alone, missing the tool schema, the chat-template wrappers, and the conversation history that all count toward billed input tokens.

60 second bullets to scan on the way to the call.

How English on o200k_base maps from words to tokens (about 1.3).
Why the multiplier breaks on code, JSON, and non-English.

Primary sources. Browse if you want the original framing.