Which AI Model Does a Tool Use? How to Find Out

Asking which AI model does a tool use sounds like a question the vendor should just answer, and some do. When they do not, the answer is still usually recoverable, because a model id leaks into response metadata, sub-processor lists, status pages and support replies long before it appears in marketing copy. Work the five places below in order and you will have a defensible answer, or you will have learned something useful about the vendor.

One thing to settle first, because it invalidates half the answers people accept: a deployment name is not a model id. Anthropic's docs note that Microsoft Foundry "deployments default to the Claude API model ID (the alias, where one exists); the deployment name is what you send". A vendor telling you "we use Claude" or showing you a dropdown labelled production-fast has told you almost nothing about which weights serve your request.

Why which AI model a tool uses is worth knowing

Three decisions depend on it. Cost, because a tool reselling a cheap tier at a premium price is a different purchase from one reselling a frontier model. Continuity, because every model id carries its own retirement date and a vendor built on an older snapshot inherits that clock. And reproducibility, because a model swap is the most common explanation for output that changed without your prompt changing.

Place one: the response metadata

Start here, since it is the only source that reports what actually served your request rather than what someone intended to serve it.

If the tool exposes an API, send a request and read the whole response body and headers, not just the content. Most providers echo a model field. If the tool is a web app, open browser developer tools, filter network requests to the completion endpoint and look at the JSON coming back. Vendors who proxy a model frequently forget to strip its metadata.

What you are hoping to find is a pinned id rather than a friendly name. Anthropic's model IDs and versioning page states that "each Claude model ID identifies a pinned version of the model" and that "when you use a model ID in an API request, the underlying model remains constant for the lifetime of that ID". An id like that is an answer you can act on. A string like fast or smart-v2 is a product tier, and it can be repointed tomorrow.

The models list, if you have a key

If the tool hands you an API key for the provider underneath, or lets you bring your own, you can ask the provider directly rather than asking the tool. Both major labs expose a models endpoint that lists what your credential can reach. Anthropic's models overview notes the response includes max_input_tokens, max_tokens and a capabilities object per model, plus a line field naming the model line.

That gives you two useful things. The list bounds the possibilities, because a tool cannot serve a model your key cannot see. And the token limits are a fingerprint: if the tool caps your input well below what the listed models allow, the cap is the tool's, not the model's, and that is worth knowing before you blame the model for truncation.

Place two: docs, changelog and status page

Vendors who will not put the model in their marketing often put it in their engineering surfaces.

• Search the docs for a model-selection parameter. Tools that let you pick a model usually name the real ids in the reference.

• Read the changelog for migration notes. "Improved reasoning on long documents" is marketing. "Migrated the default engine" with a date is a disclosure.

• Read the status page component list. A status page that lists an upstream provider as a dependency has told you who it calls, even when the model is not named.

Place three: the sub-processor list

This is the most reliable public source and the least used. Any vendor selling to businesses in Europe maintains a sub-processor list, because data protection law effectively requires one. That list names the companies that process customer data on the vendor's behalf, which means it names the model provider.

A sub-processor list will not give you a model id. It will tell you which lab you are ultimately talking to, and that is enough to narrow the question from "what is this" to "which of these four". It is also the right document to read if your interest is privacy rather than performance, in which case who sees your data when a router picks the model covers the chain properly.

Place four: behaviour, used carefully

Behavioural fingerprinting is the technique people reach for first and it deserves to be fourth, because it is the least reliable. Asking the chatbot which model it is does not work, for reasons worth understanding rather than guessing at: a model does not reliably know which model it is.

Weak signals that are still worth noting:

• Tokenizer behaviour on unusual input, since families differ in how they split text.

• Refusal wording, which tends to be house style.

• Maximum output length and context limits, which are documented per model.

• Latency shape, especially time to first token under load.

Treat all of these as evidence that narrows a list you built from places one to three. None of them is a conclusion on its own, and routing makes them worse: if the product uses model routing, different prompts may legitimately return different fingerprints.

Place five: ask, in writing, with specific wording

Support tickets fail when they are vague. Ask four questions in one message and you will usually get three answers:

1. Which model ids serve requests on our plan today?

2. Do you pin a snapshot, or do you follow a provider alias?

3. What notice do we get before the default model changes?

4. Which model providers appear on your sub-processor list?

Question three is the one that matters commercially, and a vendor who answers it in a contract has given you something better than a model id. Asking it on a schedule, rather than after an output changes, is part of keeping up with AI news without reading every launch post. Our note on what an AI contract should say about model changes covers the clause to ask for.

What a refusal tells you

Some vendors genuinely cannot answer, because they route across providers and the answer changes per request. That is a legitimate architecture and they should say so. What should concern you is a vendor who treats the question as improper. The model behind a product is a dependency, like a database or a payment processor, and nobody considers it rude to ask who processes your payments.

A flat refusal is a signal about switching cost. If you cannot learn which model you depend on, you cannot estimate what breaks when it changes, which means you cannot plan a migration you did not choose. Price that in. Spotting a vendor overselling their tool is the broader version of the same instinct.

Frequently asked questions

Can I just ask the chatbot which model it is?

No. The answer comes from the model's training data or its system prompt, neither of which is authoritative about the deployment serving you, and both of which are frequently wrong.

Does a tool have to tell me which AI model it uses?

Generally not by name. Data protection rules push most business vendors to disclose the processor, which identifies the lab, while the specific model id stays commercial information unless your contract says otherwise.

Why would two users of the same tool get different models?

Routing by prompt complexity, plan tier, region, or a staged rollout. All four are common, which is why response metadata beats any single test.

Is a tool built on someone else's model worth paying for?

Often yes, if the product is the workflow around the model rather than the model itself. The question is whether the markup matches the work, and you cannot judge that without knowing the tier underneath.

What should I do when a tool silently changes model?

Keep a small set of fixed prompts with expected outputs and run them weekly. A silent swap shows up as a diff, which turns an argument about vibes into a dated record.