Mozilla's 6 Open Source AI Recommendations Every Business Should Be Watching

I have been saying for a while that the model is not the moat. The harness is the moat.

That was my own conclusion from watching the ecosystem change in real time and using open models in actual work. Now Mozilla has published a 91-page report that gives the argument a much stronger evidence base, then pushes it further than I have been pushing it myself.

Mozilla's State of Open Source AI 2026, Volume 1.1 says the next strategic fight is not only over model capability. It is over the harness, permissions, state, pricing, post-training, and the shape of the ecosystem around the model.

One important qualification: Mozilla uses “open” in a narrower, practical sense here. Unless it says otherwise, “open” means downloadable weights. That is not the same as the Open Source Initiative's fuller definition, which asks for the freedoms, data information, code, and parameters needed to study, modify, and share an AI system. Of the 16 prominent releases Mozilla examines, none provides that complete recipe. Open weights are strategically valuable, but the label should not do more work than the evidence supports.

That matters because the model market is moving too quickly for a business to build its identity around one model vendor. A strong model today can be a middling choice six months from now. A model that costs too much, loses access, changes its policy, or gets surpassed by a cheaper alternative can become a business problem long before it becomes a technical failure.

I would not put a hard percentage on how much enterprise work open-weight models can cover. My own guess is that the number is high, and rising. Some of the best open-weight models are already as good as frontier models from a year ago, and they are getting uncomfortably close to the current frontier on a lot of ordinary work. The important advantage is not that every open model wins. It is that a business can keep looking, measure cost per task, and swap in a better model without rebuilding everything around it.

Mozilla's report turns that instinct into six recommendations. They are presented as bets on keeping the open layer open. Read together, they are something more useful: a checklist for making your AI system replaceable.

The model can change. Your harness, state, authority, and ability to improve the system should not disappear with it.

1. Make the harness swappable

This is the recommendation that landed closest to home for me. Mozilla's first bet is to standardize both the wire format a harness uses to talk to a model and the state the harness exports when you leave.

A harness is more than a wrapper around an API. It is the operating layer that decides which model gets a task, which tools the model can call, what context it receives, how results are checked, when a human must approve an action, and what the system remembers afterward. That is where the useful behavior accumulates.

Look at how much a modern model interface already contains. OpenAI's Responses API supports stateful interactions, tools, file search, web search, computer use, and function calling. Those are valuable capabilities. They are also reasons an organization can become attached to the interface around a model, not only to the model itself.

Mozilla's report makes the point with a useful warning: the harness can change what a model is able to do in practice. In one comparison, bringing a different harness to the same model moved its benchmark result by 21.8 points. After the labs pulled their own harnesses in-house, that advantage compressed to roughly three points. The figures are directional and benchmark-specific, but the implication is hard to miss. The model is only one part of the system being evaluated.

The practical response is to create a model boundary that your organization owns. Keep provider adapters at the edge. Keep task definitions, tool contracts, evaluation fixtures, approvals, and state exports in formats you can test without the provider. Run the same task set against several models before you decide that one of them is indispensable.

I wrote about this more directly in the earlier argument for an open agentic harness. Mozilla's report gives that argument a wider frame. The harness is not merely a convenience layer. It is where your replaceability lives.

2. Solve portable permission

Authentication and authorization are not the same thing, and an enterprise agent needs both. Authentication answers who the agent is. Authorization answers what it may do, which data it may touch, where that data may go, and when its authority expires.

The distinction becomes obvious as soon as an agent can write a file, send a message, approve a purchase, alter a record, or move a document between systems. The permission decision has to cover the action, the data, the destination, the budget, the duration, the revocation path, and the history of what the agent has already done.

The Model Context Protocol authorization specification is useful here, but its scope is narrower than many architecture diagrams imply. It defines transport-level authorization for HTTP-based MCP implementations, including OAuth flows, metadata discovery, PKCE, access tokens, and server-side validation. Those are necessary controls. They do not amount to a portable policy language for cumulative agent authority, data destinations, spending limits, or organizational approval rules.

That gap matters because the harness is where permissions become behavior. If each model vendor defines its own tool policy, approval flow, and audit vocabulary, changing models also means changing the way your organization grants authority. The result is a system that can swap intelligence more easily than it can swap accountability.

Businesses should define permissions outside the model interface. A tool request should be evaluated against a policy that can say what action is proposed, what data it touches, where the data may go, how much it may cost, who approved it, and when that approval expires. The policy should survive a model change.

This is also where the distinction between connectivity and control matters. MCP can help agents connect to tools. It does not remove the organization's responsibility to decide what those connections are allowed to do.

3. Own the state

Memory is where a replaceable model becomes an irreplaceable product.

Mozilla's report treats memory, session state, and cache as a new form of lock-in. It cites a 10-to-30-times gap between cache hits and misses in some workloads, with a larger peak in its cited summer data, and notes that there are no portable standards for cached context. These figures are a point-in-time report finding, not a universal price law. The strategic problem is clear either way: a provider can make accumulated context expensive to move, impossible to restore, or useless outside the model that created it.

Enterprise governance should treat state as a set of controlled assets, not as one undifferentiated blob of context. Before you promise portability, decide what must survive a model change:

• Interaction state: conversation history, task status, and agent plans.
• Organizational memory: durable facts, preferences, source references, and provenance.
• Operational state: tool results, approvals, permissions, retries, and audit events.
• Evaluation state: test cases, outputs, scores, failure labels, and model or version identifiers.
• Performance state: cache entries, embeddings, retrieval indexes, and routing history.

Each class needs an owner, retention rule, export format, deletion path, and a test that proves another harness can restore it. If you cannot answer those questions, you do not own the state yet.

It also means deciding what should not be remembered. A portable system needs retention rules, deletion rules, provenance, and a way to distinguish a user's instruction from an agent's inference. Otherwise, exporting state just exports a new kind of confusion.

The business test is simple: if your provider disappeared tomorrow, could you reconstruct the useful context of an active workflow somewhere else? If the answer is no, the model is not the only thing you rented.

4. Break the meter

Token price is not the same thing as the cost of getting useful work done.

Cost per task is the enterprise metric. It includes retries, output review, latency, tool failures, and the human work needed to accept the result. A model can be cheap per token and expensive per completed job.

Take public benchmarks with a pound of salt. They are useful for a rough shortlist, not a procurement decision. The only way to know what a model can do for your business is to run it through your harness against production-like workloads and measure completed-task cost, quality, latency, and review burden.

A cheap model that needs twice as many attempts, produces longer outputs, or demands expensive review may be more expensive per completed task. A model with a higher token price can be the better choice if it solves the task reliably on the first pass. This is why businesses need cost-per-task measurements, not only price tables.

Mozilla cites an AT&T routing program that cut task costs by as much as 56 percent while accepting a 2 percent quality reduction. The report also cites a 2.3-to-4.6-times increase in DeepSeek output pricing during an August repricing. Both examples need their original context and should not be generalized into a permanent market rule. They do make the strategic point: the meter can move, including inside an ecosystem that was supposed to provide an escape from closed-provider pricing.

The answer is not to route every request through an elaborate maze. It is to own the router, measure the outcome, keep a second source warm, and self-host workloads whose demand is predictable enough to justify it. The router should be able to choose on cost, latency, quality, policy, and availability. It should also be able to stop using a provider without taking the product down.

Token-maxing is not a strategy. A strategy is knowing what a completed task costs, knowing why that cost changes, and retaining enough control to respond when it does.

5. Own the loop

Post-training is moving capability work into reach of organizations that could never afford to pretrain a frontier model. That changes who can build a useful model, but it also changes what businesses need to protect.

Mozilla's report cites two post-training passes that lifted an unchanged DeepSeek model by 10 and eight points on its cited index. Those are reported capability gains, not a promise that every company can buy the same result.

The right enterprise question is not what the training run cost in isolation. It is what changed afterward: cost per completed task, task volume, acceptance or error rate, review time, and the cost of running the tuned model at production volume. Without that before-and-after, a training price is just a large number, not a business case.

The durable asset is not only the tuned checkpoint. It is the loop that produced it: the task distribution, the examples, the evaluation set, the reward function, the failure taxonomy, the adapter, the deployment configuration, and the decisions about what counts as good enough. That collection is an operational description of the business.

If a managed training platform keeps the useful parts of that loop inside its own service, the organization may improve a model without owning the improvement. The next provider can offer a better base model and still leave the customer unable to reproduce the behavior that made the old one valuable.

Keep the training and evaluation artifacts in a portable repository. Record which data was used, which data was excluded, what the reward function measured, and where the model failed. Treat a post-training run as an organizational asset, not as a button press in somebody else's dashboard.

6. Make the open default plural

Open does not automatically mean independent.

In the report's August OpenRouter snapshot, eight of the ten highest-volume models were open-weight, and seven of those were Chinese-built. That is a useful signal about where capability and economics are moving. It is not a census of enterprise AI, and it is not a judgment about the quality or safety of a model based on where it was built. OpenRouter's own methodology says its rankings measure traffic routed through OpenRouter, not the whole market, and that token volume is not the same as requests, users, spend, or quality.

Mozilla's sixth recommendation is about avoiding a new kind of monoculture. A commons with one supplier is still dependent, whether that supplier is an American closed lab, a Chinese open-model ecosystem, a single gateway, or one runtime that every other component quietly assumes.

Plurality means more than keeping two model names in a configuration file. It means maintaining viable alternatives across model origin, provider, runtime, gateway, license, and operating environment. It means testing whether your permissions, state, and task evaluations still work when the alternative is actually used.

The goal is not to pick a geopolitical favorite. The goal is to avoid inheriting one builder's blind spots because nothing else was funded, tested, or made easy enough to deploy.

That is why the open ecosystem needs to remain plural even when one model is currently the best deal. The point of optionality is to preserve the ability to disagree with the market later.

These six recommendations are really one recommendation: own the exit.

Use a closed frontier model when it earns the dependency. Use an open-weight model when it offers the better economics, control, or fit. Keep measuring. Keep the state. Keep the harness. Do not let a convenient model quietly become the only place your permissions, context, operating knowledge, and improvement loop can live.

The model will keep changing. That is the point. Your AI strategy should be built for that change, not designed to make change too expensive to attempt.