Mozilla.ai will mit dem Otari Gateway die Lücken offener Modell-APIs schließen

Die unsichtbare Arbeit gehosteter APIs

Der Beitrag knüpft an eine These an, die Mozilla.ai im Juli aufgestellt hat: Offene Modelle seien bereit für Agenten, ihre APIs aber nicht. Laut dem Autor erforderte die Umstellung der firmeneigenen Agenten-App von einer proprietären Frontier-API auf offene Modelle den Nachbau überraschend vieler Infrastrukturkomponenten rund um das Modell selbst.

Mozilla.ai nennt als Ziel, dass sich das Entwickeln auf Basis offener Modelle so nahtlos anfühlen soll wie die Nutzung geschlossener Alternativen. Die schwierigsten Probleme seien nicht die offensichtlichen Funktionslücken, über die oft gesprochen werde. Es seien vielmehr die subtilen Funktionen, die gehostete APIs im Hintergrund still erledigen und auf die sich Anwendungscode verlässt, ohne dass es jemand bemerkt.

Otari ist die Antwort auf dieses Problem. Es handelt sich um eine Gateway-Schicht, die zwischen einer Anwendung und dem vom Entwickler gewählten Modell-Host sitzt und diese fehlenden Fähigkeiten zurückbringt.

Websuche und Codeausführung unter eigener Kontrolle

Als Hauptbeispiel dient im Beitrag die Websuche. Ist die Funktion in Claude aktiviert, laufen Anfragen im Hintergrund über eine Suchmaschine zu Bedingungen, denen der Nutzer nie direkt zugestimmt hat. Laut Mozilla.ai können Entwickler weder den zugrunde liegenden Anbieter wählen noch nachvollziehen, welche Daten gespeichert werden, noch den Dienst wechseln, wenn die Ergebnisse in ihrem Fachgebiet schlechter werden.

Bei der Codeausführung gibt es ähnliche Bedenken. Nutzerdateien laufen in Sandboxes, die der Entwickler nicht konfiguriert hat, an Orten, die sich nicht überprüfen lassen.

Mit Otari bleiben diese Entscheidungen nach Angaben von Mozilla.ai in der Hand der Entwickler:

• Web-Anfragen laufen über Dienste, die der Entwickler konfiguriert, mit eigenen Zugangsdaten und Verträgen.
• Code wird in Sandbox-Umgebungen ausgeführt, die der Entwickler festlegt, und zwar auf Basis eines offen veröffentlichten Protokolls, das jeder implementieren kann.

Die Anwendung sieht dieselbe Tool-Schnittstelle wie zuvor, während der Entwickler volle Transparenz und Eigentum behält, so das Unternehmen.

Was noch aussteht

Mozilla.ai berichtet, diesen Aufbau bereits in octonous.com umgesetzt zu haben, was das Unternehmen als wichtigen Meilenstein bezeichnet. Es gibt jedoch noch Dinge zu implementieren und zu verfeinern.

Die verbleibenden Herausforderungen sind womöglich nicht offensichtlich für jemanden, der noch nicht rund um mehrere Frontier-APIs gebaut hat. Der Beitrag nennt Context Compaction, Prompt Caching und persistenten Speicher. Beim Speicher soll es Entwicklern möglich sein, ihn einzusehen und zwischen Modellen zu migrieren, statt ihn in proprietären Silos einzuschließen.

Der entscheidende Maßstab sei laut Beitrag, ob ein für kommerzielle Frontier-APIs entworfener Agent direkt über Otari auf offene Modelle zeigen und einwandfrei arbeiten kann. Leser, die das testen, sind eingeladen, im GitHub-Repository des Projekts ein Issue zu eröffnen.

Was das für Entwickler bedeutet

Für Teams, die Agenten bauen, lautet das Angebot: auf offene Modelle umsteigen, ohne die Infrastruktur neu schreiben zu müssen, die geschlossene APIs implizit bereitstellen, und dabei die eigenen Suchanbieter und Sandboxes wählen. Der Beitrag verweist außerdem auf weitere Arbeiten von Mozilla.ai, darunter die Verfügbarkeit von Mistral Large 4 in Otari, das als Open-Source-Gateway und Policy-Schicht von Mozilla AI beschrieben wird. Der projekteigene Maßstab, ein unveränderter Agent auf offenen Modellen, gilt noch nicht als erreicht, wie die offenen Punkte zeigen.