How to Calculate AI Costs: A Practical TCO Guide

AI cost is the cost of operating an AI-enabled business process, not merely the model call or software subscription. A useful total-cost-of-ownership estimate includes software and usage, data preparation, infrastructure, integration, evaluation, monitoring, human review, security, compliance, maintenance, incident handling, and a reserve for migration or vendor change.

Use this editorial model:

Total AI cost = setup costs + recurring operating costs + variable usage costs + risk-triggered costs.

For a simple illustration, a hypothetical GPT-4.1 request containing 2,000 input tokens and 500 output tokens would cost $0.004 for input and $0.004 for output at the documented rates of $2 and $8 per million tokens. The token charge is therefore $0.008 before tools, platform fees, integration, monitoring, or review. It is an example of token arithmetic, not a complete business budget.

Prices and plans change. The vendor references and figures in this guide were checked on October 11, 2026. Date every estimate and record the model or service, plan, region, billing cadence, effective price, and usage assumptions.

What does AI really cost a business?

Begin with the business job rather than a product list. Identify the source system, expected volume, destination, service-level requirement, permitted data, quality threshold, and the action taken when the AI service is unavailable or uncertain. Then separate costs by timing and behavior.

• One-time setup: process design, data cleanup, integration, configuration, evaluation, security review, and staff training.
• Recurring operations: subscriptions, API usage, hosting, workflow execution, monitoring, support, and scheduled evaluation.
• Risk-triggered costs: retries, human escalation, incident response, rollback, compliance work, retraining, and migration.

Fixed costs include subscriptions, reserved capacity, retainers, and platform minimums. Variable costs include tokens, workflow credits, recommendation requests, data processing, and training jobs. Risk-triggered costs occur only when volume, uncertainty, failure, or regulatory exposure creates additional work. Shared technology costs should have an explicit allocation method rather than being treated as free.

Build an estimate from actual usage

Inventory every billable unit on the process path. A request, token, document, workflow bundle, module action, training job, GPU-hour, user license, and platform minimum are different units. They should not be compared as though they measure the same thing.

Model normal, peak, retry, and exception paths separately. A retry can repeat model usage. A workflow that expands one event into 100 records can multiply downstream module actions. Keep raw usage events at their natural grain and derive daily or monthly reports separately. A summary row cannot uniquely identify multiple requests made by the same account on the same day.

Workload	Main driver and trap	Estimate method	Validation and fallback
LLM request	Input and output tokens, context, cached input, tools, retries. One conversation may contain many requests.	Count requests and measured units by model and price version.	Validate usage and structured output. Route malformed or uncertain results to an owner or reviewer.
Automation workflow	Source bundles, modules reached, AI features, credits, and retries. One scenario run is not one operation or credit.	Simulate bundle and module paths under normal and peak volume.	Filter eligible records before AI processing. Investigate failed, queued, or retried runs.
Recommendation service	Ingestion, training, requests, metadata, and active real-time minimums. Requests are not returned items.	Count interaction records, training jobs, requests, and applicable provisioned throughput.	Choose real-time or batch delivery according to latency and traffic. Review unexpected usage.

For every estimate, retain the effective date, provider, account, model or service version, plan, region, billing cadence, currency, and assumptions. This makes a forecast reproducible when a price page or workload changes.

Estimate LLM API costs per request

Use the selected model’s price and estimate input and output tokens separately. Input usage includes the prompt, conversation history, documents, and other context sent with the request. Apply separate rates for cached input, tools, batch processing, or other metered features when they apply.

The basic formula is:

Input tokens / 1,000,000 x input rate + output tokens / 1,000,000 x output rate + other metered charges.

OpenAI’s GPT-4.1 documentation lists $2 per million input tokens and $8 per million output tokens. At those model-specific rates, the hypothetical request above is calculated as follows:

• 2,000 input tokens / 1,000,000 x $2 = $0.004.
• 500 output tokens / 1,000,000 x $8 = $0.004.
• Total token charge = $0.008 before other applicable charges.

Check the current OpenAI API pricing and GPT-4.1 model documentation at estimate time. The current pricing environment includes multiple models and product-specific charges. A model snapshot, reasoning setting, tool call, cached-input rate, or price change can alter the result. The OpenAI tokenizer can estimate text tokenization, but it is not a complete cost calculator and does not replace actual usage telemetry.

A proposed usage record can contain the following fields. This is an editorial implementation pattern, not a vendor-published schema:

{
  "usage_event_id": "provider-account-request-timestamp",
  "provider": "OpenAI",
  "account_id": "account-123",
  "request_id": "provider-request-id",
  "model_id": "gpt-4.1",
  "model_snapshot": "gpt-4.1-2025-04-14",
  "event_timestamp": "illustrative timestamp",
  "input_tokens": 2000,
  "cached_input_tokens": 0,
  "output_tokens": 500,
  "tool_calls": 0,
  "estimated_cost": 0.008,
  "currency": "USD",
  "price_book_version": "dated pricing reference"
}

The raw event grain is one API request or one billed usage record. Use a provider request ID where available and enforce uniqueness in storage with a stable event identity. If concurrent workers can process the same event, use a database-enforced unique constraint or transactional upsert. A lookup followed by an insert is not race-safe. Keep daily and monthly summaries in a separate view or table.

Include workflow-platform costs and fan-out

Automation cost depends on how many bundles reach each module, not only how often a scenario starts. A CRM trigger that receives 100 records may create many more module executions than a trigger that receives one record. Filters, routers, iterators, searches, AI features, write-backs, audit records, notifications, error handlers, and retries can all change the path.

Make currently describes credits as its billing unit. Its documentation distinguishes credits from operations, and module or AI-feature consumption is not uniform. The Make pricing page, credits and operations guidance, and operation documentation should be checked together. Compare the selected plan’s allowance and billing cadence with forecast consumption instead of reusing an older monthly price.

An illustrative CRM design would be: a trigger supplies records, deterministic filters remove ineligible bundles, an AI step classifies only permitted text, a destination module writes approved results, and an audit event records the decision. Estimate each path by bundle and module action. Add separate cases for peak volume, errors, retries, external API charges, monitoring, cleanup, and human exception handling. This describes a proposed workflow architecture, not a verified end-to-end Make template.

Make automation consulting is relevant when a scenario needs bundle-path mapping, credit assumptions, and operational ownership.

Budget for recommendation systems and infrastructure thresholds

Amazon Personalize separates ingestion, training, and inference pricing. The AWS pricing page documents v2 recipe examples of $0.05 per GB ingested, $0.002 per 1,000 interactions for training, and $0.15 per 1,000 recommendation requests. Other recipes, recommenders, metadata options, and service configurations can use different pricing. Confirm the section that applies to the selected service before calculating a budget.

Keep these grains separate:

• One interaction record for a user-item event.
• One training job for a training execution.
• One recommendation request for an API request.
• One request-item result only when item-level attribution is needed.
• One period summary for an aggregated cost report.

A request that returns several items is still one request unless the applicable pricing model says otherwise. Do not count every returned item as another request. Include data ingestion, training frequency, requests, metadata, engineering, and the selected real-time or batch delivery pattern.

The Amazon Personalize developer guide describes real-time and batch workflows. Use the delivery mode that meets the latency requirement without assuming that request volume alone determines cost.

For hosted models, compare utilization and operating responsibility as well as hourly rates. AWS documents H100-equipped EC2 instances, including P5 configurations, but an estimate requires the specific instance, region, operating system, purchase option, and date. See AWS accelerated-computing instances, On-Demand pricing, and Capacity Blocks pricing. Do not treat a GPU hourly rate as the full cost of running a model. Add storage, networking, orchestration, monitoring, reliability, security, and engineering where applicable.

Choose rules, AI, or human review by the cost of being wrong

Use deterministic rules for required fields, permissions, numeric thresholds, date windows, deduplication, policy blocks, and known status routing. Use AI for semantic interpretation of unstructured text when the output can be constrained and checked. Human review, auditability, and reversibility are operating requirements for legal, financial, employment, eligibility, and safety decisions, not optional overhead.

A proposed CRM classification sequence is: a record event enters the workflow; eligibility and field permissions are checked; only approved text is sent to the model; the model returns a constrained label and optional rationale; the response is parsed and checked; a stale or uncertain result is routed to review; and only an approved result is written back. CRM systems consulting can help assess record permissions, provenance, and write-back design.

Trigger and AI job	Validation gate	Action	Fallback
Support text arrives; draft or classify a response.	Check permitted fields, schema, allowed labels, and source version.	Save the draft or approved classification with provenance.	Send malformed, stale, or uncertain results to a support owner.
CRM record changes; classify permitted unstructured text.	Check taxonomy, write permission, freshness, and review policy.	Write only approved fields and append a classification event.	Do not overwrite the record. Assign a named CRM or operations reviewer.
Recommendation request arrives; rank or return items.	Check dataset requirements, service configuration, request grain, and applicable minimum throughput.	Deliver real-time or batch results according to the service design.	Use a safe non-personalized result or batch path when the service is unavailable.

For CRM deduplication, identify a classification event by source system, source record ID, source record version, and classifier or prompt version. Retain the event separately from the CRM record so reclassification does not erase history. Concurrent workers should rely on a database-enforced unique constraint or transactional upsert, not lookup-then-create alone.

Reject malformed output and labels outside the allowed enum. Confirm that the source record still exists and has not changed since classification. Write only authorized destination fields. Retain model and prompt versions, source version, validation status, reviewer, timestamp, and write-back status. Do not automate direct write-back when an incorrect result could create an irreversible legal, financial, employment, eligibility, or safety consequence without an appropriate human decision.

Apply data minimization and field-level access controls before sending business data to an AI service. Set retention and review rules according to sensitivity and impact. The CRM pattern above is an illustrative implementation design, not a verified vendor template.

Turn the pilot into a budget you can manage

Start with one process and a measured baseline: current labor or service cost, volume, error rate, cycle time, and the outcome the AI must improve. Then calculate cost per successfully completed business outcome, including review time, failed runs, retries, exceptions, and platform usage. Cost per model request alone cannot establish commercial value.

Set owners and thresholds for spend, latency, quality, and escalation. Compare forecast usage with observed events. Investigate variance by path rather than only by monthly total. Pause or roll back when a validation, permission, or safety control fails. Scale only when measured usage and quality support the business case, and keep estimates distinct from operating results.

External budget findings need the same discipline. IBM reported planned AI spending averaging 3.32% of revenue among surveyed retail and consumer-products executives. The study covered 1,500 executives in 15 countries, so the figure is not a universal budget recommendation. HubSpot reported that 75% of surveyed marketing leaders at organizations investing in AI said they had positive ROI. That is a scoped, self-reported survey finding, not evidence that 75% of all companies achieve positive ROI.

Similarly, Oracle’s Q1 FY2025 release referred to 42 additional signed cloud GPU contracts totaling $3 billion. It did not establish that Oracle spent $3 billion on infrastructure in that quarter. Avoid converting contract values or survey results into general business benchmarks.

Proceed when those conditions are in place. If the data, process, ownership, or exception path is not ready, improve that foundation before automating it.