What it costs, and what you are tied to

What it actually costs

Three shapes of cost, and organisations routinely budget for one of them.

Per-seat subscriptions. Business tiers typically run around twenty to thirty units of currency per user per month. Forty people is a five-figure annual line, and the decision is usually made once and never revisited.

Consumption pricing. Charged per token, so the bill is a function of use rather than headcount. This is where the surprises live, because the relationship between a person's activity and the number is not intuitive: a long conversation resends the entire transcript every turn, a reasoning model may consume several times the visible answer in hidden working, and an automated sequence that loops can run all night.

In-suite add-ons. The assistant inside your office or line-of-business software, usually per seat, often with its own tier.

The cost nobody counts is the fourth one: checking time. If verification adds four minutes to a task done twenty times a week by forty people, that is over five thousand hours a year. Against that number, the licence fee is a rounding error, and the whole argument about whether these tools pay for themselves turns out to be an argument about the checking, which is the argument this course has been having throughout.

Two settings on day one

If you have consumption pricing, do these before anybody uses it:

• A hard spending limit on the account, set below the level at which you would be alarmed.
• A budget alert at half of it.

Providers offer both. They take five minutes. The alternative is finding out at the end of the month, and the mechanisms that produce a large bill — a loop, a long-running job, a document re-sent on every turn — do not announce themselves.

Give each team or project its own key where the platform allows it, so the bill tells you where the money went rather than only how much.

Lock-in is not where you think

The instinct is to worry about being tied to a model. That is the least of it: models are substitutable, and a competitor's is usually close behind on the tasks in this course.

The real lock-in is elsewhere:

• Your prompts, if they live only inside one product's interface.
• Your data, if uploaded corpora, chat history and custom instructions exist only in that vendor's account.
• Your integrations, once the tool is wired into six systems.
• Your habits, which are the most expensive and least visible.

Four cheap practices keep you portable: keep prompts in your own documents or repository, not only in the product; keep the source material outside the tool, in your own storage; prefer standard formats when exporting; and once a year run your three most important workflows against a different provider's model to see whether anything actually breaks.

That last one takes an afternoon and converts "we could switch" from a belief into a fact.

The model changes under you

This deserves its own warning, because it catches careful teams.

Providers update models, sometimes without a version change you can see, and deprecate old ones on their own schedule. A prompt tuned over months can start producing a different shape of output on a Thursday, with nothing in your systems to explain it.

Two defences. Where the platform lets you pin a specific model version, pin it, and change deliberately. And keep a regression set: twenty real items with the outputs you accepted. Rerun them after any change — announced or suspected — and compare. Twenty items is a few minutes and it converts a vague sense that something is off into evidence.

This is also, as the free-stack lesson notes, the one clear advantage of a local model: the weights on your disk do not change unless you change them.

Prices and tiers move

Free tiers shrink, features migrate upward into more expensive plans, and per-seat prices rise at renewal. Anything that has become load-bearing for your operation at a price you did not negotiate is a risk that grows with your dependence on it.

The mitigation is not cynicism, it is proportion: do not make a free tier the foundation of a process you cannot run without, and know what your fallback is before you need it.

Do not build one

For almost every organisation reading this, building your own assistant is the wrong answer. The demonstration takes a weekend and the maintenance takes forever — evaluation, safety, updates, the model changing, the person who built it leaving.

Buy, or use the free local stack, and spend the effort you saved on the prompts, the checking and the training. Those are the parts that determine whether any of it works, and no vendor supplies them.

A budget that is a real number

Whatever you decide, write down a monthly figure, enforce it with the platform's own limits, and review it against measured benefit rather than enthusiasm. The measuring lesson gives you the method.

A stated cap has a second effect worth having: it forces the conversation about which tasks are worth spending on, which is the conversation that produces good decisions here.