The prompt token estimator above models an entire API request, not just a single string of text — because that's what actually determines whether your call fits inside a context window and what it costs when the invoice arrives. Enter your system prompt size, your user message, how many prior turns of conversation get carried along, and how long you expect the reply to run, and the tool adds it all up for you.
We use this kind of modeling constantly at Arb Digital when we scope AI-assisted features for clients — a chatbot, a content pipeline, an automation script — because the real cost of "a call to the API" is almost never just the one message a person typed.
What This Tool Does
Rather than counting tokens in a block of pasted text, this tool builds up the full shape of a real request: a system prompt (the instructions sent behind the scenes on every call), the current user message, a running history of prior conversation turns, and the tokens you expect the model to generate in its reply. It sums the input side — system plus user plus history — separately from the output side, then reports both the total and the pieces that make it up.
This is a fundamentally different question from "how many tokens is this text," which is why it lives apart from a plain text counter. A short user message can still produce an expensive call if it's riding on top of a long system prompt and ten turns of accumulated chat history.
How to Use It
- Enter your system prompt size. If you don't know the exact token count, paste it into a text-based counter first, or estimate roughly one token per four characters.
- Enter the user message size. This is the specific question or instruction for this particular call.
- Set conversation history. Enter how many prior turns are being included and the average token size of each — this is often the part people underestimate.
- Set expected output length. Estimate how long the model's reply will typically run, since output is billed and counted separately from input.
- Read the total. The headline number is the full per-call token count; the grid breaks out input, output, history, and the portion re-sent every turn.
The Formula / How It's Calculated
The math is a straightforward sum, but the components matter: total input tokens = system prompt + user message + (history turns × average tokens per turn), and then total tokens per call = total input tokens + expected output tokens. Most commercial APIs, including OpenAI's, bill input and output tokens at different rates and report them separately in usage data, which is why we keep those two numbers distinct throughout the tool rather than collapsing them into one figure. See OpenAI's own explanation of request and response token accounting in its Chat Completions API reference, and Anthropic's equivalent guidance on token counting for Claude models.
Every number you enter here is itself an estimate unless it comes from an actual tokenizer count, so treat the total as a planning figure. It's still far more useful than eyeballing a single message, because it forces you to account for pieces of the request that are easy to forget — especially conversation history, which silently grows with every reply.
Why the Whole Request Matters More Than Any One Message
A chat-based assistant doesn't just send your latest message to the model — most implementations resend the entire conversation so far, every single time, because language models are stateless between calls. That means turn ten of a conversation carries the token weight of turns one through nine along with it. If each of those nine turns averages 400 tokens, that's already 3,600 tokens of pure overhead before the model even reads what you just typed. Multiply that across thousands of daily conversations, and history overhead often becomes the single largest line item in an AI feature's operating cost, larger than the "interesting" part of the conversation itself.
This is also the number that decides whether you fit inside the model's context window at all. If system prompt, history, and user message together approach the model's maximum, there may be no room left for a useful output, and some providers will simply truncate the oldest turns to make space — which can silently change how the assistant behaves mid-conversation.
Practical Ways to Control the Cost
- Trim history aggressively. Keep only the turns that are actually relevant to the current question rather than the entire conversation from the start.
- Summarize old turns. Replace early conversation history with a short, model-generated summary once it grows past a handful of turns, preserving context at a fraction of the token cost.
- Cap output length explicitly. Set a maximum output token limit rather than letting the model run as long as it wants — this protects both cost and context budget.
- Slim the system prompt. Every token in a system prompt is paid on every single call for the life of that feature; keep instructions tight and remove anything not actively changing model behavior.
- Watch the resend line specifically. The "re-sent every turn" figure in this tool's results is the number that compounds fastest as a conversation grows — it deserves its own line of attention in any cost model.
How This Differs From a Simple Token Counter
A plain text counter answers "how many tokens is this paragraph." This tool answers a different question: "what will this entire API call actually cost me, end to end." It models the request the way the API itself sees it — a system role, a user role, prior turns, and a generated response — rather than a single pasted block. If you only need the first question, our ChatGPT Token Counter is the faster tool for that job; use this one when you're scoping a feature, a chatbot, or a batch job where conversation history and output length are real variables, not afterthoughts.
A Worked Example: Ten Turns Into a Conversation
Picture a support chatbot with a 250-token system prompt, a 600-token current question, nine prior turns averaging 400 tokens each, and a 500-token expected answer. History alone contributes 3,600 tokens — larger than the system prompt and current question combined. Total input lands at 4,450 tokens, and the full call, including output, comes to 4,950 tokens. Run that same conversation to turn twenty and history alone can exceed 7,000 tokens, even though the user's actual question that turn might be a single short sentence. This is exactly why teams that only budget off "the user's message" are consistently surprised by their real per-call costs once a feature ships and conversations run long.
The practical takeaway is that cost modeling for a chat feature has to be done at the conversation level, not the message level. A feature that looks cheap based on a single test message can become expensive once real users start having ten- and twenty-turn conversations, and the only way to catch that before launch is to model history growth explicitly, the way this tool does.
Batch and Automation Workloads Need the Same Modeling
Conversational chat isn't the only place this matters. Automation pipelines — a script that summarizes documents, tags support tickets, or generates product descriptions in bulk — often carry their own version of a "system prompt" in the form of fixed instructions repeated on every call, plus per-item content that varies. Modeling that fixed overhead against your expected per-item content size, the same way this tool models system prompt against user message, is the difference between a batch job that's priced accurately up front and one that blows past its budget halfway through a run of ten thousand items.
Arb Digital designs and ships AI-assisted tools, chatbots, and content workflows for real businesses — with the token and cost math worked out before launch, not discovered on the first invoice.
See Our Services All Free ToolsCommon Mistakes to Avoid
- Forgetting history entirely. Estimating cost off the user's message alone dramatically understates real per-call token totals in any multi-turn feature.
- Ignoring the system prompt. It's invisible to the end user but billed on every call — a large or verbose system prompt adds up fast at volume.
- Underestimating output length. Output is often priced higher per token than input, and a model asked to "explain in detail" can run far longer than expected.
- Assuming history is a one-time cost. It's resent and rebilled on every subsequent turn until it's trimmed or summarized, not just paid once.
- Not testing against the real context limit. A call can be affordable and still fail outright if system prompt, history, and output together exceed the model's maximum context window.
Related Free Tools From Arb Digital
For a fast estimate of a single block of pasted text, use the ChatGPT Token Counter. To convert between word counts and token counts quickly, try the Words to Tokens Converter. If you need to check whether a request fits inside a specific model's context window, use the Token Limit Checker. Once you know your per-call token totals, compare providers with the LLM Cost Comparison tool, or explore the broader AI Token Calculator collection. You can also browse our full free online tools hub for more calculators.
Frequently Asked Questions
Every prior user and assistant turn that gets resent along with the current request, since most chat implementations pass the full conversation back to the model on each call.
Most providers price and report input and output tokens differently, with output typically costing more per token, so keeping them separate gives a more accurate cost picture.
It shows you the total tokens per call so you can compare that number against your model's published context window, but it doesn't hard-enforce any specific model's limit.
Paste it into a text-based token counter, such as our ChatGPT Token Counter tool, or use the rough rule of about one token per four characters of English text.
Because it's resent in full on every single turn, not paid once — a long-running conversation can multiply its own token cost many times over as it continues.
Yes — combine the total tokens per call from this tool with your expected call volume and a provider's per-token pricing, or feed those numbers into the LLM Cost Comparison tool for a fuller monthly estimate.
