6 Punkte von GN⁺ 2025-08-09 | Noch keine Kommentare. | Auf WhatsApp teilen
  • Lokale LLM-Ausführung und Code-Sandbox werden genutzt, um einen KI-Workspace ohne Cloud-Abhängigkeit aufzubauen.
  • Ollama für die lokale LLM-Ausführung, Apple Container für die Codeausführung in einer isolierten VM und Playwright für Automatisierung sowie Internetzugriff über einen Headless-Browser.
  • Das UI basiert auf assistant-ui und implementiert Modellauswahl-Dropdown mit ai-sdk-Integration sowie eine sichere Codeausführungsumgebung über MCP (Model Context Protocol).
  • In einer per MCP angebundenen Coderunner-VM werden Jupyter-Server und Browser ausgeführt, sodass Diagrammerstellung, Bild-/Videobearbeitung, Installation von GitHub-Tools und Websuche in einer Datenschutzschutzumgebung möglich sind.
  • Aktuell ist es nur für Apple Silicon geeignet, und zukünftige Aufgaben sind UI-Verbesserung, Browser-Umgehung zur Bot-Erkennung und Ausbau des Tool-Managements.

Anforderungen und Hintergrund

  • Ziel: alles lokal ausführen, ohne Cloud- oder Remote-Code-Ausführung.
  • Bestehende LLM-Chat-Apps (z. B. ChatGPT, Claude) bieten Cloud-LLM-Chat, Cloud-/lokale Codeausführung und Internetzugriff.
  • Mit dem Anstieg von Open-Source-LLMs stellte sich die Frage, ob all diese Funktionen vollständig lokal umgesetzt werden können.
  • Ein reines lokales LLM reicht nicht aus; Code sollte in einer isolierten Umgebung laufen und auch Browser-Zugriff auf Inhalte ist notwendig.

Idee und Konzeption

  • Das LLM vollständig in der lokalen Umgebung ausführen.
  • Leichte VM (virtuelle Maschine): Codeausführung nur dort verarbeiten, um das Host-System zu schützen.
  • Headless Browser ergänzen, um Automatisierung sowie Suche nach neuen Informationen und Tools zu ermöglichen.
  • Einen vollständig lokalen, datenschutzzentrierten Workflow aufbauen, von der KI-Idee bis zur Codeausführung.
  • Vielfältige Aufgaben wie Bild- oder Videobearbeitung lokal erledigen, ohne Daten an externe Dienste zu senden.

Technologiestack

  • LLM: Ollama (lokale Modelle und Unterstützung einiger externer Modelle)
  • UI: assistant-ui + ai-sdk (Erweiterung der Modellauswahl)
  • VM-Laufzeitumgebung: Apple container (liefert eine isolierte VM-Umgebung)
  • Orchestrierung: instavm/coderunner (MCP-Anbindung eines Jupyter-Servers)
  • Browser-Automatisierung: Playwright (als MCP-Tool bereitgestellt)

Mac-App-Versuche und Umstieg

  • Der Versuch, eine native Mac-App mit a0.dev zu bauen, scheiterte an iOS-Fokus.
  • Ein Ansatz mit Electron + NextJS wurde ebenfalls versucht, aber wegen der Komplexität verworfen.
  • Letztlich wurde auf eine lokale webbasierte assistant-ui umgestellt.

Assistant-UI-Anpassung

  • Zwar wurde erwartet, dass ein Modell-Auswahl-Dropdown verschiedene LLMs unterstützt, aber die Funktionalität war begrenzt.
  • Nach dem Studium von Beispielen wurde die Auswahl mehrerer Modelle direkt über ai-sdk umgesetzt.
  • Zu Beginn wurden auch Cloud-Modelle wie OpenAI/Anthropic unterstützt, mit einer schrittweisen Strategie zur Migration auf lokal.

Tool-calling und Modellunterstützungsprobleme

  • Es wurden Modelle benötigt, die Tool-calling unterstützen; bei einigen wie Ollama ist das in der Praxis nicht gegeben.
  • In offiziellen Dokumenten ist Tool-Unterstützung oft angegeben, doch die tatsächliche Implementierung ist häufig unzureichend.
  • Durch die rasche Entwicklung im Open-Source-Ökosystem schwanken sowohl der Tool-Support als auch die Tokenpreise stark.

Containerbasierte isolierte Codeausführung

  • Mit Apples Container-Werkzeug, das pro Container im Vergleich zu Docker eine vollständig isolierte VM-Umgebung bereitstellt, kann KI-generierter Code sicherer ausgeführt werden.
  • In der VM wird ein Jupyter-Server bereitgestellt, der über das Model Context Protocol (MCP) exponiert wird, damit verschiedene Tools (Claude Desktop, Gemini CLI usw.) sofort nutzbar sind.
  • Der coderunner-MCP-Servercode wurde veröffentlicht und zeigt Integrationsbeispiele mit externen Tools.
  • Das Apple Container-Tool ist noch instabil, sodass bei Build-/Imageproblemen wiederholte Neustarts nötig sind.
  • Bei echten Video-Editing-Tests wurde das Zusammenspiel von UI + LLM + Coderunner erfolgreich validiert.

Headless-Browser-Integration

  • Innerhalb des Containers wurde ein auf Playwright basierender Headless-Browser bereitgestellt und als MCP-Tool exponiert.
  • Erwartete Einsatzmöglichkeiten: Entdeckung neuer Tools/Informationen, Suche nach GitHub-Nutzung, Automatisierung von Recherchen.
  • Der Basis-Workflow ist abgeschlossen: Kombination aus lokalem LLM + Sandbox-Codeausführung + Headless-Browser.

Mögliche Aufgabenbeispiele

  • Forschung und Zusammenfassung zu spezifischen Themen
  • Erstellung und Darstellung von CSV-Charts per natürlicher Sprache
  • Videobearbeitung mit ffmpeg (z. B. Teilen schneiden)
  • Bildgröße ändern, Zuschneiden, Formatumwandlung
  • Installation von GitHub-Tools innerhalb des Containers
  • Web-Crawling und -Zusammenfassung mit Headless-Browser

Datei-Volume-Mount und Isolation

  • Der Host-Pfad ~/.coderunner/assets wird auf den Containerpfad /app/uploads gemountet, Dateien werden in einem sicheren Freigabebereich abgelegt.
  • Ausgeführter Code kann nicht direkt auf das Host-System zugreifen, wodurch die Sicherheit erhöht wird.

Grenzen und nächste Schritte

  • Funktioniert nur in Apple-Silicon-Umgebungen; macOS 26 ist optional.
  • UI-Verbesserungen sind nötig, etwa Tool-Management und Output-Streaming.
  • Der Headless-Browser wird auf einigen Seiten wegen Bot-Erkennung blockiert.

Fazit

  • Dieses Projekt ist mehr als nur ein Experiment und hat Rechenhoheit sowie Datenschutz zum Fokus.
  • Es bietet die Möglichkeit, Daten sicher auf der eigenen lokalen Maschine zu verarbeiten, ohne Abhängigkeit von Cloud- oder Remoteservern.
  • Das beste LLM kann in großen Clouds bleiben, das Ziel ist jedoch die Weiterentwicklung lokaler KI-Tools, die persönliche Privatsphäre schützen.
  • Die Open-Source-coderunner-ui ist auf GitHub verfügbar; Feedback und Kollaboration sind willkommen.

Relevante Ressourcen

Noch keine Kommentare.

Noch keine Kommentare.