Your prototype may cost very little while only you use it. A product used by other people creates a different question: what happens to the bill when use increases, someone retries a task or you spend an afternoon helping a customer?
Before choosing a price, make a simple cost model. This is a written set of assumptions and calculations, not a prediction of income. It helps you decide what to measure, which limits to set and whether the proposed service is practical enough to test.
All amounts in the worked example below are hypothetical Pakistani rupees, written as PKR. They are teaching numbers, not supplier quotations, recommended market prices or financial advice. Readers elsewhere can use their own currency without changing the method.
Describe the unit of useful work
Our fictional learner, Bilal, is building a product-description helper for small stationery suppliers. A user enters verified product facts, receives a draft description and checks it before use. The tool does not publish listings or decide product claims.
Bilal’s unit of work is one draft request. That sounds simple until he notices that a request can contain a short pencil description or a long catalogue excerpt. A user may also regenerate the result several times. Counting users alone would hide these differences.
For an early estimate, he defines one ordinary request as a limited input followed by a limited output. He separately records retries and unusually large requests. Later, he will replace these assumptions with observations from safe trials.
Separate fixed costs from usage costs
A fixed cost is an expense that stays roughly the same within the operating range you are considering. A variable cost changes with use. These categories are planning tools, not permanent properties: a hosting plan may have a fixed fee until usage reaches a threshold.
Bilal writes the following hypothetical monthly plan:
- Hosting and basic storage: PKR 3,000.
- Monitoring and other operating tools: PKR 1,000.
- Time budget for maintenance and support: PKR 6,000.
- Planning reserve for unexpected operating work: PKR 2,000.
That totals PKR 12,000 in monthly fixed and planned costs. The time budget is an assigned value for his own effort, not a salary he has actually received. The reserve is a planning allowance, not an incurred bill. Separating these labels prevents an estimate from looking like an accounting statement.
He then assumes an average variable cost of PKR 2 per draft request. This is deliberately invented. A real estimate must include the actual model usage and other usage-based services relevant to the design.
Learn what the model provider charges for
An API is a way for your application to request a service from another system. Model APIs may charge differently for input and output tokens. Tokens are pieces of text used in model processing; they are not always whole words. Different languages and inputs can produce different token counts.
As a current example of billing structure, Anthropic’s official documentation lists separate input and output token prices and describes additional pricing for features such as prompt caching and tools. This article does not reuse any provider’s current numerical rate. Check the exact model, service and feature combination before making your own estimate. See Anthropic’s pricing documentation.
A simple token estimate is: input tokens divided by one million, multiplied by the input rate, plus output tokens divided by one million, multiplied by the output rate. Add applicable tool charges and other costs separately. Do not assume a chat subscription pays for your application’s API use; verify your actual plan and billing arrangement.
If supplier bills and customer prices use different currencies, write the exchange-rate assumption and its date. Do not quietly treat today’s conversion as a permanent rate. Also identify payment fees and tax questions for appropriate local advice rather than assuming they are zero.
Figure 1. Keep assumed fixed costs and usage-based costs separate.
Work through one hypothetical price
Bilal considers a purely hypothetical plan priced at PKR 1,500 per month with up to 200 ordinary draft requests. At the assumed PKR 2 variable cost, using all 200 requests costs PKR 400. The amount left toward fixed costs is therefore PKR 1,100 per fully used plan, before any costs omitted from the example.
This amount is sometimes called contribution: price minus the variable cost associated with that sale. It is not the same as profit. Fixed costs still have to be covered, and the assumptions may be wrong.
To cover the PKR 12,000 monthly plan under these simplified assumptions, calculate 12,000 divided by 1,100, which is about 10.91. Because he cannot have a fraction of a customer account, the arithmetic rounds up to 11 fully paying accounts. At 11 accounts, the contribution is PKR 12,100, leaving only PKR 100 above the planned fixed amount.
That tiny difference is a warning about the assumptions, not a business target. This calculation excludes acquisition costs, payment fees, taxes, refunds and unexpected heavy support beyond the assigned allowance. It also assumes all accounts pay the stated price. There is no evidence yet that anyone wants the plan.
Stress the assumptions before trusting them
Now suppose the average request costs PKR 4 instead of PKR 2. The 200-request allowance costs PKR 800. Contribution falls to PKR 700, and 12,000 divided by 700 rounds up to 18 accounts. A single changed assumption has substantially changed the result.
Alternatively, suppose a confusing interface causes frequent support requests. The token bill may stay small while Bilal’s time requirement becomes impractical. Record time spent investigating problems, helping users and maintaining the product. An AI product can be expensive to operate even when individual model calls are cheap.
Make three scenarios: lighter use, expected use and heavier use. Keep the number of customers separate from requests per customer, average request cost and support time. Change one assumption at a time first so you can explain its effect. Then combine pressures to test a difficult month.
Figure 2. Hypothetical arithmetic shows why one price needs more than one usage scenario.
Design limits that users can understand
Avoid offering unlimited use merely because it sounds attractive. Define what counts as a request, what happens when a request fails, how retries are counted and what the user sees near a limit. Do not surprise someone with a charge they could not reasonably predict.
For the prototype, Bilal can stop generation at a clear trial allowance instead of implementing paid overages. He should also set application-side limits appropriate to his design and verify what provider-side budget controls actually enforce. An alert is not necessarily a hard spending stop.
Cost controls must preserve usefulness. Removing essential input to save tokens could produce worse descriptions and more retries. Test the quality and total cost together. A cheaper individual response may be a poor choice if people need several attempts to complete the same task.
Use a cost worksheet as a learning exercise
Write these fields on one page: task unit; expected monthly requests; input and output assumptions; supplier rate source and date; hosting; storage; support time; payment costs; uncertainty allowance; proposed price; included use; and excluded costs.
Mark every entry as measured, quoted or assumed. This simple distinction is valuable. An observed bill for ten tests is measured evidence, but it does not automatically predict a busy month. A supplier price is a quote or listed rate, while your expected user behaviour is still an assumption.
Upverto’s practical learning approach connects concepts to exercises and projects. Apply that pattern here: explain the formula, calculate a small example by hand, build a simple calculator and check its result against your hand calculation. Then change the request allowance and explain the difference without relying on the calculator’s output alone.
Your next step is to estimate the cost of ten invented tasks, record what actually happened and update one assumption. Pricing decisions should follow better evidence about both costs and usefulness. This can support your own product or an internal business tool; it does not require turning the exercise into freelance work.
Frequently asked questions
Is the cheapest model always the best business choice?
No. Compare results on your actual task, including retries, review time and failures. A low listed rate does not establish the lowest cost of completing useful work.
Can I use these example prices for my product?
The numbers are hypothetical teaching inputs. Replace them with verified costs, your intended workload and evidence about customer needs. They are not a recommendation about what customers should pay.
Does reaching the calculated account count guarantee profit?
No. The calculation covers only its listed assumptions. Missing costs, unpaid bills, heavier use or additional work can change the result, and there may be no demand at the proposed price.
Should my own time count if I am a beginner?
Record it even if you are not paying yourself. You need to understand the effort required to maintain the tool. Keep learning time separate from recurring support when comparing scenarios.
What if my product is only for my own shop?
Compare its operating cost and effort with the existing workflow. You may not need a customer price, but you still need to decide whether the tool is useful enough to maintain.
When should I update the estimate?
Update it after meaningful changes in usage, provider rates, features or support needs. Keep dated assumptions so you can explain why the newer estimate differs from the earlier one.