The price of one AI response covers only part of the cost of running an AI feature. A task may involve several requests and retries, even other paid services, before it produces something the business can use, and connecting those charges to a completed task gives you a budget you can explain.
A chat subscription used by your staff and an AI connection inside your website are separate purchases. One may be sold by seat while the other charges for processing, and a monthly service around them may carry its own fee, so keep those lines apart even when the same company supplies more than one of them.
This worksheet is for a business owner or product founder who wants a bill they can explain. You will need usage information from the person who operates the feature, and the calculation itself needs no code.
Define one task that has a useful result
Choose a specific job. For example, the feature might turn an inquiry into a draft response that a staff member reviews. Write down what counts as an acceptable result before you estimate its cost.
The task might involve reading the inquiry and retrieving approved business information before asking a model to draft a reply. If it tries again after an incomplete response, that extra attempt belongs to the same task’s cost.
Ask the operator for the number of submitted tasks and the number that produced acceptable results. Keep failed work in the usage total, because an unsuccessful attempt can still consume processing when the customer sees no usable answer.
Use a small reporting sheet:
| Field | What to record |
|---|---|
| Task name | The business job the feature performs |
| Tasks submitted | All attempts during the measured period |
| Acceptable results | Results meeting your written criteria |
| Model requests | Every request, including retries |
| Other paid work | Searches or services used by those tasks |
| Review effort | Human time needed to make results usable |
You can compare periods once the definition stays the same. A slow week and a busy week will have different totals, so look at the cost per acceptable result next to the overall bill.
Understand the units on the invoice
Many model providers charge separately for input and output. Input is the information sent to the model, and output is what it generates. Providers commonly measure both in tokens, which are small units of text or other processed content, so use the provider’s own token count when you estimate cost.
Ask the operator to use the usage figures the provider reports. A request can include instructions and retrieved material that never appear in the customer-facing answer, so estimating tokens from page length tends to come out low.
Anthropic’s pricing documentation separates these charges and describes additional pricing for some tools. Check the current terms for the provider and model your feature uses, including any intermediary that adds its own fee.
Keep a dated copy of the assumptions used in the budget. If a model or rate changes, you should be able to point to the line that changed without rebuilding the whole worksheet.
Work through a simple example
Example numbers follow, chosen to make the arithmetic easy to check.
Assume a feature receives 1,000 tasks during a month. Each task is planned to make two model requests, and additional attempts add 20% to that request count. That gives:
1,000 × 2 × 1.2 = 2,400 requests.
Assume each request averages 2,000 input tokens and 500 output tokens. For this example only, use an input rate of $2 per million tokens and an output rate of $8 per million tokens.
| Calculation | Example amount |
|---|---|
| Input tokens: 2,400 × 2,000 | 4.8 million |
| Input cost: 4.8 × $2 | $9.60 |
| Output tokens: 2,400 × 500 | 1.2 million |
| Output cost: 1.2 × $8 | $9.60 |
| Model processing total | $19.20 |
If 900 of the submitted tasks produced acceptable results, the model-processing cost is $19.20 ÷ 900, or about 2.1 cents per acceptable result.
Now add assumed hosting of $30 and another service costing $12. The example operating total becomes $61.20, before human review or maintenance work. Keep the $19.20 model subtotal visible so that a change in hosting does not look like a change in model efficiency.
Replace each assumption with your own observed usage and current rates. If your provider uses different units or charges separately for audio, give those charges their own lines next to the text calculation.
Give retries their own line
A retry can make sense when a service briefly fails. Asking the model again and again to repair an answer can also be a sign that the task is poorly specified or needs a different approach.
Ask the operator to report those two reasons separately. A report that only counts completed requests hides whether an increase came from new demand or from several failed attempts at the same work.
Set a stopping rule that fits the task. After the set number of attempts, the feature might ask a staff member to review the request or tell the user it cannot complete it yet, and that behavior should be decided before an unusual request starts consuming repeated calls.
For a product with several customers, look at unusually heavy usage by account as well as by feature. Limit billing records to what the investigation needs, which usually means identifiers and usage totals, and keep private inquiry text out of the report.
Compare cheaper models against the same work
A lower rate can help when the model still meets the task requirements. Try the alternative on the same representative examples and judge the results against the same criteria.
Using the earlier arithmetic, suppose another setup reduces processing cost by 25%, from $19.20 to $14.40, but produces only 600 acceptable results. Its processing cost per acceptable result becomes $14.40 ÷ 600 = 2.4 cents.
That is higher than the earlier 2.1 cents even though the processing invoice is smaller, which is why we keep the accepted-result count next to the rate. It also leaves out any extra staff time spent repairing failures, which you would need to include in an operating decision.
Change one part of the setup at a time when you can. If the model and the task instructions both change, a better result is harder to explain and reproduce.
Use discounts where the work qualifies
Repeated instructions may qualify for prompt caching, which lets a provider reuse processing of matching input. Anthropic’s caching guide describes separate cache-write and cache-read charges, while output generation is still charged.
Ask whether your own requests use the cache and record the observed amounts. Apply an advertised discount only to the share of input that qualifies for it.
Work that can wait may fit a provider’s batch-processing option. Anthropic documents batch processing as a separate route with its own timing and pricing. A background report can tolerate a different completion window from a booking decision a customer is waiting on.
Saving a finished answer for reuse is another choice. Before doing that, check whether the information is still current and whether it belongs to a particular customer, because one customer’s private answer must stay with that customer whatever the savings.
Decide what happens when the budget is reached
Ask the operator which controls send alerts and which stop work. A warning email gives someone time to act only if it reaches a person who is responsible for the bill.
Write down the response to a budget threshold. Background jobs that can wait might pause, while a customer-facing feature may need a clear fallback, and any plan that saves money by dropping work the customer believes is underway, without telling them, needs to be rewritten.
Include a busy-period estimate with more tasks and a higher retry rate. You do not need to predict every spike, but you should know which assumptions make the total grow fastest.
Keep this worksheet beside the wider website operating-cost plan. If the feature is part of an app built with AI, add the same calculation to the monthly cost check in our owner’s checklist for AI-built apps.
Review the real bill against the assumptions after the feature has run. Replace estimates with observations and look into the lines that differ, keeping the accepted-result definition steady so you can see whether the feature is getting cheaper to operate or simply completing less work.
For a business website, our project and monthly plan separate the build from ongoing care and explain which third-party costs stay in your own accounts. If your cost question concerns the tools connected to your site, see our integration approach.