Was ist maxOS

maxOS ist eine Open-Source-AI-native-Plattform des Unternehmens ООО «Гарипофф», die auf lokalen Modellen basiert. Ihr offener Kern ist ein Agent: Er liest und bearbeitet Dateien im Projekt und führt Befehle im Terminal aus, nutzt dafür jedoch ein Sprachmodell, das direkt auf deinem Rechner läuft. Weder Code noch Anfragen oder Dateiinhalte werden in eine fremde Cloud übertragen.

Der Kern ist unter der Apache-2.0-Lizenz freigegeben: github.com/LLC-Garipoff/maxos. Fangen wir damit an.

Ein Agent, keine Autovervollständigung

Die Autovervollständigung schlägt die nächste Zeile vor. Ein Agent hingegen löst die Aufgabe als Ganzes: Er arbeitet sich in das Projekt ein, nimmt Änderungen an mehreren Dateien vor, startet den Build-Prozess sowie Tests, liest die Ausgabe und macht weiter.

Im Inneren von maxOS läuft ein einfacher Zyklus. Dem Modell werden die Aufgabe und eine Beschreibung der verfügbaren Tools übergeben. Das Modell antwortet nicht mit Text, sondern entscheidet sich für den Aufruf eines Tools. Es gibt vier Tools:

• read_file – eine Datei lesen;
• list_dir – den Inhalt eines Verzeichnisses anzeigen;
• write_file – eine Datei erstellen oder überschreiben;
• run_bash – einen Befehl in der Shell ausführen (Build, Tests, Ausführung).

maxOS führt den Aufruf im Arbeitsverzeichnis aus, gibt das Ergebnis an das Modell zurück, und der Zyklus wiederholt sich, bis das Modell aufhört, Tools aufzurufen, und mit einem Endergebnis antwortet. Alle Pfade sind auf das Arbeitsverzeichnis beschränkt – ein Aufruf, der versucht, dieses zu verlassen, wird abgewiesen. Vor dem Schreiben einer Datei und vor dem Ausführen eines Befehls fragt maxOS standardmäßig nach einer Bestätigung.

Das ist das ganze Prinzip. Kein versteckter Cloud-Orchestrator – Zyklus, Tools und Prompt passen in einige hundert Zeilen ohne Laufzeitabhängigkeiten.

Nur lokale Modelle

maxOS berechnet das neuronale Netz nicht selbst. Es delegiert die Inferenz an eine lokale Laufzeitumgebung mit einer OpenAI-kompatiblen API – zum Beispiel Ollama oder llama.cpp. Du startest das Modell bei dir:

ollama pull qwen2.5-coder:7b

– und maxOS kommuniziert mit ihm über http://localhost. Ein Cloud-Endpunkt existiert in diesem Schema überhaupt nicht: Wenn der Rechner das Modell schafft, arbeitet der Agent vollständig offline.

Hier gibt es eine technische Feinheit, für die eine eigene Schicht geschrieben werden musste. Einige lokale Modelle übergeben Tool-Aufrufe brav im strukturierten Feld tool_calls, wie es das OpenAI-kompatible Protokoll erwartet. Viele andere jedoch – darunter auch qwen2.5-coder – schreiben den Aufruf stattdessen als JSON-Text direkt in die Antwort. maxOS erkennt beide Fälle: Wenn das strukturierte Feld fehlt, extrahiert es den Aufruf aus dem Text (einschließlich des Formats mit <tool_call>-Tags) und setzt den Zyklus fort. Deshalb funktioniert das Framework nicht nur mit einem „richtigen“ Modell, sondern mit ganz unterschiedlichen.

Wo die Modelle für das Coding angebunden werden

maxOS ist ein Orchestrator: Prompt, Tools, Zyklus, Sandbox, Bestätigungen. Den Code selbst schreibt und korrigiert das angebundene Modell. Für das Coding werden spezialisierte Modelle in der Laufzeitumgebung installiert – qwen2.5-coder, llama3.1 und ähnliche, die Tools aufrufen können. Das Modell zu wechseln ist eine Sache von einer Zeile (--model) oder einer Umgebungsvariable; der restliche Agent bleibt unverändert.

Die Trennung ist bewusst. Der Agenten-Zyklus stößt an die Grenzen von Festplatte und Netzwerk, nicht an die der Rechenleistung. Deshalb ist er in TypeScript geschrieben – für schnelle Iterationen und eine einfache Installation. Und performante sowie systemnahe Komponenten, die es noch nicht gibt, wollen wir in einen nativen Kern in Rust auslagern: die Indizierung großer Repositories und die Suche darin, ein einziges Binary ohne Node-Abhängigkeit. Die Logik ist dieselbe: das passende Werkzeug für einen konkreten Zweck wählen, anstatt das in Rust zu schreiben, was ohnehin durch I/O limitiert ist.

Was hat SpotMax damit zu tun?

SpotMax ist die Desktop-Anwendung des Teams, die aus derselben Idee entstanden ist: Ein Modell, das dir hilft, sollte direkt bei dir laufen und nicht in einem fremden Rechenzentrum. Der Name selbst steht für Spotlight + max: ein Werkzeug, das tief in das Betriebssystem integriert und immer griffbereit ist.

Wir haben es für den Vertrieb entwickelt – für eigene Präsentationen und Pitches: Der Assistent hört dem Gespräch zu und gibt in Echtzeit Tipps, um den roten Faden und den Kontext nicht zu verlieren. Es stellte sich heraus, dass er weitaus vielseitiger einsetzbar ist – er erwies sich sowohl für Bewerber als auch für HR als nützlich. Und heute wird er immer häufiger für Verhandlungen mit ausländischen Partnern genutzt: SpotMax erkennt und transkribiert Sprache direkt auf dem Gerät und hilft dabei, das Gespräch zu führen, ohne den Sinn zu verlieren. Wie genau er den Anruf hört, die Sprache transkribiert und Tipps gibt, haben wir separat aufgeschlüsselt: Wie SpotMax funktioniert: Transkription, Übersetzung und Hinweise während des Anrufs.

Die Erkennung und Sprechertrennung funktionieren lokal – das sind genau die Modelle, die auf dem Gerät laufen. maxOS ist das gemeinsame, offene Fundament darunter: die Agenten-Ebene, die wir als Open Source bereitgestellt haben, damit man sie lesen, überprüfen und verbessern kann.

Warum lokal?

Cloud-Agenten für Code senden deinen Quellcode, deine Anfragen und oft auch die Terminal-Ausgabe an einen fremden Server. Für einen großen Teil der Arbeit – proprietärer Code, regulierte Daten, NDA oder einfach eine schlechte Netzwerkverbindung – ist das inakzeptabel. maxOS macht den lokalen Weg zur einzigen Option: Das lässt sich direkt im Quellcode überprüfen, da er offenliegt.

Code, Bug-Reports und Verbesserungen gibt es auf GitHub: github.com/LLC-Garipoff/maxos. Und für konkrete Verbesserungen an lokalen Modellen haben wir ein Bounty-Programm.