What an AI project actually costs (the parts nobody quotes)

The quote covers one line out of five

You asked what an AI capability would cost and got back a number built almost entirely out of model pricing — a per-seat figure, a per-million-token figure, or a vendor's estimate of monthly API spend. Then the project started, and the spend showed up where the quote never looked: three months of somebody extracting text from scanned PDFs, a subject-matter expert pulled off her real job to label a test set, an integration into a system of record that outlasted the model work, and a standing on-call rotation nobody had budgeted for.

That gap is not a vendor being dishonest. It is a category error. Model pricing is the only part of an AI project with a published price list, so it is the part everyone quotes. The other four cost centers — data preparation, evaluation, integration, and ongoing operation — have no price list, because they depend on the state of your data and the shape of your existing systems. This guide walks all five and gives you a method for producing a number you can put in front of a budget owner without flinching.

Inference: cheap to demo, priced by structure

Start with the part you can look up, because you should look it up rather than trust a summary. Current rates live on the vendors' own pages: Anthropic, OpenAI, Google's Gemini API, AWS Bedrock, and Azure OpenAI. These change often enough that any number written into an article is stale before it is read. What does not change quickly is the structure, and structure is what determines whether your bill is manageable.

There are at least two prices per model, not one. Input tokens and output tokens are billed separately, and on every major published list output is the more expensive class. That single fact should shape your design: a task that reads a long document and returns a short structured verdict has a very different cost profile from one that reads a short prompt and writes a long narrative, even at identical request volume.

Reasoning tokens bill as output. When a model thinks before answering, that internal reasoning is billed at the output rate. Anthropic's documentation makes this explicit, telling developers to monitor a response field that "reports how many of the billed output tokens were internal reasoning." Turning reasoning depth up is therefore a direct multiplier on your most expensive token class. It is often worth it. It is never free, and it should be a measured decision rather than a default.

Caching is a real lever with a real failure mode. Anthropic publishes the multipliers: 5-minute cache write tokens cost 1.25× the base input price, 1-hour cache writes cost 2×, and cache reads cost 0.1×. If a long, stable prefix — a system prompt, a policy document, a schema — is read back many times within its lifetime, the saving is large. If the prefix changes between requests, or the prompt is used once, you have paid a premium to write a cache nobody reads. Caching rewards workloads with a stable front and punishes ones without.

Batch endpoints are the largest structural discount most teams ignore. Anthropic's Message Batches API documentation describes asynchronous processing at 50% lower cost, with most batches finishing in under an hour. OpenAI's Batch API guide states a "50% cost discount compared to synchronous APIs" with each batch completing within 24 hours. Anthropic also notes that the caching multipliers stack with the batch discount. Nightly document processing, bulk classification, and large evaluation runs almost never need a synchronous answer — and routing them synchronously is a decision to pay double for latency nobody uses.

Consumption and capacity are two different billing models, and pilots hide the difference. A pilot bills for tokens processed. Production with a latency commitment frequently does not. Microsoft's provisioned throughput documentation is unusually direct about this: a provisioned deployment "holds a fixed amount of processing capacity exclusively for your deployment's use, whether or not requests are being made," and is "billed at an hourly rate ($/PTU/hr) based on the number of PTUs deployed, regardless of the number of tokens consumed. The meter starts when the deployment is created and stops when it's deleted." AWS Bedrock provisioned throughput follows the same pattern, and self-hosting an open-weight model has the same shape again — EC2 on-demand instances bill for the instance-hour whether or not a request arrives.

The practical consequence: a pilot's cost per request does not predict production's. Under consumption pricing, an idle system costs nothing. Under capacity pricing, an idle system costs the same as a busy one, and your unit economics improve only with utilization. Those are opposite optimization problems. If you have not decided which model you are on, you do not yet have an estimate. Our guides on context economics and caching and open-weight versus frontier API go deeper on both branches.

One last line estimates routinely omit: retries, failed parses, and evaluation runs are billable traffic. Most spreadsheets count successful user-facing requests only, while real systems re-ask on schema-validation failures, re-run on tool timeouts, and fire large internal volumes every time the eval suite runs.

Data preparation: the cost that recurs

This is where schedules actually go. Not the interesting part — the part where somebody discovers that a third of the source documents are scans without a text layer, that the same policy exists in four near-identical versions with no way to tell which is current, that the export has no reliable modified date, and that access to the folder requires an approval chain nobody has started.

The work is concrete and unglamorous: securing access, extracting text (including from images of text), normalizing formats, deduplicating near-copies, handling sensitive fields, setting chunk boundaries that do not sever a requirement from its exception, and establishing what "current" means in a corpus with no version discipline.

The expensive property is not the first pass. It is that this cost recurs. Source systems change. A department reorganizes its shared drive. A new file type appears. A retention rule changes what you are allowed to keep. Sculley and colleagues documented exactly this class of cost in "Hidden Technical Debt in Machine Learning Systems" (NeurIPS 2015), observing that "only a small fraction of real-world ML systems is comprised of the ML code" and naming data dependencies, configuration debt, boundary erosion, and changes in the external world as standing maintenance burdens. The paper is a decade old and reads like this year's incident log.

What goes wrong: teams price data preparation as a one-time month in the project plan, then find it is a permanent job with no owner. Budget it as a recurring line from the start, and the surprise disappears.

Evaluation: the line item cut first, missed most

Evaluation has two separate costs, and confusing them causes bad planning. The first is expert time to build a labeled set that reflects real inputs and real judgments. This is expensive because it consumes your best people — the ones who can say whether an output is actually correct — and it cannot be delegated to whoever is free. The second is compute to run the suite. Individually cheap; expensive at cadence, because a mature system runs its evals on every prompt change, every model version, every data refresh. Model-graded evaluations bill tokens like any other traffic.

Treat measurement as standing work rather than a gate you pass once. That is also how the NIST AI Risk Management Framework is structured: its four core functions — Govern, Map, Measure, and Manage — describe measurement as continuous. The framework is voluntary, but its shape is the right one for budgeting, because it puts an ongoing activity where teams usually put a milestone.

What goes wrong: the eval set gets built once, against the happy path, on tidy sample documents. Then the provider deprecates the model version you launched on, and there is no instrument capable of telling you whether the replacement is better or worse. Re-validation becomes a fresh project with a fresh budget request. Our companion guide on how teams test AI agents covers the mechanics.

Integration: where the schedule actually goes

The model call is a handful of lines. The system around it is not. Integration is authentication against your existing identity provider; writing to a system of record without creating duplicate entries when a request is retried; backoff that respects rate limits without stampeding; timeouts and circuit breakers; a defined fallback when the model abstains or output fails schema validation; and audit logging that ties an output to a request, a user, and a decision.

Cost management is itself an integration requirement. If per-request spend is not attributed to a function, a team, or a mission activity, nobody can tell you which use case is consuming the budget — and the first time finance asks, the answer is a guess. Tracing that records prompts, responses, and token counts against an owning function is not overhead; it is the only way the bill becomes manageable rather than merely observable.

What goes wrong: a convincing prototype in a week, then months on plumbing that was priced as a rounding error. The prototype was never the hard part.

Operation: the cost that never ends

Four recurring lines, all of which outlive the build.

Version churn. Providers deprecate model versions on their own schedule. Your prompts, your cached prefixes, and your evaluation baselines are all coupled to a version. Even small configuration changes have billing consequences — Anthropic's documentation notes that changing a thinking budget between requests invalidates cache breakpoints, so the next request pays write price instead of read price. A model generation change is far larger than that, and it arrives whether or not you planned for it.

Human review. If a person confirms outputs before they take effect — and for consequential decisions one should — that person's time is part of the per-unit run cost, and it scales with volume. Systems designed to reduce headcount that route every output through a reviewer have simply moved the cost, not removed it.

Monitoring and drift. Inputs change even when the model does not. Somebody has to notice when yesterday's accuracy is no longer today's.

Incident response. A bad output at scale is an operational event. The cost is a rotation, a runbook, and a rollback path.

Building a number you can defend

Here is the method. It produces an estimate you can show your work on, which is the only kind worth having.

1. Name the unit of work. One claim reviewed. One report summarized. One ticket triaged. If you cannot name it, stop — you do not have a project yet, you have an aspiration, and no pricing page will rescue it.
2. Count volume. Units per month, plus the peak. Capacity pricing is sized on the peak; consumption pricing is billed on the total.
3. Measure tokens per unit on real inputs. Your longest actual documents, not the clean samples. This step is where optimistic estimates die, and it takes an afternoon.
4. Multiply by the published rate for the exact model, region, and deployment type you will actually use, separating input from output.
5. Apply a retry multiplier derived from your measured failure and re-ask rate, not from optimism.
6. Add evaluation traffic at your intended cadence, not at zero.
7. Decide consumption versus capacity, and price both. Capacity wins above a utilization threshold you can compute once you have steps 2 and 3.
8. Add the recurring human lines: data maintenance, review labor, monitoring, on-call.

Steps 1 through 3 carry almost all of the uncertainty, and none of them are answerable by a vendor. That is the honest reason AI estimates vary so wildly between firms: the ones who quote fast are quoting step 4 alone. If you want a check on the model-tier assumption underneath the whole calculation, our guide on choosing a model tier and the mid-2026 pricing guide for AI coding tools are useful next reads.

Sources: Anthropic — Prompt caching pricing multipliers; Anthropic — Message Batches API; Anthropic — Thinking-token billing and cache invalidation; OpenAI — Batch API guide; Microsoft — Provisioned throughput (PTU) billing; AWS — Bedrock Provisioned Throughput; AWS — EC2 on-demand pricing; Sculley et al., "Hidden Technical Debt in Machine Learning Systems," NeurIPS 2015; NIST — AI Risk Management Framework. Current rates: Anthropic, OpenAI, Google Gemini API, AWS Bedrock, Azure OpenAI. Verify all rates against the vendor page before you budget. Analysis and framing by Precision AI Academy.

Common questions

Why does an AI pilot cost so much less than production? Usually because the two are billed on different models. A pilot bills by consumption — tokens actually processed. Production with a latency commitment often bills by reserved capacity: Microsoft's provisioned-throughput documentation states PTU deployments are billed hourly based on PTUs deployed, "regardless of the number of tokens consumed." Pilots also tend to exclude retries, failed parses, evaluation traffic, and the longer real documents production sees.

Does prompt caching always reduce cost? No. Anthropic's published multipliers put cache reads at 0.1× the base input price, but 5-minute cache writes at 1.25× and 1-hour writes at 2×. Caching pays when a stable prefix is read back many times within its lifetime, and loses money on one-off prompts or prefixes that change between requests.

What is the cheapest way to run a large one-time job? An asynchronous batch endpoint, when the work does not need an immediate answer. Anthropic's Message Batches API documentation describes a 50% cost reduction with most batches finishing in under an hour; OpenAI's Batch API documentation states a "50% cost discount compared to synchronous APIs" with each batch completing within 24 hours. Anthropic notes the caching multipliers stack with the batch discount.

Is data preparation a one-time cost? No. Source systems change, new file types appear, folder conventions get reorganized, and access rules are revised. Sculley et al. (NeurIPS 2015) documented data dependencies, configuration debt, and changes in the external world as standing maintenance costs, noting that only a small fraction of a real machine learning system is the machine learning code itself.