Die ersten öffentlichen Versionen von IndeRun sind veröffentlicht. Der Code ist auf GitHub verfügbar: https://github.com/independo-gmbh/inderun

Damit ist ein wichtiger Schritt geschafft: Aus der Architektur, die wir im letzten Beitrag beschrieben haben, ist eine erste nutzbare Grundlage geworden. IndeRun ist weiterhin ein Projekt im frühen Stadium. Die aktuelle Version ist kein fertiges KI-Produkt und kein vollständiges Provider-Ökosystem. Aber sie zeigt den Kern der Idee in Code: Apps sollen KI-Aufgaben über eine stabile Schnittstelle ausführen können, ohne sich überall selbst um Provider-Auswahl, Capability Checks, Fallbacks und unterschiedliche Fehlerformate kümmern zu müssen.

Vom Architekturentwurf zur ersten Version

Im letzten Beitrag haben wir erklärt, warum wir bei IndeRun zuerst die Architektur klären. Die KI-Landschaft verändert sich schnell: Cloud-APIs, systemnahe On-Device-Modelle, lokale Runtimes und neue Browser-APIs entwickeln sich parallel. Für Apps, die KI-Funktionen verantwortungsvoll einsetzen wollen, reicht es nicht, einfach einen einzelnen Provider fest einzubauen.

Gerade in inklusiven Anwendungen ist Vorhersehbarkeit wichtig. Eine App sollte wissen, ob eine Aufgabe lokal ausgeführt werden kann, ob eine Internetverbindung nötig ist, ob Datenschutzregeln eine Cloud-Ausführung erlauben und was passieren soll, wenn ein Provider nicht verfügbar ist.

Genau dafür entsteht IndeRun: als offene Ausführungs- und Routing-Schicht für KI-Funktionen.

Mit der ersten Version ist diese Idee nun nicht mehr nur Architekturpapier. Die grundlegenden Verträge, SDK-Oberflächen und ersten Provider-Pfade sind vorhanden.

Was in der ersten Version enthalten ist

Die aktuelle Version konzentriert sich auf den einfachsten und wichtigsten Ausführungsmodus: run().

Das bedeutet: Eine App stellt eine Anfrage, IndeRun wählt auf Basis der verfügbaren Provider und Constraints einen passenden Ausführungspfad, und am Ende kommt ein Ergebnis zurück. Der erste Aufgabenbereich ist text_to_text, also textbasierte KI-Aufgaben wie Zusammenfassen, Umformulieren, Übersetzen oder Vereinfachen.

Die erste Version enthält unter anderem:

• eine gemeinsame Vertragsbasis für Requests, Ergebnisse, Fehler und Provider-Beschreibungen,

• SDK-Pfade für Web/TypeScript, iOS/Swift und Android/Kotlin,

• deterministisches Routing auf Basis von Constraints und Capability-Informationen,

• normalisierte Provider-Fehler,

• eine OpenAI-kompatible Cloud-Provider-Basis,

• On-Device-Pfade für Apple Foundation Models und Android ML Kit GenAI / Gemini Nano, sofern die jeweilige Plattform und das Gerät diese unterstützen.

Wichtig ist dabei: IndeRun entscheidet nicht magisch, dass lokale Ausführung immer möglich ist. Lokale KI hängt stark von Gerät, Betriebssystem, Modellverfügbarkeit und Plattform-APIs ab. IndeRun macht diese Unterschiede nicht unsichtbar, aber besser handhabbar. Die App soll nicht überall eigene Sonderlogik für jeden Provider brauchen.

Was im Moment noch nicht enthalten ist

Die erste Version ist ein Fundament, kein Endzustand.

Noch nicht umgesetzt sind zum Beispiel Streaming und Realtime-Sessions. Web unterstützt aktuell vor allem den Cloud-Pfad; ein browser-lokaler Systemmodell-Provider ist für den nächsten Meilenstein geplant.

Das ist Absicht. Für IndeRun ist es wichtiger, zuerst stabile Grundbegriffe zu schaffen, als möglichst viele Provider schnell nebeneinanderzustellen. Wenn die Verträge, Fehlerformen und Routing-Entscheidungen nicht sauber sind, wird jede spätere Erweiterung schwieriger.

Warum das für inklusive Apps relevant ist

IndeRun entsteht aus unserer Arbeit mit digitalen Werkzeugen für Unterstützte Kommunikation und Barrierefreiheit. KI kann dort helfen: beim Vereinfachen von Texten, beim Formulieren, beim Zusammenfassen, beim Vorschlagen von Symbolen oder beim Strukturieren von Informationen.

Aber gerade dort müssen KI-Funktionen nachvollziehbar und verantwortbar bleiben.

Eine App sollte lokale Ausführung bevorzugen können, wenn sensible Inhalte verarbeitet werden. Sie sollte auf Cloud-Ausführung ausweichen können, wenn lokale Modelle nicht verfügbar sind und die Policy das erlaubt. Sie sollte verständliche Fehler zurückgeben, statt Provider-spezifische Ausnahmen bis in die Benutzeroberfläche durchzureichen.

IndeRun macht KI dadurch nicht automatisch inklusiv. Aber es schafft eine technische Grundlage, auf der KI-Funktionen kontrollierter, prüfbarer und plattformübergreifend konsistenter eingebaut werden können.

Was als Nächstes geplant ist: Milestone 2

Nach der ersten Veröffentlichung geht es im nächsten Schritt darum, die Provider-Basis zu erweitern und die Architektur an realistischeren Ausführungsszenarien zu testen.

Milestone 2 konzentriert sich auf mehrere Themen.

Erstens soll die Provider-Landschaft breiter werden. Für Web ist ein Systemmodell-Provider geplant, also ein Pfad für browserverwaltete lokale Modelle. Solche APIs entwickeln sich gerade schnell, etwa rund um browser-lokale Prompt-APIs. IndeRun soll hier ehrlich mit Verfügbarkeit umgehen: Ist die API vorhanden? Ist das Modell verfügbar oder herunterladbar? Ist die Hardware geeignet? Gibt es Speicher- oder Netzwerkgrenzen?

Zweitens planen wir eine ONNX-Runtime-Provider-Familie. Dabei geht es nicht nur darum, ONNX-Modelle auszuführen. Der wichtigere Teil ist ein gemeinsames Modell-Lade- und Paketkonzept: Wie kann eine App eigene oder mitgelieferte lokale Modelle referenzieren? Welche Metadaten braucht IndeRun, um Fähigkeiten, Kompatibilität und Ressourcenbedarf zu prüfen? Welche Teile funktionieren auf Web, iOS und Android gleich, und wo unterscheiden sich die Plattformen?

Drittens sollen Provider-Dokumentation, Provider-Matrix und Tests ausgebaut werden. Es soll klarer sichtbar werden, welche Provider auf welcher Plattform existieren, welche Modi sie unterstützen und welche Grenzen sie haben. Außerdem sollen Demos und Tests zeigen, wie Routing zwischen Cloud, systemnahen lokalen Providern, browser-lokalen Modellen und später auch eigenen lokalen Modellen funktioniert.

Darüber hinaus bleibt das größere Architekturziel bestehen: Streaming, ein einheitliches Event-Modell, zuverlässige Abbruchlogik, Session-Formen für spätere Echtzeitinteraktionen, Route-Erklärungen und bessere Telemetrie.

Mitmachen und Feedback

IndeRun ist Open Source und steht noch am Anfang. Gerade deshalb ist Feedback jetzt besonders wertvoll.

Uns interessieren vor allem Fragen wie:

• Welche Provider-Pfade sind für reale Apps am wichtigsten?

• Welche Capability Checks brauchen Entwickler:innen wirklich?

• Wie sollte eine App ausdrücken, dass lokale Ausführung erforderlich oder bevorzugt ist?

• Welche Fehler und Fallbacks müssen besonders verständlich sein?

• Wie können eigene lokale Modelle eingebunden werden, ohne dass die öffentliche API provider-spezifisch wird?

Der Code ist auf GitHub verfügbar: https://github.com/independo-gmbh/inderun

Die erste Version ist damit ein Anfang, aber ein wichtiger: IndeRun hat nun eine offene Grundlage, auf der wir die nächsten Provider, Ausführungsmodi und Routing-Entscheidungen schrittweise aufbauen können. Genau dort entscheidet sich, ob KI-Funktionen künftig weniger abhängig von einzelnen Anbietern, besser erklärbar und besser in inklusive Anwendungen integrierbar werden.