Before you generate ten thousand AI responses, two questions decide your costs and your UI: how long will each response actually be, and what will that length cost? This estimator answers both — converting between words, pages, and tokens, estimating the output of a given prompt, and projecting per-response and monthly generation cost.
Mode 1: Plan a Response Length
Enter a target length in words, pages, or tokens, plus your model's output price per million tokens, and monthly volume if you want the projection. The conversions the engine applies:
Outputs: the token count, pages (words ÷ 500), estimated reading time at 220 words per minute, a recommended max_tokens setting (the estimate × 1.25 headroom, rounded to the nearest 50 — set your API limit there so responses finish instead of truncating mid-sentence), cost per response, and monthly cost, which is flagged when it exceeds 0.28 per million tokens and Gemini Flash at $3 per million, so the spread between budget and mid-tier pricing is visible at a glance.
Worked example. A 1,000-word response on a model charging 15 = 199.50 (flagged as high); recommended max_tokens 1,650; reading time about 5 minutes; the same workload costs 39.90 at Gemini Flash's — a 50× spread for identical word counts, which is why length planning and model choice belong in the same conversation.
Mode 2: Estimate from a Prompt
Paste a prompt, set the expected output tokens (default 256) and the words-per-token ratio (default 0.75), and the estimator returns your prompt's word and token counts plus the response's estimated size:
Worked example. A 40-word prompt with 512 output tokens: the prompt itself costs about 54 tokens, and the expected response is 384 words ≈ 2,304 characters — a solid paragraph block, roughly three-quarters of a page. This is the mode for product decisions: will the answer fit a chat bubble, a summary card, an email? Set output tokens, read the word estimate, adjust before a single API call is made.
Using the Estimates Honestly
Every figure here descends from the 0.75-words-per-token heuristic — excellent for English prose, rougher for code, tables, and non-English text (all of which tokenize less efficiently), and blind to reasoning models whose billed output includes hidden thinking tokens. Treat results as ±20% planning numbers: right for budgets, capacity, and settings; wrong for invoicing. The two disciplines that keep production systems sane follow directly: always set max_tokens from the padded estimate (truncated responses are the most common and most preventable length bug), and re-run the monthly projection with your actual average response length from logs after launch — the difference between planned and real length is where AI budgets quietly leak.
Frequently Asked Questions
Why 0.75 words per token?
It is the long-standing average for English text across mainstream tokenizers — roughly 4 characters per token. The estimator lets you change the ratio because your text may not be average English: dense technical prose, code, and many other languages need noticeably more tokens per word.
What is the recommended max_tokens actually for?
It is the API's output cap. Set it too low and responses cut off mid-thought; set it carelessly high and a runaway generation bills you for the full excursion. The estimate × 1.25, rounded to a tidy 50, is headroom sized to the response you actually planned.
Does this estimate generation time or speed?
No — length and cost only. Generation time depends on the provider's tokens-per-second at that moment, which varies with model, load, and tier; divide the token estimate here by a speed you observe in practice if you need a wait-time estimate.