Vercel reportedly disclosed that open-weight models now account for 78.4% of the token volume flowing through its AI Gateway, overtaking OpenAI specifically as the largest single category of routed traffic. That is a striking number, and it is already being read — incorrectly, in places — as proof that open models have "won" against closed frontier providers. They haven't, at least not in any way this stat can support. What it does show is worth taking seriously: on the exact workload one large infrastructure provider sees from real production apps, cost-sensitive builders are routing the overwhelming majority of their token volume to open-weight models.
This post breaks down what the 78.4% figure actually measures, why open-weight models are winning on that specific metric, and — the part that matters for anyone shipping a product — what it should change about how you pick a model for a given piece of work.
TL;DR
| Question | Answer |
|---|---|
| What is the stat? | Open-weight models reportedly made up 78.4% of token volume through Vercel's AI Gateway, overtaking OpenAI |
| Is this the whole AI market? | No — it's traffic through one gateway, whose customer base skews toward app/agent builders |
| Does "token volume" mean "spend"? | Related but not identical — cheap open models can carry more tokens for less total spend; per-token price and total spend move differently |
| Why would open models win here? | Lower cost per token, self-host or cheap third-party inference, fine-tuning control, no single-vendor lock-in, "good enough" for high-volume repetitive calls |
| Does this apply to enterprise or consumer apps? | Not necessarily — those segments still lean on closed frontier models for support, compliance, and consumer-facing quality bars |
| What should I actually do? | Route by task: cheap open-weight models for high-volume/low-stakes calls, closed frontier models where failure cost or reasoning depth justifies the premium |
What the 78.4% figure actually measures
Start with the caveat, because it changes how you should read every number that follows: this is token volume/spend through one infrastructure provider's AI gateway, not a claim about the whole model market.
Vercel's AI Gateway is a proxy layer that sits between an application and multiple model providers — OpenAI, Anthropic, DeepSeek, Z.ai, Moonshot, Alibaba, and others — behind a single API, a single bill, and unified logging. When a team wants to compare a closed model against a Kimi K3 or GLM deployment, the gateway makes that a model-ID swap rather than a new SDK integration. That convenience is exactly why gateway traffic is a useful — but narrow — window into builder behavior: it captures teams that are already inclined to shop between providers, which is a self-selected population, not a random sample of all AI usage.
Three things to keep separate when reading "78.4% of token volume":
- Token volume is not request count. A small number of huge-context batch jobs (bulk extraction, embeddings prep, agent loops with long scratchpads) can dominate token counts without representing a majority of actual product features or user-facing traffic.
- Token volume is not spend. Open-weight models are typically priced far below closed frontier APIs per million tokens, so a workload can carry the large majority of tokens while representing a much smaller share of total dollars — or the reverse, depending on how the platform aggregates the numbers. Treat "78.4% of volume" and "78.4% of spend" as related but distinct claims unless the source explicitly ties them together.
- "Overtaking OpenAI" is a comparison to one company, not to closed models as a category. Anthropic, Google, and xAI traffic through the same gateway isn't folded into "OpenAI" — so this is specifically open-weight models passing OpenAI's slice, not open models passing every closed provider combined.
None of this means the number is unreliable. It means it's a real, specific data point about a specific population — read it as "Vercel's builder segment now sends most of its gateway tokens to open-weight models," not "open models have overtaken the industry."
Why open-weight models are winning on this metric
Assume the number is roughly right for Vercel's traffic. Several forces point the same direction, and they compound rather than operate independently.
Cost per token is the dominant lever at volume
At low request counts, the difference between a frontier closed model and a cheap open-weight one is invisible on a bill. At production volume — thousands to millions of calls a day — the gap compounds fast. explainx.ai has covered this compounding effect directly: a model that looks cheaper per token can still produce a bigger bill once tokenizer efficiency is accounted for, but the broader pattern holds — open-weight models from DeepSeek, Moonshot, and Z.ai are consistently priced at a fraction of frontier closed APIs, and that gap is the single biggest driver of routing decisions once a team ships past the prototype stage.
Self-hosting and inference flexibility
Open weights can run behind Vercel's gateway via cheap third-party inference providers (Fireworks, Together, Baseten, and similar) or be self-hosted entirely, which decouples cost from a single vendor's pricing decisions. Bolt.new's Bolt Forge experiment — offering up to 50x more usage on GLM, Kimi, and DeepSeek models in exchange for anonymized training data — is a direct example of a builder-facing product leaning into this flexibility to expand usage limits without the marginal cost of a closed frontier API.
Fine-tuning control
A closed API gives you prompting and, at best, limited fine-tuning through a vendor's own pipeline. Open weights let a team fine-tune, quantize, and evaluate on their own infrastructure — a meaningful advantage for narrow, repetitive tasks where a smaller specialized model can match a frontier model's accuracy at a fraction of the cost. Vercel's own Design.md spec-driven work and its broader AI Gateway strategy point toward the same builder profile: teams that want to own the evaluation loop, not just call an API.
Avoiding vendor lock-in
Routing high-volume traffic to one closed provider means that provider's pricing changes, rate limits, or deprecations become your outage. A gateway that abstracts the model ID, paired with open weights that can move between inference providers, gives builders an exit ramp. explainx.ai's decision framework for choosing between open-weight and closed AI models covers this trade-off directly: open weight becomes economical once workload volume, hardware fit, or customization needs justify owning that operational surface — exactly the profile of a team routing bulk traffic through a gateway.
"Good enough" quality at the task level
The clearest driver is also the simplest: for high-volume, low-stakes calls — drafting, classification, extraction, summarizing, routine steps in an agent loop — a frontier closed model is frequently overkill. Once a team benchmarks a cheap open-weight model against their actual task and finds the quality gap doesn't matter for that specific job, there's no reason to keep paying frontier prices for it. This is the same "route by task, not by brand loyalty" pattern explainx.ai has tracked in enterprise model routing through OpenRouter and in Ramp's data showing enterprises skipping Fable 5's premium pricing in favor of cheaper models for routine work.
What this means practically for builders
This is squarely a "what should I actually pick and pay for" question, and the answer is not "switch everything to open weights" any more than it was "always use the newest frontier model." Use the workload, not the headline, to decide.
| Workload signal | Lean toward |
|---|---|
| High call volume, repetitive structure, well-defined evaluation | Open-weight model, cheapest that clears your quality bar |
| Low call volume, high per-call stakes (legal, medical, safety-critical) | Closed frontier model |
| Novel or ambiguous reasoning, multi-step tool use with unclear failure modes | Closed frontier model, at least until you've benchmarked an open alternative |
| Data residency, offline requirement, or need to fine-tune on proprietary data | Open-weight, self-hosted or private inference |
| Consumer-facing quality bar where a bad answer damages trust immediately | Closed frontier model, or a heavily evaluated open model with human review |
| Internal tooling, agent scaffolding, boilerplate generation | Open-weight model |
A few practical steps that follow directly from the gateway data:
- Instrument your own token spend by task type before assuming anything. The Vercel number is a population-level average across many apps; your workload mix will look nothing like it until you measure it.
- Put a gateway or router in front of your app early, even if you start on a single provider. The entire reason gateway data exists is that switching became a config change instead of a rewrite — that optionality is worth having before you need it.
- Benchmark the open-weight candidate on your actual task, not a public leaderboard. explainx.ai's guide on reading AI benchmarks is the right companion here — a model that wins a general benchmark can still lose on your specific extraction or classification task, and vice versa.
- Keep a closed-model fallback path for the tail of requests an open-weight model gets wrong, rather than treating the choice as binary.
The caveat that matters most: this doesn't generalize evenly
Vercel's customer base is developers and teams building web apps, agents, and AI features — a population that is unusually price-sensitive, technically comfortable swapping model IDs, and building workloads (chat features, agent steps, content generation) that tolerate "good enough" quality at scale. That is a real and growing segment of AI usage, but it is not the whole market.
Enterprise procurement, regulated industries, and consumer-facing products with strict brand and safety requirements still route heavily to closed frontier models — often specifically because the operational overhead of owning an open-weight deployment (hosting, security review, monitoring, update cadence) costs more than the API premium for their volume. Ramp's enterprise spend data shows this nuance clearly: even where enterprises moved away from the priciest frontier tier, they moved to a cheaper closed model (Opus 5), not necessarily to open weights — cost-sensitivity and open-weight adoption are correlated but not the same decision.
Read the Vercel figure as a leading indicator for one important, growing segment of AI-native builders — not as a referendum on the entire model market. The honest version of the headline is: for teams building high-volume, cost-sensitive apps and agents, open-weight models have become the default — and that segment is worth paying attention to, whether or not it describes your own workload yet.
Related reading
- How to Choose Between Open-Weight and Closed AI Models — the full decision framework this post's routing table is drawn from
- Bolt Forge Gives Open-Weight Models Up to 50x More Usage
- How Enterprises Use OpenRouter for Model Routing and Cost Optimization
- Opus 5 Overtook Fable 5 in Enterprise Spend — Ramp Data
- Why "Price Per Token" Doesn't Tell You What a Model Actually Costs
- Imagine Image 2.0 on Vercel AI Gateway: What It Means for Developers
- What Is Vercel? How to Deploy Your App
- How to Read AI Benchmarks
Figures in this post are drawn from reported disclosures about Vercel AI Gateway token volume; specific percentages reflect the reported measurement window and are accurate as of the publication date. Vercel's own published documentation should be checked for the most current numbers.