Is the AI Model Becoming a Commodity?

In This Issue

• What Vercel's latest production data reveals about model switching, spending, and pricing.

• Why interchangeable model APIs do not guarantee interchangeable results.

• Where models are becoming economically substitutable, and where capability still commands a premium.

• How to evaluate model alternatives using production outcomes rather than token prices alone.

The signal: models are becoming easier to replace

In September 2026, nearly half of eligible teams using Vercel AI Gateway changed their most-used AI model. Almost one-third changed their most-used model developer.

This is one of the clearest signs that AI model selection is becoming more fluid.

Vercel's October Production Index also reports that open-weight models processed 71.5% of gateway tokens while accounting for approximately 23% of estimated spending.

Meanwhile, the average price per token was 47% below its December 2025 level.

The numbers suggest an increasingly competitive market, where customers can experiment with alternatives and direct more workloads toward lower-cost models.

But another number complicates the commodity argument.

Total estimated gateway spending in September was approximately thirteen times December's level.

Organizations were spending much more on AI even as average token prices declined.

The market is expanding, and its economics are changing. That does not establish that the underlying models have become equivalent.

Vercel's measurements describe traffic routed through its own gateway. Spending is estimated from published prices, and switching rates apply to qualifying paid teams.

They are useful evidence of behavior within a substantial production environment, not a representative census of all enterprise AI usage.

The central question is what this behavior actually proves.

What does commodity mean for an AI model?

A commodity is a product that buyers can substitute for another supplier's product with limited consequences.

In a mature commodity market, supplier differences are small enough that price, availability, and delivery conditions become primary purchasing factors.

AI models do not meet that definition consistently.

One model may classify routine documents as accurately as another. The same two models may perform very differently when asked to debug a complex codebase, analyze a difficult contract, or execute a multi-step workflow.

There are three separate developments worth distinguishing.

Standardized access: Multiple models can be called through similar APIs, common SDKs, and model gateways.

Economic substitutability: Different models can satisfy the requirements of a particular workload at an acceptable cost.

Capability equivalence: Different models can produce comparably good results across the relevant range of tasks.

The first is becoming widespread.

The second is increasingly achievable for selected workloads.

The third remains highly dependent on the task.

Confusing these developments leads to bad procurement and architecture decisions.

What the production evidence actually shows

Vercel's October report offers more than a snapshot of market share.

It shows how customers behave when switching becomes easier.

Since December, teams processing at least 10 million tokens through the gateway used an average of 15 model versions. Teams processing at least one billion tokens used an average of 42.

That does not mean each team replaced one model 42 times. Some may use multiple models simultaneously, and each model version counts separately.

Still, the numbers demonstrate substantial experimentation and multi-model usage.

Another finding is especially revealing.

In September, 68% of teams that increased spending on open-weight models also increased spending on closed-weight models.

Organizations were not necessarily abandoning premium models when they adopted cheaper alternatives.

They were using more of both.

This is consistent with workload segmentation: lower-cost models handling high-volume tasks while more capable or specialized models serve work where their differences justify the price.

Vercel also found that Anthropic's Claude Opus 5.5 captured more than one-tenth of gateway spending during its first two weeks.

Customers still allocated significant budgets to premium capability.

The evidence therefore supports increasing substitutability in parts of the market, not universal commoditization.

Why capability differences still matter

On October 27, Artificial Analysis introduced version 5 of its Intelligence Index.

The benchmark combines evaluations covering knowledge work, coding, science, and general capabilities.

Sixty percent of the new index uses private test sets or held-out answers, partly to improve the usefulness of the measurements as public benchmarks become familiar to model developers.

Its published comparisons continue to show substantial differences between models.

Leading proprietary models remain ahead of currently released open-weight alternatives on the composite index.

That does not mean proprietary models are always the best choice.

A composite benchmark is not a measurement of every customer's workload. Rankings can change with task selection, evaluation methodology, and model configuration.

A smaller model may be entirely sufficient for a narrow classification task even if it performs poorly on advanced scientific reasoning.

But the benchmark evidence does contradict the claim that AI models have become broadly equivalent.

Capability remains a differentiator.

The size of that differentiation depends on the work being performed.

Four dimensions that determine model value

1. Quality

Quality means the model produces an acceptable outcome for the assigned task.

The requirements may involve accuracy, completeness, instruction following, structured output validity, or correct use of tools.

For a document classifier, quality might be measured by precision and recall.

For a coding agent, it might be whether the proposed change passes tests and can be safely merged.

A model that performs well on a general benchmark can still fail a specific business requirement.

The relevant comparison is between results on representative application tasks.

2. Performance

Performance includes latency, throughput, and consistency under load.

A model may produce excellent answers but be too slow for an interactive workflow.

Another may respond quickly but struggle with complex tasks.

Some workloads need low time to first token. Others need high throughput or fast completion of a long-running task.

These are different operational requirements.

Model choice must reflect the experience or service level the application actually needs.

3. Reliability

Reliability is broader than whether the model endpoint is available.

It includes consistent output formats, successful tool use, predictable failures, retry behavior, and recovery from interruptions.

A model that occasionally generates invalid structured output may create expensive downstream failures.

A model that makes incorrect tool calls can introduce operational or business risks.

Provider uptime also matters, but it is a separate measurement from application correctness.

4. Operational cost

Token pricing is only one part of the cost.

The application may consume additional tokens through reasoning, retries, context expansion, tool calls, and repeated execution.

There may also be infrastructure costs, gateway charges, evaluation expenses, and human review.

A cheap model can be expensive when it repeatedly fails to complete the task.

The useful metric is cost per successful, accepted outcome.

The economics of a model switch

Consider a hypothetical document-processing workflow.

Two models are evaluated against the same 1,000 documents.

Model B is considerably cheaper on the initial calculation.

But suppose each rejected output requires manual review costing $0.50.

For 1,000 attempts:

• Model A costs $20 for inference and $10 for review, totaling $30.

• Model B costs $8 for inference and $75 for review, totaling $83.

This simplified example excludes resubmission, infrastructure overhead, and the value of differing failure consequences.

It demonstrates why per-token savings cannot establish total savings.

The correct model depends on the economics of completed work, including the cost of errors.

When models really are substitutable

Model substitution works best when a task has a narrow scope and a measurable acceptance standard.

Examples include extracting predefined fields, categorizing support requests, producing constrained summaries, or drafting content that is reviewed before use.

Several models may meet the minimum quality threshold.

At that point, cost, latency, availability, and contract terms become stronger differentiators.

A premium model may provide no meaningful business benefit if a less expensive alternative already satisfies the task's requirements.

The commodity-like behavior is therefore emerging at the workload level.

It does not require all models to offer equivalent intelligence.

It requires multiple models to perform one defined job well enough.

When not to treat models as interchangeable

Substitution becomes more difficult when the task involves complicated reasoning, long context, multi-step tool use, or costly errors.

An autonomous coding agent may require a different model from a routine code classifier.

A financial workflow that recommends an action may require stronger validation than an internal summarization tool.

Differences in tool-calling behavior, context management, structured outputs, and model-specific capabilities may require application changes.

A shared API makes integration easier.

It does not eliminate differences in behavior.

Even switching between providers serving the same model can introduce changes in latency, availability, configuration, and commercial terms.

Portability must be demonstrated at the application level.

The move: establish a model substitution threshold

Choose one production workload with a meaningful volume of requests.

Identify the minimum acceptable quality, latency, reliability, and cost requirements.

Then evaluate the current model against two alternatives using the same representative dataset.

Record output acceptance, task completion, end-to-end latency, retry frequency, human review, and full cost.

Before switching, define the threshold at which the alternative becomes acceptable.

For example:

• At least 97% accepted outputs.

• No increase in critical errors.

• End-to-end latency within the application's service requirement.

• Lower total cost per accepted task.

• A verified fallback or rollback procedure.

These are example thresholds, not universal recommendations.

Set limits according to the consequences of failure in the actual workflow.

Run the alternative in shadow mode or on a controlled share of traffic before routing production decisions through it.

Continue monitoring after the change.

A successful benchmark does not guarantee that performance will remain stable when data, workloads, or model versions change.

What this means for the market

AI model developers face growing pressure from falling average token prices and increasing customer choice.

At the same time, production usage and spending continue to expand.

This creates room for different kinds of suppliers.

Low-cost models can compete for high-volume workloads. Premium models can command higher prices when their additional capabilities improve outcomes.

Cloud platforms and gateways can compete on reliable access, routing, billing, and operational controls.

Application vendors can create value by combining suitable models with data, workflows, evaluations, and business-specific logic.

The most important change may be that the model no longer needs to define the entire application.

An organization can design a workflow, establish acceptance criteria, and select the model that meets those requirements.

As the market evolves, it can repeat the evaluation.

That does not make models identical.

It makes model selection an ongoing operational decision.

Worth reading

Vercel: Open weight takes 71.5% of tokens and 23% of spend

The October 2026 Production Index examines real gateway traffic, model switching, token-price trends, and spending patterns, with methodology notes explaining the limits of those measurements.

Takeaways

For builders: Design model interfaces for substitution, but verify quality and feature compatibility before switching. Common APIs do not guarantee common behavior.

For operators: Measure accepted outcomes, latency, retries, and failure costs. The lowest token price may not produce the lowest operating cost.

For leaders: Treat AI models as a portfolio of capabilities. Use competitive pressure where alternatives meet requirements and pay for premium capability where it produces measurable value.

The AI model is becoming easier to buy, compare, and replace.

That is not the same as becoming a commodity.

The deciding factor is whether another model can deliver the same required business outcome at a better total cost.

If this post helped you, leave a comment or your reaction. I’d like to hear where you landed.

Note: Third-party company and product names belong to their respective owners and are used for identification and illustrative reference only.