The same model, three packagings
When a company "adopts AI", the decision is rarely about which model. It is far more about how the model reaches the work — and there are three routes for that, plus a fourth that sits between them.
The odd part is that behind all three stand the same few models. The difference is not in capability but in who presses the button, where the data sits, and what the invoice counts.
1. Chat interface
The best-known route: you subscribe, you type the question, you get the answer.
- Good for: one-off tasks, drafting, thinking out loud, work a human would do anyway, only faster. Zero adoption time.
- Not good for: repetitive bulk work. Someone pasting the same kind of text into the same window 200 times a day is not an AI rollout, it is manual labour with AI.
- What you pay: a monthly fee per user, typically with tiered usage limits. Between the free and the paid tier the main difference is not the model but the quantity.
2. API
Direct access to the model from code. Here no human sits at the screen; your own system makes the call.
- Good for: repetitive tasks built into an existing process. If the work already happens inside a system — CRM, support tickets, invoices — this is the only route that scales.
- Not good for: when there is nobody to write and run it. An API is not a product, it is a component.
- What you pay: per token, by usage. No monthly fee, but also no ceiling — the cost grows with the traffic.
3. AI built into an application
The third route is that software you already own gains an AI feature: the support system drafts replies, the accounting package reads the invoice, the office suite summarises the document.
- Good for: when the task is exactly the one the vendor solved. You get not only a model but the workflow built around it, with checks and permissions.
- Not good for: when your task differs from what the product imagines. Built-in AI cannot be reshaped, only switched off.
- What you pay: typically a surcharge on an existing subscription, per seat or per outcome. Some vendors bill per resolved case.
The fourth route, halfway between
In the last two years an intermediate layer has appeared: no-code and agent platforms, where you click together a process that calls an API behind the scenes. No developer needed, but you still have to get the process designed.
This is a good choice when the task is repetitive but not big enough to justify commissioning development. What is as true of it as of the API: if it gets something wrong, you are the one who has to notice — the responsibility does not transfer to the platform.
What decides between them?
Not the price and not the model. Four questions:
- How often does it run? Under five a day: chat. Over a hundred a day: API or built-in AI.
- Where is the data? If the material already sits in a system, copying it out by hand is waste.
- Who is accountable for the result? With chat a human always looks at it. With an API that has to be designed in separately.
- Is there someone to run it? An API solution does not get finished — it runs, and running needs an owner.
The prices are not comparable
This is the most common mistake in the decision: putting the monthly fee next to the token price. They are not comparable, because they measure different things.
A chat subscription is a fixed fee per user, whether that colleague uses it five times a month or five hundred. An API bill grows with actual traffic and is zero when nobody uses it. Built-in AI is often priced into the software itself — meaning you pay for it even when it is switched off.
The only fair comparison is to work out the total monthly cost for one real month under all three models. What You Actually Pay For goes through that in detail.
One decision, worked through
The situation: an eight-person company's support desk gets about 60 emails a day. The goal is faster replies.
Chat: the colleague pastes in the email, gets a draft reply, edits it, sends it. At 60 emails that is an hour and a half of copying every day — it works, but not for long.
API: a solution built into the ticket system attaches a draft reply and a category to every incoming email. The colleague only reviews it. This is the right answer — if there is someone to write and maintain it.
Built-in AI: if the ticket system's vendor already offers this, you get the same thing without development, just with less control. At eight people this is almost always a better deal than building your own.
So the order is: look first at what you already use. Only build when your existing software cannot do it, or does it badly.
What to take away
Chat is for human work, the API is for systems, built-in AI is for what the vendor has already solved. The decision is not made by the model but by how often the task runs, where the data sits, and whether anyone will run it. And prices are only worth comparing as a total monthly cost — a monthly fee and a token price are not the same measure.