Start with one completed task, not a monthly guess
An AI app's running cost depends on how many model requests each task makes, the input and output billed for those requests, and any tools or infrastructure it uses. A feature that drafts a short note once is a different workload from an agent that searches, reads documents and retries several times.
For a first estimate, define the task: for example, turn a fictional repair note into a checked job description. Count the requests needed to finish it, including failed attempts. This guide builds a usage worksheet rather than recommending a provider or quoting a universal cost per user. All dollar rates in the worked example are invented teaching inputs, not a current vendor quote.
Building a prototype with AI assistance and paying for an AI model inside the finished app are separate activities. The existing app-building guide covers the prototype; this guide covers metered runtime usage.
What is a token, and what should you count?
Tokens are the units a model uses to represent its inputs and outputs; they are not interchangeable with words or characters. Images, audio and other media can have their own conversion or billing rules. Google's token guide explains pre-request counting and returned usage information. Use the selected model's counting tools instead of assuming a fixed words-to-tokens ratio.
Count the actual request, including instructions, conversation history, retrieved passages and tool definitions where applicable. A small user message can sit inside a much larger request. Anthropic's token-counting endpoint estimates input size, but does not predict a cache hit or the future output length. Reconcile estimates against returned usage and the billing dashboard.
Keep a rate sheet with provider, model ID, billing platform, currency, effective date, input categories, output rate and separately charged services. Record any applicable volume tier, region modifier or batch discount. Do not combine a price from one platform with usage rules from another.
Separate uncached input, cache writes, reads and output
Prompt caching reuses eligible repeated context; it does not mean the model's answer is free or reused unchanged. Cache creation, reuse and expiry depend on provider rules. Check supported lengths and matching requirements before budgeting a hit.
For the Anthropic Messages API, the documented input categories are input_tokens, cache_creation_input_tokens and cache_read_input_tokens. The first excludes tokens assigned to the other two. Split cache writes further if different lifetimes have different rates. Do not charge the combined input total at the normal rate and then add cache charges again.
For a worksheet with mutually exclusive categories, token cost equals the sum of each category's token count multiplied by its price per million, divided by 1,000,000. Add separately billed tools afterward. Other APIs can expose a total with cached tokens as a subset, so map the fields before using this formula.
Worked example: 100 tasks with a reusable context
Assume 100 completed tasks, exactly one model request per task, no retries and 400 output tokens each. Each request contains a 4,000-token shared prefix plus 1,000 fresh input tokens. The first request writes the prefix to cache; the next 99 successfully read it before expiry. Assume the prefix meets this fictional service's caching requirements.
Invented rates in USD per million tokens: ordinary input $2; cache write $2.50; cache read $0.20; output $8. Assume no thresholds, discounts, storage fees or taxes. Fresh input is 100 × 1,000 = 100,000 tokens, costing $0.20. One 4,000-token cache write costs $0.01. Cache reads total 99 × 4,000 = 396,000 tokens, costing $0.0792. Output totals 100 × 400 = 40,000 tokens, costing $0.32.
The model subtotal is $0.6092. Now assume 20 separately billed searches at an invented $0.005 each: add $0.10 for a total of $0.7092, or $0.007092 per completed task. Any text from those searches must already fit within the input counts assumed above; otherwise, add its actual tokens too.
For the same request sizes with caching disabled, 500,000 ordinary input tokens cost $1.00. Add $0.32 output and $0.10 searches: $1.42. The example's saving is $0.7108. It is not a measured vendor result, and it depends on the stated successful cache reuse.
Stress the assumptions before multiplying by users
Keep caching enabled but suppose every request misses and writes a new 4,000-token prefix. The write total becomes 400,000 tokens, costing $1.00 at the invented rate. Add $0.20 fresh input, $0.32 output and $0.10 searches: $1.62. Here caching costs more than the $1.42 disabled-cache scenario. Actual miss behavior must come from the provider's usage records.
Do not multiply by registered accounts. Estimate completed tasks per active user and requests per task, then include retries and abandoned runs. For a second exercise, reuse the original $0.7092 batch but suppose only 90 outputs pass your quality checks: cost per usable result is about $0.00788. If 100 results are still required, the cost of replacing the failed ten is additional and unknown.
Long conversations and retrieved documents can change later request sizes. Measure a short, typical and unusually long task separately. Report the high-cost cases alongside the average so a few expensive runs do not disappear inside a reassuring headline.
Include tools and the rest of the service
Anthropic's pricing documentation distinguishes token usage from some server-tool charges. Tool definitions and returned content can also consume model input. A search charge and the tokens used to read its results are different line items; neither should silently disappear from the estimate.
Build separate rows for model usage, searches or execution services, document storage and retrieval, hosting, database, monitoring and payment processing where relevant. Some are usage-based and others fixed monthly costs. Add taxes and currency conversion only when the applicable terms are known.
Keep credentials and raw private prompts out of your cost worksheet. A task ID, model/version, usage categories, retry count, chargeable tool units, duration and pass/fail result are enough for the first cost comparison. Retain only the operational data you need.
Put spending controls in the app
OWASP identifies uncontrolled model consumption as a source of service disruption and financial loss. Its guidance supports limits and monitoring. Translate that into explicit application behavior: bounded input and output, authenticated usage allowances, limited retries and a maximum number of agent steps.
Test what happens when the allowance is exhausted: the app should stop or offer a clear fallback. Treat a budget alert as a notification unless the provider explicitly documents an enforced stop. Concurrent requests and delayed billing can make a simple after-the-fact balance check insufficient; account for work already in flight.
Compare lower-cost settings on the same representative tasks and acceptance criteria. A cheaper response that repeatedly fails can cost more per usable result. Keep task quality and spending as separate measurements.
Five-minute practice: build a bill you can explain
Recreate the four token rows from the worked example in a spreadsheet. Keep counts, units and rates in separate columns; calculate each line before summing. Change only one assumption at a time: cache hits, output length, tool count or usable-result count.
Check your answers: original model subtotal $0.6092; total with searches $0.7092; caching disabled $1.42; every prefix rewritten $1.62. These are per 100 requests under the stated assumptions, not monthly subscription prices.
For a real pilot, start with synthetic or approved non-sensitive inputs. Compare the recorded usage to the provider's billing export, explain any discrepancy and date the rate sheet. Only then project a monthly range from measured task volumes.
PROMPT TO ADAPT
Build a cost worksheet using only the usage counts and rate sheet I supply. Separate ordinary input, cache writes by lifetime, cache reads, output and separately billed tools. State whether cached tokens are a subset of total input or a separate category. Show units, assumptions, retries and cost per accepted task. Mark missing values as unknown; do not invent live model prices or send API requests.
Sources & further reading
- Anthropic: model, caching and tool pricing
- Anthropic: prompt caching and usage fields
- Anthropic: counting tokens before a request
- Google: understanding and counting Gemini tokens
- OWASP: unbounded consumption in LLM applications
Educational content. Examples are illustrative. Protocols, products and rules can change; consult the linked documentation for current details.