Stop Choosing AI Models by Price. Build an Architecture Instead.

Choosing AI models has turned into a tribal argument.

Every WhatsApp group I’m in, every inner circle of founders and marketers I talk to, is having some version of the same debate. One side wants to move everything to DeepSeek, Qwen, Kimi or GLM because the token price is a fraction of what OpenAI or Anthropic charge. The other side won’t touch them, on principle, on trust, sometimes just on habit.

Both sides are asking the wrong question. The question was never “which model is cheapest.” It’s “which model is right for this specific job, and what does it actually cost me when it gets it wrong.”

The shift to cheap models is real, and bigger than most people realise

This isn’t a fringe conversation any more. CNBC’s reporting in July 2026, based on OpenRouter data, found Chinese-origin models climbed above 30% of US enterprise token volume every week since early February and peaked at 46%, up from just 4.5% in the first half of 2025.

OpenRouter’s Justin Summerville told CNBC that open-source Chinese models can run 60% to 90% cheaper than the leading Anthropic and OpenAI models. Vercel’s head of agentic infrastructure described one Chinese model’s daily token volume growing 27-fold in its first week after launch.

The Associated Press ran the same story that same month, quoting Mozilla’s CTO switching his own daily workflow to a Chinese model because, in his words, it “just seems snappier,” and citing a Goldman Sachs research note calling the adoption curve a “critical stage.”

So the price gap is real, and the shift is real. That’s exactly why the conversation needs to move past price, because price is the easy part to compare and the least useful part to decide on.

Price per token is the wrong question

Here’s the framing I’ve landed on, and it isn’t originally mine.

Nate B. Jones, an AI analyst I trust and read closely, put it precisely in a piece testing DeepSeek, Qwen, GLM, Kimi and MiniMax against live work: “Someone on your team wants to move a workload onto a Chinese model because it costs a fifth as much. Someone else says absolutely not. Both of them are arguing about a country. What actually decides it is a job, an endpoint, and a check.” 

That last sentence is the whole argument. Not the country the model was built in. The job, the endpoint, and the check that catches it when it’s wrong.

Jones ran one of these models inside a live multi-agent system and found a worker that reported 213 verified quotations, thirteen of which turned out to be fabricated. Thirteen stitched-together citations sitting inside output that looked, on the surface, completely clean. He describes the real replacement metric for token price as what an accepted result actually costs, and states it plainly: a cheaper model can double your review time. That’s the number nobody puts on the invoice. You don’t see it in the API bill. You see it in the extra hour your team spends checking work they used to trust.

This matches what I’ve watched happen with clients switching automation stacks. The token bill goes down. The time somebody spends re-reading output, catching a fabricated detail, or debugging a broken step in a workflow goes up, quietly, off any dashboard that tracks spend. If that extra review time costs more than the tokens you saved, you haven’t cut costs. You’ve moved them somewhere less visible. 🫤

No single model rules them all, and that’s the real argument for an architecture

Even if you ignore the cost question entirely, betting your whole operation on one model is a bad structural decision, because the leaderboard doesn’t sit still. Independent benchmarking from Artificial Analysis has shown the top intelligence score changing hands repeatedly through 2025 and into 2026, with open-weight models closing the gap to within single digits of frontier models on many tasks. Stanford’s 2026 AI Index put the gap between the leading US model and the leading Chinese model at just 2.7% as of March 2026, having traded the lead multiple times in the year before that.

You’ve also just watched what single-vendor dependency actually looks like in practice. Anthropic’s Fable and Mythos models were suspended under US export controls for weeks in mid-2026 before access was restored, a standoff CNBC covered directly in the same reporting on model adoption.

Whatever you think of the politics, the operational lesson is the same one insurance teaches: don’t build a critical process around a single point of failure you don’t control, whether that’s one vendor, one country’s regulatory posture, or one model that might get deprecated, restricted, or simply overtaken next month.

The hidden cost nobody puts on the invoice

MIT’s NANDA initiative studied 300 enterprise AI deployments and found that 95% of generative AI pilots showed no measurable impact on profit or loss. That failure rate has nothing to do with which model was cheapest. It has everything to do with organisations skipping the unglamorous work of matching the right tool to the right task and measuring what actually came back out the other end. A 20% saving on tokens that doubles your rework time it’s a cost you’ve relocated from a bill you can see to a team’s calendar you can’t. 😉

When cloud isn’t the real question, data classification is

The local versus cloud debate gets treated as a technical or cost decision, and mostly it’s neither. It’s a data classification decision. If the task involves confidential business data, client personal information, or anything GDPR governs, the question isn’t which model is cheapest or fastest, it’s whether that data should leave your control at all.

Again, this isn’t theoretical, since security researchers at Wiz found an unauthenticated, internet-facing DeepSeek database exposing over a million lines of chat logs, plaintext messages and API keys, discovered and disclosed in early 2025.

The EU’s European Data Protection Board published guidance in April 2025 naming on-premise inference as the strongest available mitigation against cross-border data transfer risk, precisely because it removes the question entirely rather than trying to manage it. DeepSeek’s own privacy policy states data is stored in the PRC, and Chinese law compels cooperation with state intelligence requests. None of that means the model is bad at the task you’re asking it to do. It means the task you’re asking it to do determines whether it should ever see that data in the first place.

Flip it around, and cloud APIs, including Chinese-hosted ones, are entirely sensible for the large share of work that isn’t sensitive: bulk content drafts, public-facing copy variants, internal brainstorming, code that touches no customer data.

You get better resources, faster iteration, and no infrastructure to maintain. The gate becomes less about a vendor’s nationality and more about whether the data classification allows it to leave your building at all.

Build the architecture, not the allegiance

Put these pieces together, and the answer stops being “which model” and becomes “what routing logic sits in front of every task.” This is what LLM routing tools exist to solve: an abstraction layer that sends each request to whichever model actually fits it, rather than locking your whole stack to one provider’s roadmap.

OpenRouter and LiteLLM are the two most widely adopted open approaches right now, and both AWS Bedrock and Azure AI Foundry now ship a native router built directly into their platforms. None of these tools makes the task-fit decision for you.

They just mean that once you’ve made it, switching a task to a different model doesn’t mean rewriting your whole system.

The architecture matters more than the allegiance. Instead of choosing a favourite model, you’re building a system that can absorb the fact that the best model for coding, the best model for bulk classification, and the best model for anything touching client data are very likely three different models, and that ranking will look different again in six months.

The framework I actually use

Before I move a task to a cheaper model, I ask four questions in order, and price is deliberately last.

1. What does the data classification allow? Can this leave the building at all?
2. What does getting it wrong actually cost, in rework hours, not in embarrassment?
3. Does the task need consistency and judgement, or does it tolerate variation because you’re testing at scale anyway?

Only once those three are answered does price get to break the tie. The table below is the shorthand version I use to sort a task before I decide anything about which model touches it.

None of this is a case against the cheap models.

Some of them are pretty excellent, and the price gap is large enough that ignoring it is its own kind of expensive. It’s a case against letting price be the first question instead of the last one.

Build the routing logic once, apply the same four questions every time, and the country a model was trained in stops being the argument. The job in front of you becomes the argument, which is the only one that was ever worth having.