How much does AI integration cost? What you pay for besides the build

It costs the build plus a set of running costs, and the running costs are the ones people underestimate. For the build, the owner-stated position is that most Skofi projects land between $5,000 and $10,000 (US dollars), and larger systems cost more than $10,000. That is a typical range for our projects, not an AI-specific benchmark and not a quote, and we quote after a discovery conversation once we have seen the process, its exceptions and the systems involved.

The range says nothing about what you will pay a model provider each month. That depends on volume, on how much text or imagery each item contains, on which model does the work and on how often the work has to be repeated. We do not quote model prices here, because vendors change them and the current figure is on their pricing page. Anthropic's pricing page is the one we have read for this article, and it lists input and output tokens separately, with different rates for cached input and for batch processing. We have not compared providers' prices, and you should not rely on us for that.

This article is about metered API usage in software you build or commission. A product subscription for a chat tool or a coding assistant is priced differently, and the reasoning here does not carry over. For the engineering that makes extraction safe, see our article on AI invoice extraction.

The layers interact. Spending a little more on a stronger model can reduce review labour. Spending more on validation can reduce both retries and review. The point of listing them separately is to see which one a given change moves, instead of judging the whole project by the model's price list.

Providers charge per token processed, with input and output priced separately. On the pricing page we read for this article, every listed model charges more for output tokens than for input tokens, so a task that returns a long answer costs more than one that returns a short label, even when the input is identical. A token is a fragment of text, and images and long documents are converted into tokens as well.

What counts as input is more than the document. It includes your instructions, any examples, the tool definitions you supply, the conversation so far and anything retrieved from your records. Anthropic's pricing page describes the tokens added by tool use in these terms, and says that some server-side tools carry charges of their own on top. A pipeline that makes several model calls per item pays for each of them.

Why model choice changes the bill

Models are priced in tiers, and the pricing page we read describes the smallest current Anthropic model as aimed at high-volume tasks such as classification, extraction and routing. That is the principle behind our own advice: use the cheapest model that can actually do the job. Deciding whether an inbound email is an invoice, an enquiry or spam rarely needs a strong model. Reading a creased photograph of an invoice taken in poor light might. The cost question is where each of your task types sits.

Routing by difficulty applies the same principle inside one task. Send everything to the small model first, validate the result, and escalate only the items that fail validation or come back with low confidence to a stronger one. If most items are easy, most of the volume is billed at the lower rate, and you pay the higher rate only on the exceptions. This is a design decision with a cost in complexity, and it is only worth making when volume is high enough for the saving to matter. Test it on your own documents before you rely on it.

Retries, loops and agents multiply the bill

A response that fails validation and is requested again costs twice. An agent that calls a model repeatedly while it works through a task pays for every call, and each call may resend the growing context. This is why we cap retries, cap the number of steps an agent may take, and log tokens per task. Our article on AI agents for operations covers when an agent is the right shape at all.

AI steps inside automation platforms

If the model call sits inside Make, Zapier or n8n, the platform meters it under its own rules and you may pay the platform and the provider. On Make, for instance, non-AI modules cost a credit per module run while other modules can cost differently, so check the platform's credits page for the AI modules you use. Our automation platform comparison explains the billing units.

Review labour is the cost of a person checking what the model produced, and for anything that writes to your books, goes to a customer or cannot be undone, we think it should be budgeted, not wished away. It is the layer that turns a data-entry job into a review job. It is usually cheaper than typing, but you should time it on your own documents rather than assume so.

This is why the cheapest model is not automatically the cheapest system. A model that costs less per item but needs corrections on more fields costs reviewer time on every one of them. The comparison to make is total cost per accepted item: model charges plus review minutes plus the cost of errors that were missed. On the trading ERP we built, the model proposes line items, a person confirms, and only the confirmation moves stock and balances. We have not published a time saved or an accuracy figure for it, because we did not measure one we can defend, and you should be wary of any provider who quotes one without showing the method.

Review cost can fall over time, deliberately. Once you have measured field-level accuracy on real documents, you can consider auto-approving narrow, low-risk cases that pass validation, and keep a person on the rest. Start with review everywhere and loosen it with evidence. Loosening it on a hunch is how an extraction error becomes a ledger error found at month end.

Evaluation is a set of real examples with the correct answers written down, run before and after every prompt or model change. It costs the time to build the set, which is mostly someone who knows the right answers, and the tokens to run it. Monitoring is the production counterpart: knowing what the system is spending and where it is failing.

• Build the set from your own documents, the worst ones included. A clean sample makes the project look cheap and then makes it late.
• Run it before every model or prompt change and compare field by field. It is the only way to know whether a cheaper model is good enough for your task.
• For large evaluation runs that nobody is waiting on, use the provider's batch interface. Anthropic's batch documentation lists large-scale evaluations as a use case and describes batched requests as discounted compared with standard ones.
• Log token counts per request and per task type, so the first bill is not the first time anyone sees the numbers.
• Alert on spend, on the rate of validation failures and on the size of the review queue. A rising failure rate is often the first sign that an input format or a model changed.

Hosting is usually small beside model usage and review labour, but it is not zero, and it has a design side. Source documents need private storage and a retention rule. Work that nobody is waiting on can run asynchronously, which is also what makes batching possible. Check your host's current pricing rather than assuming.

Maintenance is where the cost of AI differs from conventional software. A rule written in code behaves the same next year. A prompt written for a model may not. Providers release new models and retire old ones on their own schedules, and the same text can be counted as a different number of tokens on a different generation of model. Keep the model behind a setting, keep your evaluation set, and budget a periodic review. When a provider retires a model, check their current deprecation notices for the dates, because we have not tracked them here.

Resilience has a cost too. On the trading ERP the scanner holds several API keys per provider and falls through to a second provider on rate-limit, quota or authentication failure. That is extra build and extra testing, and it exists because those errors arrive when volume is highest. Whether you need it depends on how much a stalled queue costs you.

Put a hard limit at the provider, put soft limits in your own code, and decide in advance what the product does when a limit is reached. A limit that silently stops the feature at the busiest moment is a failure of design, not a success of budgeting.

Anthropic's own guidance on controlling Claude Code costs makes the same points for a different product: usage is charged by token consumption, per-developer cost varies widely, and a team should start with a small pilot group and use the tracking tools to set a baseline before a wider rollout. The reasoning carries over to any metered model usage.

Run the real task on real items from your own business, record what it costs per item in tokens and in minutes of review, and multiply by forecast volume. A pilot answers the three questions a quote cannot: how many tokens an item really uses, how often the output needs correcting, and how long a correction takes.

1. 01Choose one task and define the unit: a document, a message, a decision. Write what a correct result looks like for it.
2. 02Collect a sample of real items, large enough to show the spread, with the worst ones deliberately included. Write down the correct answers.
3. 03Set a spend limit on a separate key before you start, so the pilot cannot become the surprise.
4. 04Run the sample through the candidate models. Record input tokens, output tokens, retries and failures for each task type, from the usage the provider reports.
5. 05Add validation (structure and arithmetic) and count how many items it flags before a person sees them.
6. 06Have the person who will do the review time it, and count the corrections per field. This gives you correction rate and minutes per item.
7. 07Compute cost per accepted item: model charges at the vendor's current prices, plus review time, plus the cost of any error you found afterwards.
8. 08Multiply by forecast monthly volume, then again by ten times that volume. If the larger figure crosses a point where you would choose differently, such as routing, batching or a different model, that is the result of the pilot.
9. 09Add the fixed layers: hosting, monitoring, a periodic model review, and the build. Decide on the total, not on the model's price list.

We scope a pilot against your own documents instead of quoting a duration or a spend here, because both depend on what is in them. Our estimating assistant is a useful example of the discipline, because it is a working demo on a small library and is described as that: one held-out job checked against its draft is recorded as a single check, not as a general accuracy figure.

• Prices and features change. We read Anthropic's pages on 10 October 2026 and quote no figures from them. Read the vendor's current pages when you plan, and again when you renew.
• We have not compared providers' prices, and we do not claim that one is cheaper. Model quality and price both change, and the only comparison that counts is the one run on your documents.
• A pilot sample can mislead. If the real inputs include a format the sample lacked, the correction rate will be worse than measured. Say what the sample did not contain.
• Volume forecasts are often wrong, and public-facing features can be driven by users or by abuse. Quotas and spend limits matter more there than any estimate.
• Review labour depends on who reviews. A specialist's minute costs more than a clerk's, and that changes which model is cheapest overall.
• Regulated or personal data brings obligations about what may be sent to a provider and where it is processed. That needs specialist advice, and none of this article is legal advice.