Skip to content

Glossary

Model provider

The company that makes and offers the model, which is frequently not the company selling you the product you use.

In plain terms

The company that built the engine, as distinct from the company that sold you the car. Sometimes they are the same and often they are not, and the difference decides who is really setting the behaviour, the price and the timetable of the thing you bought.

01

Why it matters

Because a product's most important properties are frequently decided by a company the buyer has no relationship with. What the tool can do, how it behaves, when that behaviour changes and what it costs to run are all substantially set one layer down, and none of it appears in the contract the buyer signed.

02

How it works

Many products in this category are an interface, a set of integrations and a prompt over somebody else's model. That is a legitimate and often excellent thing to build, and it means the underlying capability is bought rather than owned, which is worth knowing when assessing what the vendor actually controls.

Behaviour changes on the provider's timetable rather than the vendor's. A model updated underneath a product changes what the product does, sometimes improving it and sometimes not, and the vendor is frequently as surprised as the customer because they are downstream of the same decision.

Retirement is the version of this that causes real work. A provider withdrawing a model obliges every product built on it to move, and the customer experiences that as their tool behaving differently for reasons nobody at the vendor chose.

Some vendors offer a choice of underlying model, which changes the relationship materially. Being able to switch converts a dependency into a preference, and it is one of the few product properties that genuinely reduces this exposure rather than describing it.

The buyer's practical leverage is asking rather than avoiding. Which provider is behind it, whether that can change, what notice is given and whether an alternative exists are all answerable questions, and vendors generally answer them because none of it is secret.

Who decides what

Who decides whatNaming the split is useful because the natural assumption is that the company you pay controls the thing you bought, and in this category that assumption is frequently wrong in a specific direction. Everything a buyer evaluates during procurement sits in the left-hand column: the interface is what a trial shows, the integrations are what a checklist covers, the price is what a negotiation moves. Everything that determines whether the tool keeps being useful sits on the right, decided by an organisation that has no relationship with the buyer and no obligation to them. This is not a reason to avoid such products, since building on somebody else's model is how most good tools in this category get built and the alternative is usually a worse model. It is a reason to ask two questions that cost nothing: who is behind it, and can it be changed. A vendor that can switch has converted the right-hand column into something closer to a preference, and that single property is worth more than most of the features a comparison table lists.Your vendor decidesThe interface and the workflow.Which systems it connects to.What you are charged.The provider decidesWhat the model can do.When its behaviour changes.How long it exists at all.The right-hand column containsthe properties a buyer caresabout most, and the contractcovers the left. That gap isnormal in this category and isworth entering knowingly ratherthan discovering during anupdate.
Naming the split is useful because the natural assumption is that the company you pay controls the thing you bought, and in this category that assumption is frequently wrong in a specific direction. Everything a buyer evaluates during procurement sits in the left-hand column: the interface is what a trial shows, the integrations are what a checklist covers, the price is what a negotiation moves. Everything that determines whether the tool keeps being useful sits on the right, decided by an organisation that has no relationship with the buyer and no obligation to them. This is not a reason to avoid such products, since building on somebody else's model is how most good tools in this category get built and the alternative is usually a worse model. It is a reason to ask two questions that cost nothing: who is behind it, and can it be changed. A vendor that can switch has converted the right-hand column into something closer to a preference, and that single property is worth more than most of the features a comparison table lists.
03

Seen in the wild

  • An assistant whose answers change one week because the model beneath it was updated.

    ChatGPT
  • A coding tool that lets you choose which underlying model runs, turning a dependency into a setting.

    Claude Code
  • Running a model yourself, which makes you the provider and hands you everything that comes with it.

    LM Studio
04

Common misconceptions

People assume

The company selling the tool made the model.

In fact

Frequently not. A great many products are an interface and a set of integrations over a model bought from somebody else, which is a reasonable thing to build and means the core capability is not the vendor's to control.

People assume

A vendor controls when their product's behaviour changes.

In fact

Not where the model is somebody else's. An update applied upstream reaches every product built on it, and the vendor learns about the consequences at roughly the same time as their customers do.

05

Telling them apart

Model provider vs Inference provider

Model provider

Made the model and decides what it is.

Inference provider

Runs the model and decides how it is served.

One sets behaviour and lifetime. The other sets speed, availability and cost per call.

06

Questions

How do we find out who is behind a product?
Ask, because it is rarely secret. Vendors disclose it more readily than buyers expect, and where a vendor is reluctant that reluctance is itself informative, since the usual reason for vagueness is that the arrangement may change rather than that it is confidential.
Does a choice of model actually help?
It is one of the few product features that genuinely reduces this exposure. Being able to switch turns a dependency into a preference, so a provider's decision about pricing or retirement becomes an inconvenience rather than an event that has to be absorbed.
Does self-hosting remove the question?
It answers it by making you the provider, along with everything that role carries. The model still came from somewhere and its licence still applies, and the operational responsibility that somebody else was holding is now yours to staff and to fund.
07

Key takeaways

  • The company selling the tool frequently did not make the model.
  • Behaviour and retirement move on the provider's timetable, not the vendor's.
  • A choice of model converts a dependency into a preference.
  • Who is behind it is a fair question and usually answered.
09

Tools that use this

  • ChatGPT

    Answers changing because the model beneath was updated.

  • Claude Code

    Choosing the underlying model turns a dependency into a setting.

  • LM Studio

    Running it yourself makes you the provider, with what that carries.

Last checked August 2026

All glossary terms