When a Client Wants You to Use a Different AI Model

The Short Answer

When a client wants you to use a different AI model, do not defend your favorite and do not quietly agree. Ask why first, because the reason decides the answer. Then explain the difference between the tool you use to build and the model the build uses once it is running. In many cases you can keep building in Claude Code and point the finished build at the model the client prefers. Test the two models on the client's own real examples, show them the results, and let them choose with evidence instead of brand loyalty. If the switch changes the scope, price it.

That is the Model Swap Test. It works because most clients do not actually care which model is under the hood. They care that the build works, that it fits the rules their company already has, and that the running cost is predictable. Answer those three things and the model question usually settles itself. Argue about brands and you turn a simple question into a standoff, the same trap covered in [when a client asks for a feature you think is a bad idea](/blog/client-asks-for-a-feature-you-think-is-a-bad-idea).

Why Clients Ask for a Different Model

The request usually shows up during the proposal or right after a demo. Ask a plain question before you respond: 'Happy to look at that. What is behind the preference?' The answer is almost always one of these.

• They already pay for it. The company has a subscription or an account with another AI provider and does not want a second bill. This is a cost and admin question, not a quality one.
• It is on their approved list. Larger clients often have a list of vendors IT or legal has already reviewed. Anything not on the list means a review that can take weeks. This often shows up alongside [a security questionnaire](/blog/client-sends-you-a-security-questionnaire).
• They have a data rule. Someone inside the company has decided where customer or company data is allowed to go. The request is really about data handling.
• Someone told them it is better. A friend, an article, or a team member has a favorite. They need to see results, not hear opinions.
• They want to avoid being locked in. They worry that if you leave, they are stuck with something only you understand. That is a fair worry, and it is about the build's design, not the model.

Each reason has a different fix. The first two are usually solved by running the build on the model they already pay for or already approved. The third is solved by showing where data goes and putting it in writing. The fourth is solved by a test. The fifth is solved by building so the model can be changed later without a rebuild.

Separate the Build Tool From the Model the Build Runs On

Clients often hear 'I build with Claude Code' and assume the finished build can only use Claude. That is not how it works. Claude Code is how you write, test, and fix the build. The finished build can call whatever model fits the job, as long as you set it up that way. Explaining this one distinction clears up most of these conversations, and it is often all the client needed to hear.

The practical move is to design for change from day one. Keep the model choice in one setting instead of scattered through the code, keep prompts in their own files, and keep a set of test examples you can rerun after any change. In the Claude Code desktop app you can ask Claude to put the model call behind one small function with a setting for which provider and model to use, then rerun your test examples against each option. The terminal is optional. A build set up this way answers the lock-in worry directly: if the client ever wants to switch, it is a setting change and a test run, not a rebuild.

Be honest about the limits. Models are not identical. Prompts tuned for one may need adjusting for another, some features work differently between providers, and the running cost per request can change. That is exactly why you test instead of guessing, and why the switch belongs in the scope instead of being done as a quick favor.

Run the Model Swap Test

1. Collect real examples from the client. Ten to twenty real questions, documents, or tasks the build will handle, including a few tricky ones. Have the client agree these represent the job.
2. Run both models on the same examples. Same prompts, same data, same settings, so the comparison is fair. Save every answer.
3. Show the results side by side. A simple table with the example, each model's answer, and whether it did the job. Let the client mark which answers they would accept.
4. Compare the running cost. Show what each option is likely to cost per month at their expected volume, using the provider's current published prices on the day you check. Explain how API costs are passed through, the way [billing clients for AI API costs](/blog/bill-clients-for-ai-api-costs) lays out.
5. Let the client choose and write it down. Record which model the build runs on, why, and that changing it later is a scoped change. Then build.

What to Say

Notice what the message does. It does not get defensive or argue brands. It explains the one thing the client is probably confused about. It asks for the real reason. It offers proof instead of opinion, and it answers the lock-in worry before the client raises it. If the client is still deciding whether to hire anyone at all, [the 'why not just use ChatGPT myself' objection](/blog/why-not-just-use-chatgpt-myself-objection) is a different conversation, and that post covers it.

If the request arrives mid-build, after work is done on one model, treat it like any other change. Explain what the switch involves, retesting, prompt adjustments, possibly a different cost to run, and send a [change order](/blog/change-order-template-for-a-claude-code-project) with the price and timeline. Do not swap it in quietly to keep the peace. A switch that seems to work and then gives worse answers later is the kind of problem that gets blamed on you.