Best Model for Startups: Optimise for Switching, Not Picking

The question a startup asks is which model to build on. The question that actually determines the outcome is how much it will cost to change that decision in six months, because you will change it.

The field moved substantially in the first eight months of 2026 alone. Any model you pick now will be superseded, repriced, or made irrelevant by something released before your Series A. Building as though your choice is permanent is the mistake.

Switching cost is the number to minimise

Most of what makes a model hard to replace is not the model. It is everything you built around it: prompts tuned to its quirks, output parsing that assumes its formatting, evaluations that only exist as somebody's intuition, and a provider SDK threaded through forty files.

Keep that surface small deliberately. Put every model call behind one internal interface so the provider appears in exactly one module. Prefer an OpenAI-compatible endpoint, because that shape is close to a de facto standard and swapping providers becomes a base URL and a key rather than a refactor. OpenAI-compatible APIs explained covers what that actually buys you.

Write your evaluations down. Twenty real tasks with expected outcomes, runnable in an afternoon, is the artefact that makes switching a measurement rather than a debate. Without it, every model change becomes a week of arguing about vibes, which is why teams that lack one end up frozen on whatever they chose first.

That evaluation set is the single highest-return thing an early team can build, and it takes about a day. Benchmarking models on your own work covers building it.

Unpredictable spend is more dangerous than high spend

A startup can budget for an expensive model. What it cannot absorb is a bill that varies by a factor of five month to month for reasons nobody can explain.

Agentic features are where this happens. Cost scales with steps taken, steps taken depends on task difficulty and model reliability, and neither is knowable in advance. A feature that costs eight cents per invocation in testing can cost two dollars against real user input, and you find out at the end of the month. Why agent costs are unpredictable covers the mechanism.

Instrument from the first week. Log tokens in and out, per request, tagged by feature and by customer. This is a few hours of work at the start and effectively impossible to retrofit once you have traffic, and without it you cannot answer whether a feature is profitable.

Set hard caps per user and per feature, not just an account-level alert. An alert tells you after the money is gone; a cap stops it. This matters most for anything user-triggered, where a single pathological input can run up an unbounded bill.

Licence terms become load-bearing when you sell access

Most startups treat model licences as somebody else's problem, right up until they are shipping a product that exposes model capability to customers. Then the terms matter commercially.

GLM-5.2 and both DeepSeek V4 variants are MIT licensed, which is about as unrestricted as it gets — you can host them, modify them, and build a product on them without a conversation. Qwen is permissive across most tiers.

Kimi K3 and K2.6 are not MIT. K3 ships under Moonshot's own licence, which includes a revenue threshold above which model-as-a-service use requires separate terms. If your product is essentially reselling model access, that clause is directly relevant and worth reading before you build on it, not after.

This does not make K3 a bad choice — it is the strongest open-weight model in several respects. It makes it a choice with a commercial dependency you should be aware of. Open weights versus open source covers why these distinctions matter.

Do not self-host early

Self-hosting looks like a margin improvement and is almost always a distraction at this stage.

You would be committing engineering time you do not have to an infrastructure problem that a provider has already solved, in exchange for savings that only materialise at sustained volume you probably do not have. Meanwhile the GPU charges the same whether you are at peak load or at 3am on a Sunday, and utilisation is exactly what an early-stage product cannot guarantee.

The crossover point is real but higher than most teams estimate, largely because they omit the engineering time and the on-call burden. Self-hosting versus managed API cost works it through.

Revisit at genuinely high sustained volume, or when a customer contract requires data residency. Until then, an API keeps your team working on the product.

Pick per feature, not per company

The instinct is to standardise on one model. Resist it, because different features have genuinely different requirements and standardising means overpaying on most of them.

A user-facing feature where someone waits for a response needs low latency and moderate capability. A background enrichment job needs cheap tokens and nothing else. A code-generation feature that your product's value depends on justifies the frontier tier.

Once your model calls sit behind one interface, per-feature routing is a configuration decision rather than an architectural one, and you can move any feature independently as prices and capabilities change. Model routing and fallbacks covers the pattern, including using a second provider as a fallback so an outage is degraded service rather than downtime.

A reasonable starting configuration

For the feature your product is built on, GLM-5.2 — strong on coding and long-horizon work, MIT licensed so there is no commercial conversation to have, and two reasoning effort levels to control spend as usage grows. Around $1.40 in and $4.40 out per million.

For background and high-volume work, DeepSeek V4 Flash at roughly $0.14 in and $0.28 out. Same permissive licence, cheap enough that the volume stops being a planning concern.

Where your product genuinely competes on output quality and the margin supports it, Kimi K3 — best-in-field long-horizon results, at $3 in and $15 out, with the licence caveat above if you are reselling access.

The decision rule: build the interface and the evaluation set first, instrument spend from day one, and treat the model itself as the most replaceable component in your stack. AI budgeting for small teams covers what to expect as headcount grows.