On this page
An AI app budget has two parts: the cost of building a dependable product and the recurring cost of serving useful work. A model's token price answers only a small part of the second question. Authentication, data preparation, payment handling, evaluations and support can remain expensive even when inference is inexpensive.
This guide gives a budgeting method for a small text-based application. It uses deliberately illustrative workloads rather than claiming a universal market price for development. Replace every assumption with your own supplier quote, traffic measurement or engineering estimate before approving a budget.
Define the work before estimating the bill
“A chatbot” is too broad to estimate. A useful scope statement is: authenticated employees ask questions about an approved document collection; answers cite sources; administrators can delete documents; the system rejects access outside each employee's group. That statement exposes retrieval, authorization and deletion work that a chat screen alone hides.
Write down three lists. The first contains user outcomes, such as finding an approved policy. The second contains required controls, such as tenant isolation. The third contains exclusions, such as autonomous purchases. Estimate each outcome and control separately. A prototype that only demonstrates generation is a different deliverable from a supported service.
For agent applications, count tool executions, repeated model turns and human approvals. One user message may produce several billable operations. For image or audio products, identify the provider's actual billing units rather than converting everything into text tokens.
Build a one-time implementation worksheet
| Workstream | Evidence needed for an estimate | Often missed work |
|---|---|---|
| Product and interface | Screens, accessibility requirements, acceptance examples | Empty, failed and interrupted states |
| Data and retrieval | Document formats, volume, access boundaries | Updates, permission changes, deletion propagation |
| Model integration | Supported endpoint and representative tasks | Structured output validation and fallback behavior |
| Service engineering | Availability and deployment requirements | Rate limits, secrets, migrations and recovery |
| Evaluation and release | Approved tasks and failure thresholds | Adversarial cases, regression review and rollback |
| Operations | Support ownership and incident response | Runbooks, account recovery and supplier changes |
For each row, estimate optimistic, expected and difficult effort in hours. Multiply by your team's actual loaded hourly cost, then add quoted external expenses. Loaded cost should include the employment or contractor expenses relevant to your organization. We have not measured a market-wide development rate, so there is no invented “typical developer price” here.
Suppose your internal estimate is 120 implementation hours and 40 evaluation/release hours. At an explicitly assumed internal cost of $40 per hour, the calculation is 160 × $40 = $6,400. This is an arithmetic example, not a quote or prediction. If document permissions require another 80 hours, show that change openly instead of hiding it in a vague AI surcharge.
Separate fixed, variable and step costs
Fixed costs persist when traffic is quiet: minimum hosting commitments, monitoring plans or an on-call arrangement. Variable costs grow with work: model calls, outbound traffic, storage growth and payment processing. Step costs appear at thresholds: another worker, a larger database tier or a staffed support shift.
This distinction matters when traffic doubles. A fixed subscription might stay flat, inference might double, and a database migration might cause a one-time jump. A single blended “cost per user” conceals those different behaviors.
Create a monthly ledger with owner, unit, quantity, unit price, currency, tax treatment and source date. Treat committed spend separately from usage. Record whether storage charges include replicas, whether logs have a retention limit and whether outbound transfer is included. Verify current prices in each supplier's billing documentation; no hosting price is assumed in this worksheet.
Calculate inference from actual workloads
For a simple uncached text request:
request cost = input tokens × input rate / 1,000,000
+ output tokens × output rate / 1,000,000
monthly inference = sum of costs of all billable attemptsUse the inference pricing guide for dated provider examples and cache categories. Avoid averaging incompatible units or treating a provider's cached-input rate as the rate for every prompt.
As a supplier-neutral scenario, assume 20,000 monthly requests, 1,000 input tokens and 200 output tokens each. At hypothetical rates of $1 and $4 per million respectively, inference is $36: $20 input plus $16 output. If another 2,000 identical attempts are billed during retries, the total becomes $39.60. Those rates are assumptions; they are not Theaimart AIx pricing.
Now add retrieval calls, reranking, moderation and tool APIs if your design uses them. Re-embedding a changed document collection belongs in a separate ingestion budget. A successful user task can involve both online requests and background work.
Budget for failure and abuse
A timeout does not prove that the upstream provider did no work. A client may disconnect while the server continues generating. Automatic retries can multiply paid attempts. Track logical user requests separately from provider attempts and reconcile your telemetry with invoices.
Place limits on request size, output, concurrent work and customer spend. Test how limits behave across multiple workers. A process-local limiter resets on restart and cannot enforce an account-wide financial commitment. A production budget needs a durable usage ledger and an admission policy, not just a counter in memory.
Include recovery work. A restore drill consumes engineering time; a lost document or incorrect answer can create support work even if infrastructure remains available. Do not label those costs zero because they do not appear on the model invoice.
Compare three demand scenarios
Build quiet, expected and stressed scenarios from explicit assumptions. For each, vary active customers, useful tasks per customer, attempts per task, context length, output length and peak concurrency. Avoid multiplying all inputs by the same arbitrary growth factor: longer conversations and concentrated traffic create different problems.
| Scenario question | Financial implication | Operational check |
|---|---|---|
| More customers, same task size | More total usage | Account-level limits and support capacity |
| Same customers, longer documents | More input and retrieval work | Context limits and relevant chunk selection |
| Same monthly traffic, sharper peaks | Potential capacity step | Queue delay, deadlines and admission limits |
| More provider failures | More paid attempts and support | Retry budgets and degraded-mode behavior |
Keep a reserve tied to identified risks: uncertain OCR quality, an untested migration or a possible capacity step. Explain each reserve rather than adding an unexplained percentage presented as industry practice.
Connect cost to a useful outcome
Cost per completed task is usually more informative than cost per API call. Define completion before measuring: a document answer with valid citations, a resolved support question, or an accepted code change after review. Cheap responses that require repeated corrections can be costly outcomes.
Calculate contribution before allocating all company overhead: attributable revenue minus variable model, infrastructure, transaction and support costs. Keep advertising, subscriptions and usage pricing assumptions separate; the monetization guide explains how those models change incentives. Do not assume ad impressions will cover unrestricted inference.
What can wait until after the prototype?
A prototype can use a narrow document collection, one provider and manual onboarding. It still needs safe test data, controlled credentials and a spending ceiling. Deferring those controls can make a demonstration unexpectedly expensive or expose private material.
Defer optimization until there is evidence. Shared infrastructure, custom model hosting or a sophisticated cache may cost more to build than they save at small scale. Compare their engineering and maintenance costs against an observed baseline in self-hosting versus APIs.
Turn the worksheet into an operating practice
Before release, give each cost category an owner and review date. Compare predicted and actual unit costs after a representative workload, then investigate differences: tokenizer estimates, hidden tool calls, long outputs or unexpectedly high support effort. Preserve the old forecast so the next estimate learns from it.
The AIx documentation is a starting point for checking supported API operations and account billing when considering Theaimart's inference service. Use the current model and billing information for the selected model; this guide does not supply an AIx price quote. Finish the budget by documenting which assumptions are measured, quoted or still uncertain, then fund the smallest release that can test them.