How to Build a Realistic AI Software Cost Breakdown

Build the estimate around a defined task: what a user submits, what the system returns, and what counts as an acceptable result. Then separate implementation work, usage charges and ongoing support. The worksheet below is a planning method to adapt to your project, not a market price or a fixed percentage allocation.

Describe the scope before assigning a price

Write down the proposed workflow, data sources, integrations and acceptance checks. For a document assistant, this might include importing approved files, returning answers with references, enforcing access permissions and handling questions the documents cannot answer. List excluded features as well, such as handwriting recognition or automatic actions in another system.

Ask an estimator to show hours and assumptions for each work package: data preparation, application development, integration, evaluation, release and documentation. Include time to assemble representative test cases and review outputs. If the data has not been inspected, record that uncertainty as a separate discovery task rather than hiding it in a precise total.

Estimate usage from the actual workflow

Anthropic's pricing documentation distinguishes input tokens, output tokens and cache operations. Its tool-use section also identifies additional charges for some server-side tools. Use the current terms for the provider and model you intend to use; do not assume that a single token rate covers every component.

For a simple uncached text request, estimate input and output charges separately. Count all model calls needed for one completed user task, including evaluation or retries if your design uses them. Add separate rows for tool fees, retrieval services and other metered features. Write the pricing date beside each rate.

Hypothetical arithmetic example: assume 1,000 tasks, exactly one model call per task, 2,000 input tokens and 500 output tokens per call. At invented rates of $2 per million input tokens and $6 per million output tokens, the model charge is $4 + $3 = $7. These are example assumptions, not a provider quote, measured workload or estimate of the whole application.

Make the non-model rows visible

Use this optional checklist to build the rest of your worksheet:

• Data: collection permissions, cleaning, labeling, document updates and evaluation examples.
• Retrieval: document parsing, embeddings, index storage and refresh jobs if the application needs them.
• Application operations: hosting, database, backups, monitoring and support.
• Delivery: build execution, test environments and artifact retention.
• Review: output checking, incident investigation and changes requested after release.

Check which rows are already covered by an existing contract. For example, GitHub Actions billing describes plan-dependent allowances and charges for usage beyond them in private repositories. Record the applicable allowance and expected paid usage instead of charging every build minute twice.

Compare scenarios without inventing certainty

Create a low, expected and high workload scenario using explicit assumptions. Vary task volume, document length, output length, number of calls and human review time. If you assume a cache hit rate or a support workload, mark it as an assumption until you have an observation from the proposed system.

Estimate staff effort separately from external invoices: planned hours multiplied by your chosen internal cost is a budgeting calculation, not a universal hourly rate. Keep one-time implementation and recurring monthly costs in separate totals, with currency and included charges stated consistently.

Use a pilot to revise the worksheet

Run a bounded sample against the acceptance checks before committing to a wider rollout. Record completed tasks, provider usage, failures and reviewer time without collecting unnecessary sensitive material. Compare these observations with the assumptions, explain any remaining gaps, and assign an owner to the budget.

Agree on usage limits and a response when they are reached: reduce scope, defer optional work or seek an explicit budget change. Revisit the estimate when the model, data volume or workflow changes.