The model landscape in 2025-2026: closed frontier, open-weight, and reasoning

In January 2025, DeepSeek dropped R1 with an MIT license and API output pricing roughly 96% below OpenAI o1 — around $2 per million output tokens versus o1's $60. Within 48 hours, every AI infrastructure team was running the same math and asking the same question: if a Chinese open-source model matches the best US reasoning model at 4% of the cost, what exactly are we paying for?

That event compressed what would have been two years of gradual market education into a single week. It forced everyone in the field to think clearly about what the different model tiers actually offer, when the premium for closed frontier models is justified, and what "reasoning" means as an engineering concept versus a marketing claim. This article gives you that framework.

The three tiers, defined

The model market in 2025-2026 has three structurally distinct tiers. They are not just positions on a single quality axis. They differ in training methodology, cost structure, operational model, and appropriate use cases.

Closed frontier models — GPT-5 and its variants, Claude Opus and Sonnet 4.x, Gemini 3.1 Pro — are trained at scale that only a handful of organizations can afford, served exclusively by their providers, and accessible only via API. You do not see weights, cannot fine-tune at the model level, and cannot run them on your own infrastructure. The value proposition is simple: best-in-class out-of-the-box performance, no operational burden, and pricing that has dropped 30-60% since 2024 as competition intensified. As of mid-2026, output tokens for mid-tier closed models run approximately $3-15 per million (illustrative — check current provider pricing pages, as these numbers move often).

Open-weight models — Meta Llama 4 Scout and Maverick, DeepSeek V3, Mistral Large 3 and the Ministral 3 family, Qwen 3 — release weights publicly. You can download them, fine-tune them on proprietary data, run them inside your VPC, and serve them yourself. The performance gap versus closed frontier models closed dramatically: from roughly 17.5 percentage points at the end of 2023 to near-zero on knowledge benchmarks and single-digit gaps on reasoning by early 2026. But "open-weight at frontier scale" is not free. Serving Llama 4 Maverick or DeepSeek V3 in production requires a minimum of 4-8x H100 GPUs, distributed inference expertise, security patching, and ongoing MLOps overhead. The economics only favor self-hosting at frontier scale above roughly $15,000-25,000 per month in API spend — the cluster alone costs that much — with smaller models on a 2-4 GPU cluster crossing over nearer $5,000-10,000, or when data governance requirements make third-party APIs non-viable.

Reasoning models — OpenAI o1 and o3, DeepSeek-R1, Claude Opus 4 in extended thinking mode, Gemini 3 Pro Deep Think — are a genuinely different inference-time regime. They generate a long internal chain-of-thought trace before returning an answer, trained with reinforcement learning on problems that have verifiable correct answers (math, code execution, formal logic). The result is qualitatively better performance on hard structured problems: AIME math competitions, GPQA Diamond science questions, multi-step competitive coding. The cost is 3-10x higher latency and token spend per task compared to their standard counterparts. Calling a reasoning model to answer "summarize this email" is like using a GPU to add two numbers — technically works, extremely wasteful.

What changed in 2025-2026

flowchart LR
    DS["DeepSeek-R1\n(Jan 2025)\nRL-only reasoning\nMIT license"]
    L4["Llama 4 Scout/Maverick\n(Apr 2025)\nNative multimodal MoE\n10M token context"]
    M3["Mistral 3 family\n(Dec 2025)\n10-model lineup\nMinistral 3 edge models"]
    G3["Gemini 3.1 Pro\n(Feb 2026)\n1500+ Chatbot Arena ELO\nLeads 12/18 benchmarks"]

    DS --> L4 --> M3 --> G3

    style DS fill:#a855f7,color:#fff
    style L4 fill:#15803d,color:#fff
    style M3 fill:#0e7490,color:#fff
    style G3 fill:#00e5ff,color:#0a0a0f

Several things shifted the calculus between early 2024 and mid-2026.

DeepSeek-R1 (January 2025) was the single most disruptive model release since GPT-4. The key contribution was not just the performance — matching o1 on AIME 2024 — but the training methodology. Earlier open-weight reasoning attempts were trained by having GPT-4-class models generate chain-of-thought traces, then fine-tuning smaller models to imitate those traces. DeepSeek's companion R1-Zero run showed that reasoning capability can emerge from pure reinforcement learning on verifiable outcomes, with no chain-of-thought supervision at all — the model discovers reasoning strategies on its own. The shipped R1 added a small supervised cold start on curated chain-of-thought data before RL, mostly for output readability. That finding changed how researchers and engineers think about what "reasoning" actually is and whether it requires proprietary training data.

Meta's Llama 4 (April 2025) introduced natively multimodal Mixture-of-Experts open-weight models — Scout with a 10M token context window, Maverick competitive with GPT-4o. Crucially, these were multimodal from pretraining, not models with vision adapters bolted on afterward. The MoE architecture activates only a fraction of parameters per token, making inference cheaper at a given capability level than a dense model of equivalent total size.

Mistral's December 2025 family refresh gave the open-weight ecosystem a coherent lineup from frontier MoE down to Ministral 3 edge-optimized models that run on consumer hardware. The lineup matters because the choice is no longer "pick the one good open model" — it is a graduated set of trade-offs from edge to frontier.

Gemini 3.1 Pro reached the top of Chatbot Arena ELO rankings in early 2026 (as of mid-2026), leading on multiple tracked benchmarks. GPT-5, as of mid-2026, unified OpenAI's general-purpose and coding model lines and added native computer use.

The other structural change was price compression. When multiple providers are competing at frontier capability, and open-weight models become viable alternatives, closed API pricing compresses. That compression is good for teams using APIs, but it changes the open-weight economics: the savings from self-hosting shrink as the API price drops.

The reasoning model tier: when it's worth the premium

sequenceDiagram
    participant U as User
    participant RM as Reasoning Model
    participant T as "Token budget (internal)"
    participant O as Output

    U->>RM: "Solve: integral of x·sin(x)dx"
    activate RM
    RM->>T: generates chain-of-thought trace<br/>(integration by parts, verify, check signs...)
    Note over T: ~800-4000 internal tokens consumed
    T-->>RM: reasoning complete
    RM->>O: final answer
    deactivate RM
    O-->>U: "x·(−cos x) + sin x + C"
    Note over U,O: 3-10x more tokens consumed than a standard model<br/>answering the same question

Reasoning models are not just smarter — they are structurally different. A standard model reads the prompt and immediately begins generating the response token by token. A reasoning model first generates a long internal monologue (sometimes called a scratchpad), exploring approaches, checking its own work, backtracking — and only then produces the output. That internal trace consumes tokens you pay for but never see in the response.

The practical threshold: use a reasoning model when:

• The problem has a verifiable correct answer (math, formal logic, code that can be tested)
• Standard models demonstrably fail on the problem class and you have evidence of that on your actual task data
• A single correct answer is worth the 3-10x cost premium

Do not use a reasoning model for:

• Summarization, classification, or extraction — standard models are fine
• High-throughput pipelines where latency is the constraint
• Tasks where "approximately right" is acceptable and you are running thousands of queries per day

An 8B reasoning-optimized model will outperform a 70B standard model on hard math. But the same 8B model will be worse at conversational coherence and knowledge-intensive Q&A. The capability profiles genuinely differ, not just the cost profiles. See what reasoning models actually are for the full treatment of how they are trained and where they break.

Reading the numbers honestly

Benchmark math — illustrative contamination arithmetic

Say model X achieves 85% on MMLU.
MMLU has 14,000+ questions; many have been on the internet for years.
If 5% of those questions appeared in training data (a conservative estimate),
and the model memorized answers to those,
the "true" score on genuinely unseen questions is (85 − 5) / 95 ≈ 84.2%.
That is only a ~1-point haircut — but adjacent leaderboard entries
are often separated by less than a point, so even the conservative
case reorders them. At 25% contamination (plausible for benchmarks
that have been public for years), the true score drops to 80%.

Lesson: never make a final model choice from a leaderboard.
Run held-out evaluation on your actual task distribution.

Benchmark scores are systematically unreliable for production model selection. Public benchmarks (MMLU, HumanEval, MATH-500) are contaminated by training data — questions that have been on the internet long enough to appear in crawls. The community knows this; researchers have published on it; providers have financial incentives not to remove the contaminated data. The result is that leaderboard positions, especially among top models within the same tier, should be treated as rough ordering rather than precise measurements.

The right workflow is: identify your actual task, collect 100-500 representative examples, run each candidate model on that held-out set, measure the metric that matters for your product (not accuracy if you care about cost per correct answer), and pick the winner on that distribution. That is more work than reading a leaderboard. It is also the only approach that does not occasionally produce embarrassing production failures when a model that led on HumanEval turned out to perform below average on your specific code style.

Open-weight infrastructure math

Minimum viable cluster for frontier open-weight serving (mid-2026 estimates)

Llama 4 Maverick: 400B total parameters, MoE — 17B active per token
  bf16 weights: ~800 GB just for weights
  Minimum: 8x H100 80GB (640 GB HBM) — tight but feasible with quantization
  With KV cache for 100K context: add ~16-32 GB per concurrent request
  → realistically 8-12x H100 for production serving with batching

Cost: H100 cloud spot pricing ~$2-3/GPU/hr as of mid-2026 (illustrative)
  12 GPUs × $2.50/hr × 24hr = $720/day = ~$21,600/month
  
At $15/M output tokens (closed frontier API):
  $21,600/month ÷ $15 per M tokens = 1.44 billion tokens/month to break even
  At 500 tokens/output × 1K queries/day = 15M tokens/month → nowhere near break-even
  Break-even needs ~48M tokens/day → ~96K queries/day at 500 output tokens

The economics require substantial, sustained traffic.
Add MLOps FTE cost and security patching and the real threshold is higher.

This math is why the default recommendation is closed API for most teams. The per-token savings from open-weight are real, but they are offset by cluster cost, the need for distributed inference expertise (vLLM, SGLang, or TensorRT-LLM don't configure themselves), security patching cycles, and the operational risk of maintaining a GPU cluster. For a team without a dedicated ML infrastructure function, self-hosting a frontier open-weight model is not a cost optimization — it is a new job description.

The cases where it makes sense: regulated industries (finance, healthcare, defense) where data cannot leave the organization's control; teams already running significant ML infrastructure for other workloads; and products that need task-specific fine-tuning that the closed provider's API does not support.

Mixture of Experts: why model size is confusing

Llama 4 Maverick has 400 billion total parameters. It also has roughly 17 billion active parameters per token. DeepSeek V3 has 671 billion total parameters and 37 billion active. Most marketing and benchmarking talks about total parameter count; most of what determines inference cost and speed is the active parameter count.

Mixture of Experts (MoE) works by dividing the model's feed-forward layers into many specialized "experts" (typically 8-64+) and learning a routing function that, for each token, activates only a small subset. The result is a model with large total capacity — it has many expert weight matrices — but low compute per forward pass because most of those matrices sit idle for any given token. You get the generalization of a larger model at the inference cost of a smaller one.

The catch is memory: even though only some experts activate per forward pass, all expert weights must reside in GPU memory because the router makes its decision at inference time and you cannot predict which experts will be needed. For MoE models at frontier scale, this is why the memory requirements are high even though the active FLOP count per token is modest.

This is directly relevant to the KV cache and GPU memory math you need to understand before sizing a serving cluster.

What breaks

The three tiers have distinct failure modes. Knowing them in advance saves the late-night debugging session.

Closed frontier: You are dependent on a provider API. That means rate limits, latency spikes during high demand, and unilateral model updates that can change behavior without notice. If OpenAI deprecates a model version mid-contract, or Anthropic adjusts Claude's refusal behavior in a patch, your product behavior changes without any code change on your end. Mitigation: pin to specific model versions where providers allow it, maintain a routing layer that can switch to a fallback model, and treat every model API as a third-party dependency with SLA implications. See LLM reliability patterns for the circuit-breaker and retry patterns.

Open-weight: Self-hosting failure modes are infrastructure failure modes. A GPU node fails during a long request: partial output. Memory pressure from a batch of long-context requests causes OOM: crash and retry storm. Version pinning works for weights, but serving framework updates (vLLM minor versions, CUDA driver updates) can silently change output quality or throughput. Quantization for memory savings (4-bit GPTQ, AWQ) can degrade specific capability areas even when benchmark numbers look fine. The operational maturity required is higher than most teams realize before they start.

Reasoning models: The internal chain-of-thought trace is not visible to you (in most deployments), but it can go wrong in observable ways. Overthinking — the model reasons itself into an incorrect answer it would have gotten right without reasoning, by over-examining edge cases — is documented across o1 and DeepSeek-R1. Underthinking — insufficient reasoning steps for genuinely hard problems — also occurs when the model incorrectly estimates problem difficulty. Token budget constraints can cut off reasoning mid-trace. And reasoning models are significantly more expensive to evaluate at scale, which means teams often do less evaluation and catch regressions later. The failure modes for reasoning models article covers these in depth.

A cross-tier failure that applies everywhere: the model's knowledge has a training cutoff. GPT-5, Claude Opus 4, Gemini 3.1 Pro — none of them know about events after their training data ends. For products that require current information (news, prices, recent research), no model tier solves this at the model level. You need RAG with a retrieval pipeline or tool use against live APIs.

The modality dimension

The tier structure intersects with a second axis: what input types a model accepts and what output types it produces. As of mid-2026:

Model	Text	Images	Native audio	Video	Code execution
GPT-5 (flagship)	✓	✓	✓	✓	✓ (via tools)
Claude Opus/Sonnet 4.x	✓	✓	✗	✗	✓ (via tools)
Gemini 3.1 Pro	✓	✓	✓	✓	✓ (via tools)
Llama 4 Scout/Maverick	✓	✓	✗	✓	varies by serving config
DeepSeek V3	✓	✗	✗	✗	varies
DeepSeek-R1	✓	✗	✗	✗	via tools

Modality support is volatile and routinely updated. More importantly, there is a persistent gap between what a model was trained on and what the current API exposes. Claude's training involved multimodal data, but its API as of mid-2026 does not accept audio. Always verify against the current API documentation and not against capability claims in research papers or press releases. Modalities explained covers the architectural details of how vision, audio, and video are encoded and the failure modes unique to cross-modal inputs.

The decision in practice

The taxonomy here is more useful than a ranked list because model-specific benchmarks change every few months, but the tier structure is stable. The question is never "which model ranks highest on the leaderboard this month." It is: which tier is right for this problem, and within that tier, which specific model has the capability profile that matches your task.

Start with closed frontier API. The iteration speed advantage is significant: you get a curl command, not a GPU cluster provisioning ticket. The quality ceiling is currently higher for complex agentic tasks. The pricing is reasonable for low-to-medium volume. If you are prototyping, exploring a new product surface, or running below ~1 billion tokens per month, closed API is the right default.

Move to open-weight when the numbers force you to. Not because open-source is philosophically preferable, not because a blog post made self-hosting sound exciting, but because your cost projection or your compliance requirements make the closed API untenable. When you make that move, start with a model in the Llama 4 or Mistral 3 family — well-supported inference ecosystems, active communities, known behavior — rather than a newer model whose serving infrastructure is still maturing.

Reach for reasoning models when standard models demonstrably fail on your task. Run the problem class through a standard frontier model first. Measure failure rate. If it is below 10%, the reasoning premium is probably not worth it. If it is above 30% and correctness matters, reasoning models are the right tier. Cost and latency trade-offs for reasoning has the full framework for making that call, including the hybrid approach of routing easy queries to standard models and hard ones to reasoning models. The router below lets you play with that trade-off directly: shift the traffic-mix sliders and watch how far cost falls from the all-frontier baseline before quality starts to give.

{ "type": "model-router", "title": "Model routing: cost vs. quality trade-offs across tiers" }

One principle that applies across all three tiers: build with an AI gateway layer from the start. A routing layer that can swap models — same interface, different backend — is cheap to add early and expensive to retrofit. The model tier you pick today will not be the optimal choice in 18 months.