Mozilla.ai's Otari Gateway Aims to Fill the Gaps Open Model APIs Leave

The invisible work hosted APIs do

The post follows an argument Mozilla.ai made in July, that open models are ready for agents but their APIs are not. According to the author, migrating the company's agent app off a proprietary frontier API meant rebuilding a surprising amount of infrastructure around the model itself.

Mozilla.ai says the goal is that building on open models should feel as seamless as using closed alternatives. The hardest problems, it argues, are not the obvious feature gaps people discuss. They are the subtle functions hosted APIs quietly perform in the background, which application code relies on without anyone noticing.

Otari is the answer to that problem. It is a gateway layer that sits between an application and whichever model host a developer chooses, bringing those missing capabilities back.

Web search and code execution under your control

The post uses web search as its main example. When the feature is enabled in Claude, queries run behind the scenes on a search engine under terms the user never directly agreed to. According to Mozilla.ai, developers cannot pick the underlying provider, track what data is retained, or swap services if results in their domain get worse.

Code execution raises similar concerns. User files run inside sandboxes the developer did not configure, in locations that cannot be verified.

With Otari, Mozilla.ai says these stay the developer's own decisions:

• Web queries route through services the developer configures, using their own credentials and contracts.
• Code runs in sandbox environments the developer specifies, governed by an open published protocol that anyone can implement.

The application sees the same tool interface as before, while the developer keeps full visibility and ownership, the company says.

What is still to come

Mozilla.ai reports that it has already achieved this setup in octonous.com, which it calls an important milestone. There are still things to implement and polish, though.

The remaining challenges may not be obvious to anyone who has not built around several frontier APIs. The post names context compaction, prompt caching, and persistent memory. On memory, the aim is for developers to be able to inspect it and migrate it across models instead of locking it inside proprietary silos.

The key benchmark, according to the post, is whether an agent designed for commercial frontier APIs can point directly at open models through Otari and operate flawlessly. Readers who test this are invited to open an issue in the project's GitHub repository.

What it means for developers

For teams building agents, the pitch is a way to move to open models without rewriting the infrastructure that closed APIs provide implicitly, while choosing their own search providers and sandboxes. The post also lists related Mozilla.ai work, including Mistral Large 4 availability in Otari, described as Mozilla AI's open-source gateway and policy layer. The project's own benchmark, an unmodified agent running on open models, has not yet been declared met, as the remaining items show.