If your product runs on one AI model, its price is set by a company that can change the terms when your contract comes up. This week one of the best known AI coding companies showed what that looks like, and how much it helps to be able to move.

What happened

The Information reported that Replit, the AI coding platform, moved most of its AI spending from Anthropic to OpenAI in recent months, under a contract worth more than $100 million a year with a model price discount of more than 30%. Runtime Wire, summarising that report on October 25, noted that Replit, OpenAI and Anthropic have not publicly confirmed the financial terms. Treat the figures as reported, not confirmed.

The move itself is on the record. Amjad Masad, Replit's chief executive, said on stage at TechCrunch Disrupt this month that Replit was no longer working with Anthropic, and gave his reasons: "It was a decision based on both cost, partnership, and performance." He also said: "I think ChatGPT is better now."

He then narrowed it. Afterwards he told TechCrunch: "Replit remains model agnostic," and "OpenAI is now our preferred partner for powering Replit Agent." TechCrunch reported that customers can still pick Anthropic's models, but that ChatGPT is now the default, and that this could significantly reduce Replit's Anthropic spending, since most customers keep the default. One person familiar with the matter, who asked not to be named, told TechCrunch that the partnership was still in place.

So the precise claim is this: the default changed, and the default is where the money goes.

The default is the decision

Most of the coverage reads this as a price war between two labs. For anyone building an AI product, the useful part is quieter. Replit could move a nine-figure line of spend because its product could run on more than one model, and it could tell its users so with a straight face.

Many products are built the other way. The prompts were tuned against one model's habits, the tool calls follow one vendor's format, the output parsing assumes one model's quirks, and nobody kept a record of what "good" looks like other than "it works today". In that product, switching models is not a decision. It is a quarter of rework, and the vendor knows it when the renewal comes round.

How we would build it

When we build an AI product or agent, this is how we would set it up so the model behind it can change without a rewrite.

  1. One thin model layer. Every call goes through one interface the product owns: messages in, text or tool calls out. The vendor's SDK lives behind it and nowhere else.
  2. Prompts per model, not per product. Keep a prompt file for each model you support. Models read the same instruction differently, and pretending they do not is how a switch quietly makes the product worse.
  3. An evaluation set from your own work. A few dozen real tasks, with what a good answer must contain, scored automatically. This is what turns "I think the other model is better now" into a number you can defend.
  4. Cost per task, not per token. Log what each finished task cost on each model. A cheaper price per token can still cost more if the model needs more turns or more retries.
  5. The default is a setting. Which model serves which task is configuration, so a move can be tried on a slice of traffic and rolled back the same afternoon.

Our take

Model prices are moving fast, and the labs are competing for large customers with discounts. That is good news for builders, but only for builders who can take the better offer.

If changing your model is a rewrite, you do not have a vendor. You have a landlord.

The catch

None of this is free. A model layer and a second set of prompts are code to maintain, and an evaluation set takes real work to build and keep honest. The lowest common denominator is a risk too: if you only use features every vendor shares, you give up the ones that make one model better for your task. Our view is to keep one primary model and use its strengths, but keep the evaluation set and one tested alternative, so a switch is a week of checking, not a quarter of rebuilding. A very early product with one prompt and no users may not need any of this yet.

What to do this week

  1. List every place your code calls a model vendor directly. If the list is longer than one file, that is your switching cost.
  2. Write down 20 real tasks your product does and what a good answer to each must contain. That is the start of an evaluation set.
  3. Run those 20 tasks on a second model once, and record the quality, the time and the cost of each.
  4. Before your next contract renewal, know what moving would take. That is your bargaining position.

If you are building an AI product and want a second opinion on how tied it is to one model, book a conversation.

Sources