Replit Anthropic Split: The LLM Cost Lesson for Founders

Last updated: October 2026

Key takeaways

• Replit CEO Amjad Masad said at TechCrunch Disrupt that Replit is no longer working with Anthropic, citing cost, partnership and performance.
• TechCrunch reports that insiders rejected that account, so treat the story as contested until Replit and Anthropic say more.
• The cheapest provider per token is not always the cheapest per finished task. Success rate and retries decide the real number.
• Before you switch providers, run both on your own tasks and compare cost per success.

What did Replit's CEO actually say about Anthropic?

According to TechCrunch's report, Amjad Masad said onstage at TechCrunch Disrupt that Replit is no longer working with Anthropic. He called it a decision based on cost, partnership and performance, and said OpenAI models now do better at building apps from scratch on Replit's internal and public benchmarks. Replit announced an OpenAI partnership in August.

The article also notes that people familiar with the partnership rejected his account, and that Replit had recently published material naming Claude models in Replit Agent's production environment. TechCrunch said it would update the story if Replit clarified. In other words, the facts are still moving. That is exactly why founders should not copy a headline into a roadmap.

Is cost the real reason AI app builders switch providers?

Cost is rarely the only reason, but it is the one that keeps coming back. An AI app builder makes many model calls per generated app, so a small difference in effective price multiplies fast. When a company says cost, partnership and performance in one breath, it usually means: the price per successful result, the commercial terms at their volume, and the quality of the output.

Here is the contrarian point. A provider breakup is a weak signal for your own decision. Replit's volume, contracts, prompts and benchmarks are not yours. What transfers is the method: compare providers on cost per finished task, using your workload.

Why is cost per token the wrong way to compare providers?

Because customers pay for outcomes, not tokens. A provider with a lower list price can cost more per success if it fails more often, needs more retries, or produces longer outputs.

Here is an illustrative example. These are hypothetical providers and rates, not real quotes. Say one generated app takes about 400,000 input tokens and 40,000 output tokens across an agent run.

| | Provider A (illustrative) | Provider B (illustrative) | |---|---|---| | Input price per 1M tokens | $3.00 | $2.50 | | Output price per 1M tokens | $15.00 | $10.00 | | Cost per attempt | $1.80 | $1.40 | | Success rate on your tasks | 90% | 65% | | Cost per successful task | about $2.00 | about $2.15 |

Provider B looks 22 percent cheaper per attempt and ends up about 8 percent more expensive per success. If your own numbers differ, the winner can flip the other way, which is the point: measure it. You can plug your own token counts into the Calcaas LLM cost calculator to size the attempt cost, then divide by your measured success rate.

What should you check before switching LLM providers?

Run a short, honest bake-off before any migration.

1. 1Sample real tasks. Use 100 to 200 recent production tasks, not a public benchmark.
2. 2Measure success. Define what a pass means, then count passes per provider.
3. 3Count retries and tokens. Record input, output and any repeated calls per task.
4. 4Compute cost per success. Total spend divided by passes.
5. 5Price the switching cost. Prompt rewrites, evaluation time, new rate limits and contract terms all count.

Before you commit, read how switching interacts with lock-in in our post on OpenAI and Anthropic switching and vendor lock-in, and check whether improving your harness would deliver the same savings in harness optimization versus model switching. Current list prices live on the Anthropic pricing page.

Should you depend on a single LLM provider?

The Replit story, whatever its details, is a reminder that a single-provider dependency is a business risk. Pricing, terms, capacity and relationships can change quickly, and rewriting a product around a new model under pressure is expensive.

A practical middle path: keep your prompts and tool definitions portable, keep a second provider warm on a small slice of traffic, and track cost per success for both. Then a switch becomes a routine decision, not an emergency.