Gains:
- Explain the concept of token, input/output token distinction and tokenization.
- Can calculate the cost of a request and a monthly workload from the number of tokens and unit price
- Can compare the impact of model selection and prompt length on cost
You can't build a solution at scale without understanding the economics of LLM APIs. A demo runs once; The main thing is to be able to predict what the bill will be when thousands of calls are made per month. In this unit we set up the money side of things: what is a token, why input and output are priced differently, how to calculate the cost of a request, and how to budget a monthly workload. This information allows you to measure the return of optimization techniques (caching, model selection, batch) in subsequent units.
What is Token?
Token is the smallest unit in which the model processes text. A word is not always a token; token is usually a part of a word. Roughly speaking, in English, 1 token is ≈ 4 characters ≈ 0.75 words. In Turkish and code, the ratio varies: Turkish words are often divided into more tokens than in English due to its suffixed structure and alphabet. Therefore, it is necessary to measure the number of tokens with the provider's token counting tool rather than guessing by eye.
Tokenization (the process of splitting text into tokens) may be different for each model. This has two practical consequences: (1) The same text may yield different numbers of tokens in different models; (2) Predictions made with tokenizers from other providers (e.g. OpenAI's tiktoken library) will be inaccurate for Claude — use the token counting tip for the model you are using.
Hint: "About how many tokens?" Do not answer the question blindly. Pass a representative text through the token counting API; Base budget decisions on measurement.
Input and Output Tokens
The invoice consists of two items:
- Input tokens: Anything you send to the model — system prompt, past tours, user message, documentation if any. These are processed all at once.
- Output tokens: The response produced by the model. For each output token, the model performs the calculation step by step.
With most providers, output is several times more expensive than input. The reason is simple: reading the input all at once is cheaper than producing the output token-by-token. Knowing this asymmetry explains why optimizations like “require concise answers” are so effective.
Sample prices (per 1 million tokens, USD)
The table below is a reference; Prices may change over time, please confirm your own provider's current list.
model class
sample model
Input ($/1M)
Output ($/1M)
Typical usage
fast/cheap
Haiku 4.5
1.00
5.00
Classification, labeling, simple summary
balanced
sonnet 5
3.00
15.00
General purpose, coding, agent work
strong
Opus 4.8
5.00
25.00
Complex reasoning, long-range tasks
In each class, output is 5 times the input; Moreover, even the input of the powerful model is 5 times the input of the cheap model. These two axes (input↔output and model class) form the framework of your cost decisions.
How to Calculate Cost?
The formula is simple:
cost = (input_token / 1,000,000) × input_price + (output_token / 1,000,000) × output_price
Sample account. A request with Sonnet 5: 1,500 input tokens, 400 output tokens.
input = 1,500 / 1,000,000 × 3.00 = $0.0045 output = 400 / 1,000,000 × 15.00 = $0.0060 total = $0.0105 (about 1 cent)
One call looks cheap. But multiply by volume: 20,000 calls per day → $210 per day, ~$6,300 per month. This is where scale comes into play.
Monthly Budget Template
To extract the monthly cost of a workload, use this template:
1) Average input token per request: ......2) Average output token per request: ......3) Number of requests per day: ......4) Days worked per month: ......5) Cost per request = (1)/1M×input_price + (2)/1M×output_price6) Monthly cost = (5) × (3) × (4)
Pouring this pattern into a spreadsheet and seeing how the sum plays out when you change the model embodies the model selection (unit 5) and cache (unit 6) decisions.
Shortening the Prompt with Copiable Templates
Most of the cost comes from unnecessarily long prompts and wasted output. The templates below provide direct savings.
# Limit output length. Answer with a maximum of 3 items. Add a rationale or introductory sentence.
# Return only the requested field Return only the following JSON, do not add any other text:{"category": "...", "urgency": "low|medium|high"}
# Remove unnecessary contextRemove only the date and amount from the following text. Do not repeat the entire text.Text: """{{text}}"""
# Summarize the long speech (input saving) Summarize this speech in 5 items. I will use this summary instead of the full past in subsequent rounds. Speech: """{{past}}"""
Weak prompt / Strong prompt (in terms of cost)
# WEAK (releases output, expensive)Analyze this support request and write me a comprehensive review.
# STRONG (constrains output, cheap and predictable)Classify this support request. Just return the following JSON:{"category":"invoice|technical|refund|other","urgency":"low|medium|high"}Do not write a description.
The weak version produces maybe 500 output tokens; strong version ~15. Because output is expensive, this is a significant difference per call and multiplies with volume.
Three Mini Cases
Case 1 — The hidden cost of the long prompt. As an accounting automation sorted each invoice, it added a 40-page “rule book” as input to each request: ~12,000 input tokens per request. With Sonnet 5 12,000/1M×3 = $0.036 just entered. 5,000 bills per day → $180 per day. By caching the rulebook (unit 6) input cost dropped by ~90%.
Case 2 — The payoff of downsizing the model. One team was doing simple “positive/negative” sentiment tagging with Opus 4.8: 300 input + 10 output tokens. Opus cost 300/1M×5 + 10/1M×25 = $0.00175. Switching to Haiku, 300/1M×1 + 10/1M×5 = $0.00035 — 5x cheaper, the difference in accuracy was immeasurable. On 3 million calls per month, the difference is $5,250 → $1,050.
Case 3 — Releasing the output. When a marketing team produced a product description, it set no limits on output; the model sometimes said 1,500 tokens. When I added the "60 words maximum" instruction, the average output dropped from 900 to 90 tokens. Since printing was expensive, the monthly bill was reduced by a third, and texts became more useful.
Common mistakes
- Guessing the token by eye: You can be wrong especially in Turkish and code. Measure.
- Assuming input and output are the same: Output is usually much more expensive; Most of the optimization comes from shortening the output.
- Don't be fooled by the cheapness of a single call: The decision is made by volume. $0.01 × million = $10,000.
- Prediction with another provider's tokenizer: Gives incorrect results; Use the model's token counting tool.
- Unlimited enlargement of conversation history: Each round is added to the entry; summarize in long conversations.
- Keeping `max_tokens` unnecessarily high: Hides the budget plan and the risk of being cut; Give a realistic value.
Deeper: Context Window and Long Input Cost
It's critical to see how the price stacks up "across the conversation" and not just "per request." The total amount of text that the model can process is called the context window; The sum of input and output must fit into this window. Modern models offer very large windows (hundreds of thousands, even millions of tokens), but that doesn't mean you can "fill it infinitely" — whatever you put into the window is billed as input.
The trap in long conversations is this: with each new round you send the entire history again (statelessness in unit 1). In a 20-round conversation, the 20th request carries the entire first 19 rounds as input. Thus, as the conversation gets longer, the cost per request grows cumulatively rather than linearly. A 50-round conversation with an agent assistant can produce input costs dozens of times the first round.
There are two ways to manage this. The first is recap: compressing older rounds into a single recap block, keeping only the last few rounds raw. The second is prompt caching (unit 6): reading the fixed context at a tenth of the price instead of repeatedly processing it at the full price. Together, they significantly reduce the bill on long, context-intensive workloads. So token economics is about the design of the entire session, not a single request.
In summary
Token is the smallest unit in which text is processed; input and output are priced separately, and output is often much more expensive. The cost is the number of tokens multiplied by the unit price, and the real decision is made by volume. Shortening the prompt, limiting the output, and choosing the lightest model that accomplishes the task are the most direct levers that reduce the cost many times over.
Application task
Choose a task of your own. (1) Determine the number of input and estimated output tokens for a representative prompt (measure with a token counting tool if possible). (2) Calculate the cost per request for the three model classes. (3) Estimate your daily number of requests and derive the monthly budget for the three models. (4) Add an instruction to shorten the output and note the expected savings.
checklist
- [ ] I can explain the concept of tokens and that tokenization varies depending on the model.
- [ ] I know why input and output tokens are priced differently.
- [ ] I can calculate the cost of a request with the formula.
- [ ] I can create a monthly budget for a workload using a template.
- [ ] I can show with an example the benefit of shortening the output and model reduction.