You ask a question in one app, then the exact same one in another. Both claim to use the same model. You get two answers that differ in length, tone and sometimes content. The model hasn't changed. What has changed is everything wrapped around it, which remains invisible.
This is a common source of confusion, and understanding it changes how you evaluate these tools.
1. The system prompt
This is the most important factor. Before your message, the app sends the model text you never see, which defines its role, tone, what it must refuse, how to format its answers.
We covered this in detail in our article on invisible instructions. The same model configured as a cautious legal adviser and as a creative assistant will produce radically different answers to an identical question.
2. Temperature
This setting determines how much the model favours the most likely answer or explores less expected phrasings, as we explained in our article on temperature.
A creative writing app sets it high, a document-processing tool sets it low. Same model, opposite behaviours.
3. Injected context
Many apps add information to your question without saying so: document excerpts via a RAG system, your history, data from your account.
The model is therefore not answering your question alone. It answers your question plus everything it has been given, and two apps do not provide the same thing.
Here is the sneakiest factor. An app claims to use a model by naming its family, but the precise versions differ. We documented this issue in our article on deprecation: a generic identifier can point to different versions depending on the time and the provider. Two services displaying the same name can run on two distinct models.
5. The effort level
Recent models allow you to control how much the system "thinks" before answering, which we described in our article on reasoning models.
This setting has a direct cost: more effort means more tokens, hence a higher bill. A free app has an obvious incentive to set it low, a professional offering to set it high. This is often the explanation for a quality gap between two services using the same model.
Why it's useful to know
Three practical consequences.
Don't judge a model through an app. If a tool disappoints you, it's not necessarily the model that's bad: it may be the configuration. And conversely, a good experience can come from excellent integration work around an average model.
Compare with equal configuration. That's the only way to measure anything. Comparing two apps does not compare two models.
Part of the value is in the wrapper. This is what we noted about foundation models: when everyone builds on the same bricks, what differentiates is what you put around them. A good app is not the one with the best model; it's the one that has tuned it well for its use case.
What to remember
The model name displayed in an interface is far less precise information than it appears. It tells you the family, not the version, nor how it is configured, nor what is sent to it alongside your question.
It's a bit like reading "petrol engine" on a spec sheet. It's true, and it tells you almost nothing about what the car will do.