This was the first post on this site. When I wrote it in February, choosing an AI model meant choosing a vendor, and choosing a vendor meant choosing a platform. None of those three things are tied together any more, so I have rebuilt the guide rather than patch it.
Three changes matter. The model lineup has turned over. Geo-pinned inference has changed what you can say about where your data is processed. And the same frontier model can now be reached by more than one route: Claude Fable 5.1 is available inside Copilot Studio as well as through the Claude API. The criteria I use to choose have not changed: safety, data handling, consistency and cost. What has changed is how each one is answered.
This is a selection guide, not a pitch for one vendor. The method works for any model.
Every major vendor now sells models in tiers, and for a business the tier matters more than the brand. Anthropic’s line is the one I can quote with confidence, because it is the one I price most often:
OpenAI’s GPT line, Google’s Gemini and the open-weight models you can host yourself are tiered in the same way. On the Microsoft side, GPT-6 Astra is the frontier OpenAI model now offered in Copilot Cowork and Copilot Studio.
The honest observation after a year of this: on typical SME workloads — classification, extraction, summarisation, routing, drafting — the gap between the leading vendors is narrow. Any of them will do acceptable work if the prompt and the testing are competent. So the choice is rarely decided by which model is cleverest. It is decided by the four criteria below.
The practical questions are plain. When the model does not know, does it say so or does it invent an answer? When it is given a document that is incomplete, contradictory or simply the wrong document, does it flag the problem or press on? Does it refuse the things it should refuse, every time, not most of the time?
I would not choose on a vendor’s description of its safety approach. Choose on a test: take twenty or thirty real examples from the process you want to automate, include the awkward ones, and see what each candidate does with them. A model that is confidently wrong on one in twenty invoices is a different proposition from one that says “I cannot find a VAT number on this document”.
Reliability also determines how much human review you need to design in. If a decision about a person is involved, that is no longer only a quality question. The rules on automated decisions are covered in our guide to the Data (Use and Access) Act.
This is where most UK evaluations are won or lost, and it is the criterion that has moved most.
The baseline is unchanged. Before you send business data to any model, you need written answers to four questions: is my data used to train models, how long is it retained, who are the sub-processors, and where is it processed? If you cannot get clear answers from the published terms, treat that as the answer.
Until recently the fourth question was the awkward one: the usual way to get a regional commitment was to reach the model through a third-party cloud. Anthropic’s Developer Platform now supports geo-pinned inference: you specify where requests are processed, directly, without routing through someone else’s cloud.
That changes three things in practice:
It does not change everything. Pinning where inference runs says nothing about retention, so zero-retention terms are still a separate item. It does not cover your own application: the database where you store inputs and outputs, your logs and your backups have their own residency. And the regions on offer, and the plans they are available on, must be confirmed against your contract before any data is sent. That is one of the first checks I make in a discovery.
So the residency checklist is now: geo-pinning, zero-retention terms, a named sub-processor list and a DPIA. A region on an architecture diagram is not enough.
The same discipline applies inside Microsoft 365. “It is in our tenant” is a good starting point, not a complete answer. Microsoft’s Flex Routing for EU and EFTA tenants, for example, allows constrained capacity to be served from data centres in other countries, and the sub-processor list behind Copilot changes as models are added.
A business process needs the same input to produce the same kind of output next month as it does today. Four controls decide whether you can have that:
The last two matter more than they did. The lineup above has changed more than once this year. If your tool is not pinned to a version and you have no test set, you will find out about a behaviour change from a user. Whichever model you choose, check how long a pinned version is supported and what notice you get before it is retired.
Context window, which had its own section in the original version of this post, now belongs here. The mid and upper tiers from the main vendors will take a full contract, a long email thread or a batch of invoices in one pass. It is still worth confirming for your largest documents, but it is rarely the deciding factor it once was.
API models are priced per token, and at SME volumes the numbers are smaller than most people expect. Take the illustration I use elsewhere on this site: 3,000 emails a month, about 2,000 tokens in and 300 out for each.
Haiku 4.5: about US$10.50 a month.
Sonnet 5: about US$21 a month.
Opus 5: about US$52.50 a month.
Batch processing halves those figures for work that can wait, and prompt caching cuts the cost of repeated input by around 90%.
Two conclusions follow. First, between tiers the difference is tens of dollars a month, so choose the tier on accuracy, not on price. If the cheaper model miscategorises one email in fifty and each mistake costs someone ten minutes, the saving has gone. Second, the real cost of a custom tool is the build and the upkeep, not the tokens. Budget for those honestly. Spend controls that cap usage, as opposed to reporting it afterwards, are now available and worth switching on from day one.
Since 1 September 2026, Claude Fable 5.1 has been available in Copilot Cowork and Copilot Studio. Microsoft limits it to those two surfaces; it is not available across Copilot generally. For a business on Microsoft 365, that means a frontier Claude model is reachable inside the tenant as well as through Anthropic’s own API. Choosing a model no longer settles which platform you build on.
The model is the same. What differs is everything around it:
Neither route is better in general. If the process is a conversation for licensed staff over Microsoft 365 content, I would start in Copilot Studio. If it is unattended, high-volume, cross-system or customer-facing, I would build on the API. The worked numbers are in Power Automate vs Copilot Studio vs Claude API, the wider build-or-buy question is in Copilot vs custom AI, and the vendor comparison for a bespoke build is in the Claude API buyer’s guide.
One piece of advice that has survived every lineup change: do not commit your whole roadmap to a model on the strength of one proof of concept. Testing two options properly costs very little. Migrating off the wrong foundation later does not.
If you want a second opinion on which model and which route fit a specific process, that is what a discovery call is for.
Book a free 30-minute discovery call. No pitch: I will go through your use case against these criteria and tell you what I would test first. If the answer sits inside Microsoft 365, our Microsoft 365 AI consultancy page explains how that works.
Book a Free Discovery Call