Every few months a new model launches and someone in your team pastes a pricing table into the channel: this many dollars per million tokens for GPT, this many for Claude, this many for Gemini. Then a decision gets made on the smallest number in the table. That decision is frequently wrong, because the per-million-token sticker price is close to the least useful number for estimating what a feature will actually cost you.
Model prices move too fast for a specific table to stay accurate, so this guide does not give you one. It gives you the method to read any pricing page correctly and turn it into the number that matters: cost per real interaction in your product. Learn the method once and it survives every price change and every new model.
The three things the sticker price hides
1. Input and output are priced differently, and output is the expensive one. Providers charge separately for tokens you send (input) and tokens the model generates (output), and output typically costs several times more per token than input. A model that looks cheap on the headline input price can be expensive in practice if your feature generates long responses. Always read both numbers, and weight them by how your feature actually uses them. A summarizer reads a lot and writes a little. A content generator does the opposite. Their effective costs on the same model can differ by a large factor.
2. A token is not a word. Pricing is per token, and a token is roughly three-quarters of a word in English, less in other languages, and worse for code and unusual formatting. When you estimate, do not count words and multiply by the token price. Count tokens, or estimate tokens as words divided by about 0.75, and know that non-English and code run higher. Getting this wrong by 30 percent is common and it compounds across millions of calls.
3. The prompt you send is bigger than you think. Your input is not just the user's question. It is the system prompt, any instructions, few-shot examples, retrieved context if you use RAG, and conversation history if the feature is a chat. All of that is input tokens you pay for on every single call. A feature with a long system prompt and retrieved context can spend most of its input budget before the user has typed a word.
The number that actually matters: cost per interaction
Stop comparing dollars per million tokens. Compute dollars per interaction, because that is the unit that hits your bill and the unit you compare against the revenue the interaction supports. The method:
- Estimate input tokens per call. Add up the system prompt, instructions, examples, retrieved context, history, and the user input. Use a real example, not a guess.
- Estimate output tokens per call. How long is a typical response, in tokens.
- Apply the two prices. Input tokens times the input price, plus output tokens times the output price. That is the cost of one call.
- Multiply by calls per interaction. Many features make more than one model call per user interaction: a retrieval step, a verification pass, a formatting call. Count them all.
The result is cost per interaction on that model. Now the comparison between GPT, Claude, and Gemini is meaningful, because you are comparing the numbers that will appear on your invoice, not the marketing headline. The deeper version of this, including scale curves, is in AI cost modeling for PMs.
The multipliers that turn cheap into expensive
Once you have cost per interaction, a few real-world factors can multiply it, and a PM who ignores them gets surprised by the bill.
- Multiple calls per task. If your feature does retrieval, then generation, then a verification pass, that is three calls, and your per-interaction cost is the sum. Architectures that chain calls multiply cost fast.
- Retries and failures. Calls that fail or produce bad output and get retried cost money every time. A feature with a 10 percent retry rate is 10 percent more expensive than the clean math suggests.
- Long context. Features that stuff large documents or long histories into every call pay for all of it on every call. Context is not free; it is input tokens.
- Conversation history. In a chat, each turn typically resends the whole conversation so far. By turn ten, the input is large, and you are paying for the accumulated history on every turn.
The instinct to correct here is picking a model on its headline price and being shocked at the invoice. The headline was never the bill. The architecture around the model, how many calls, how much context, how many retries, often matters more than which model you chose.
When the cheaper model is the right call, and when it is not
A smaller, cheaper model is the right choice more often than teams assume, especially when paired with good structure. A common winning pattern is a cheaper model plus a verification step, which can beat a single expensive-model call on both cost and reliability. The way to know is to measure quality and cost together on your actual task, not to assume the expensive model is better for your use case. The decision framework for this is in AI product metrics beyond accuracy.
The cheaper model is the wrong call when the quality gap on your specific task is large enough to hurt the outcome that pays for the feature, or when using it forces so many extra calls and retries that the total cost overtakes the pricier single-call option. You only find out which by running both on a real eval set and comparing cost per interaction at the quality bar you need.
A repeatable comparison, step by step
To compare three models for a feature without getting burned:
- Write down a real, representative interaction: the full input and a typical output.
- Count input and output tokens for it.
- For each model, apply its current input and output prices to get cost per call.
- Multiply by calls per interaction for your architecture.
- Run the same interaction through each model and score quality on the dimensions that matter.
- Compare cost per interaction at equal quality, and project it to your expected volume.
The winner is rarely the one with the lowest sticker price and rarely the one with the highest quality in isolation. It is the one with the best quality per rupee or dollar at your scale, which is a number you can only get by doing the steps above.
TL;DR
- The per-million-token sticker price is close to useless on its own. Compute cost per interaction instead.
- Input and output are priced separately and output is far more expensive. Weight by how your feature uses each.
- A token is about three-quarters of a word in English, more for code and other languages. Estimate in tokens, not words.
- Your input includes the system prompt, examples, retrieved context, and history, all paid on every call. It is bigger than the user's question.
- Real multipliers, multiple calls per task, retries, long context, and chat history, often matter more than which model you picked.
- Compare models on quality per unit cost at your projected scale, measured on a real eval, not on the headline price.
The reason cost surprises are so common is that the number teams compare on is not the number they get billed. In ShipSet, you build a real cost model for a feature and pick a model on cost per interaction at a measured quality bar, so the comparison method above is one you have run, not just read, and the resulting spreadsheet is a portfolio artifact hiring managers specifically ask about.