Open-Weight Models Close the Gap with Closed-Source Frontier Models to 4.4 Months: How Much Longer Will Enterprises Pay for the Lead?

Mozilla released the second edition of its State of Open Source AI report on September 15. The report’s latest assessment is that the capability gap between the best open-weight models from Chinese companies and the most advanced closed-source models from U.S. tech companies has narrowed to 4.4 months.

This does not simply mean that “an open-source model trails by a few percentage points on a leaderboard.” Compared with the first edition, released in July this year, Mozilla’s latest report goes further by examining specific models, task durations, per-task costs, and platform usage. As a result, its conclusions are closer to the questions developers actually care about: Can a model complete a task independently, and exactly how much does that task cost?

The most notable point in the report is not that open-weight models have fully caught up with closed-source models, but that the nature of their competition has changed. Closed-source models still lead in complex, long-chain, specialized tasks, but their lead is narrowing. Open-weight models, meanwhile, are rapidly capturing everyday workloads through lower inference costs, stronger deployability, and more flexible routing capabilities.

From “3% Behind in Performance” to “Able to Work Independently for Several Hours”

The first edition of the report, released in July this year, used a relatively broad metric to describe the gap between open models and proprietary models such as ChatGPT and Claude: the overall performance gap for top open models was approximately 3%.

This figure is easy to misinterpret. A gap in aggregate benchmark scores does not necessarily correspond to a comparable gap in real-world development workflows. A model might trail by only a few percentage points on average across dozens of tests, yet be unable to complete an entire task in a real project because it cannot consistently handle context, tends to drift from its objective midway through, or lacks reliable tool-calling capabilities.

The new report introduces METR’s “task time horizon” metric. It measures how long a human task a model can complete independently while maintaining a 50% reliable success rate. Here, “time” does not refer to how long the model takes to generate an answer, but rather to how many hours a human expert would typically need to complete the same task.

According to the report:

• The best open-weight models can currently reliably complete tasks lasting approximately 7 hours;
• The best closed-source frontier models can complete tasks lasting approximately 12 hours;
• The task duration that closed-source models can handle is about 1.7 times that of open models;
• Mozilla expects that in approximately four months, the capability range of open models may extend to 12 hours, while closed-source models may reach approximately 20 hours.

This metric is more like comparing the “continuous-work radius” of two engineers. Open models can already handle everyday tasks such as code completion, test generation, document organization, data transformation, and routine analysis. However, they are still more likely to lose control when dealing with work that requires long-term planning, repeated verification, cross-file modifications, and sustained tool use.

Therefore, 4.4 months does not mean that “all capabilities differ by only 4.4 months.” It is closer to an estimate of the overall rate at which capabilities are catching up. For specific tasks, the gap may be only a few weeks—or it may still exceed a year.

Kimi K3: Comparable Capabilities at a Significantly Lower Price

The Mozilla report specifically highlighted Kimi K3 from Moonshot AI. According to the Artificial Analysis Intelligence Index cited in the report, Kimi K3 scored only three points below Anthropic’s Fable 5, while its per-task cost was approximately 30% of the latter’s.

The value of this comparison lies not in which model has the higher overall score, but in the fact that it places the “capability gap” and the “price gap” side by side. If a complex task costs 1 yuan to complete with Fable 5, a similar task would cost approximately 0.3 yuan with Kimi K3. Even after factoring in failure retries, context caching, concurrency scheduling, and human review costs in actual business operations, the price difference remains large enough to change architectural decisions.

The report also mentioned GLM 5.2: on certain tasks, its per-task cost is approximately one-fifth that of the closed-source model used for comparison.

It is important to emphasize that “per-task cost” is not simply a comparison of input and output token prices. It usually also incorporates the number of calls required to complete the same task, failure rates, context length, and the number of tool calls. A model that is inexpensive but frequently requires retries may not necessarily be more economical than a higher-priced model. However, if an open-weight model has already reached a sufficient level of reliability for most routine tasks, its cost advantage will be amplified at scale.

For search, customer service, code analysis, and content moderation systems that process millions of requests every day, reducing per-request costs by three or five times is not a minor change in the decimals of a financial statement. It can determine whether the volume of model calls can continue to expand.

The Premium for Closed-Source Models Is Concentrated in 8-to-12-Hour Tasks

Raffi Krikorian, Mozilla’s chief technology officer, offered a straightforward explanation of the gap: The premium for closed-source models is mainly reflected in specialized tasks that require eight to twelve hours of continuous work. Open-weight models, meanwhile, are already inexpensive and practical enough to cover a large volume of everyday work.

This means that closed-source models have not lost their value. Rather, the boundaries of that value have become clearer.

The following tasks are still better suited to leading-edge closed-source models:

• Architecture-level modifications across multiple code repositories, with tests run continuously;
• Research-oriented tasks requiring long-context memory and multi-step planning;
• Complex analysis in high-risk financial, legal, and medical scenarios;
• Agent workflows requiring multiple tools to collaborate, execute over long periods, and correct errors automatically;
• Enterprise systems with strict requirements for result stability, traceability, and service levels.

In the following scenarios, however, the cost-effectiveness of open-weight models is already difficult to ignore:

• Question answering over internal enterprise knowledge bases and document summarization;
• Code completion, unit testing, and routine refactoring;
• Batch classification, extraction, cleansing, and structured processing;
• Content moderation, customer-service routing, and marketing material generation;
• Businesses sensitive to data residency, private deployment, or vendor lock-in.

In other words, enterprises no longer need to answer the binary question of “open models or closed-source models.” They need to answer the question: “Which types of requests should be assigned to which types of models?”

OpenRouter’s Rankings Show That Developers Are Voting with Their Feet

The report cited model-call data from OpenRouter in August 2026: By token usage, eight of the platform’s top ten models offered open weights.

This data says more than a developer survey would. Surveys reflect attitudes; token usage reflects production behavior that has already occurred. Developers may praise the most powerful closed-source models at conferences, but when request volumes actually rise, cost, latency, availability, and control over data will force teams to reconsider their choices.

It is also necessary to distinguish “open weights” from “open source” in the traditional sense. Open-weight models typically allow users to obtain the model parameters and deploy them independently, but their training data, complete training process, data licenses, and safety evaluations may not all be publicly available. Calling them “open-source models” is convenient, but it may obscure licensing and commercial-use restrictions.

For developers, more practical criteria include:

1. Whether the weights can be downloaded and whether commercial use is permitted;
2. Whether complete inference frameworks, quantized versions, and deployment documentation are provided;
3. Whether long-context processing, function calling, and structured output are stable;
4. Whether the model can run on the team’s existing GPU or cloud resources;
5. Whether previous versions remain reproducible after the model is updated;
6. Whether the community has sufficient experience with evaluation, fine-tuning, and troubleshooting.

Open models require considerably more engineering work than pure API-based closed-source services along these dimensions, but they also provide greater control in return.

One-Third of Usage, but Only 4% of Revenue

The Mozilla report reiterated a stark commercial disparity between open and closed-source models: Open models account for approximately one-third of actual AI usage but receive only about 4% of revenue, while closed-source models capture approximately 96% of revenue.

The report notes that this revenue data covers the period from May to September 2025. It shows that the scale of model usage and the revenue scale of model companies are not the same thing.

Open-weight models can be downloaded, copied, quantized, and deployed on third-party infrastructure. They may generate large volumes of tokens without converting every call into API revenue for the model provider. Closed-source models, by contrast, bind capabilities, computing power, and the access point into a single service, allowing providers to charge directly for every token, request, and enterprise account.

This is one reason closed-source labs continue to maintain high prices. Training frontier models, purchasing GPUs, building data centers, and maintaining inference services all require enormous capital investment. If open models continue to push down market prices, the profit margins and financing logic of closed-source companies will be affected.

Conversely, however, lower prices for open models may accelerate market expansion. In the past, enterprises may have used large models only in a few critical workflows because prices were too high. Once costs fall to one-third or even one-fifth of their previous levels, models can enter more internal systems and generate more real demand. The model market may consequently shift from “a small number of high-priced calls” to “large-scale, low-priced calls.”

A DoorDash-Style Hybrid Routing Strategy May Be the More Practical Answer

The report noted that DoorDash has adopted Kimi for routine tasks while retaining Fable for more complex work. This combination is not new, but it represents the shift in enterprise AI architecture from “choosing the single strongest model” to “building a model-routing layer.”

A mature routing system typically assigns requests to different models based on task type, context length, latency requirements, risk level, and budget:

• Simple classification, summarization, and rewriting are assigned to inexpensive open models;
• Routine code generation and data extraction are assigned to medium-capability models;
• Long-chain reasoning, complex agents, and high-risk decisions are escalated to frontier closed-source models;
• When the primary model times out, is rate-limited, or produces unstable results, the system automatically switches to a backup model.

The difficulty of this architecture lies not in deciding which API to call, but in defining the “escalation conditions.” For example, whether the model output passes structural validation, whether code tests pass, whether citations are supported by retrieval results, and whether confidence falls below a threshold can all serve as routing signals.

The smaller the capability gap between models, the greater the value of the routing system. Once open models can handle 70% to 90% of requests, it is more reasonable to send the remaining difficult problems to expensive closed-source models than to route every request through a closed-source model.

What Does This Report Not Prove?

Mozilla’s conclusions are important, but they should not be interpreted as evidence that open models have fully caught up with closed-source models.

First, task-time metrics depend on the test set and evaluation methodology. The fact that a model can complete seven hours of work on benchmark tasks does not mean it can run reliably for seven hours across all real-world work. Enterprises must also consider hallucination rates, data-leakage risks, tool-call failure rates, long-context degradation, and exception-recovery capabilities.

Second, cost comparisons can be heavily influenced by deployment conditions. API pricing, GPU rental prices, depreciation of self-hosted clusters, electricity, operations staff, and losses from model quantization can all change the final bill. The “low cost” of an open-weight model does not necessarily mean zero cost for a small team. Only when call volumes are sufficiently high is it easier to amortize the fixed costs of private deployment and inference optimization.

Third, model versions are changing extremely quickly. The Mozilla report reflects the competitive landscape as of September 2026. Closed-source providers may widen the gap again through new training methods, toolchains, and reasoning modes, while open models may catch up within a few months. The 4.4-month figure is a dynamic window, not a permanent conclusion.

What This Means for Developers

For teams building AI products, the more worthwhile course of action today is not to bet on a single model, but to design systems that are replaceable, evaluable, and routable.

At minimum, teams should do four things:

1. Build an internal task set. Do not rely solely on public leaderboards. Incorporate real user requests, code repositories, knowledge-base documents, and edge cases into evaluations.
2. Calculate costs by task. Track tokens, number of calls, retry rates, latency, and human review costs rather than comparing only official input and output prices.
3. Maintain multi-model interfaces. Make model providers replaceable and avoid deeply coupling business logic to a particular vendor’s proprietary capabilities.
4. Turn failure handling into a system capability. Timeout retries, output validation, fallback models, human takeover, and audit logs often have a greater impact on the online experience than a few points of difference on a model leaderboard.

If a team is already using different models such as GPT, Claude, Gemini, DeepSeek, Kimi, or GLM, an aggregation gateway compatible with the OpenAI format, such as OpenAI Hub, can be used to unify model access and switching. However, an aggregation platform solves access and routing problems; it cannot replace an enterprise’s own offline evaluations, permission management, and data governance.

Conclusion: Closed-Source Models Still Lead, but That Lead Is Becoming Expensive

What Mozilla’s second report truly changes is not the ranking of any particular model, but the way the industry measures model value.

In the past, enterprises were often willing to pay a premium for the “strongest model” because the capability gap was sufficiently large and alternatives were not yet mature. Today, open-weight models can cover a large volume of routine work and offer advantages in cost, deployment flexibility, and independence from vendors. Closed-source models remain suitable for the most complex, critical, and stability-sensitive tasks, but they must prove that their additional capabilities are worth several times—or even more—the price.

For developers, the most rational strategy is not to wait for open models to completely defeat closed-source models, but to put both into the same observable and switchable system starting today. Frontier closed-source models can handle the hardest problems, while open-weight models can take on the largest volume of requests. As the 4.4-month capability window continues to shrink, the truly competitive advantage may no longer lie in any single model, but in the engineering system capable of routing different models to the right tasks.

References

• ITHome: Mozilla Report: The China–U.S. AI Model Capability Gap Has Narrowed to 4.4 Months — An overview of the core data, model cost comparisons, and task-time-horizon metric in the second edition of Mozilla’s State of Open Source AI report.