Modell / Datensatz
johnbean393/Sidekick avatar
johnbean393/Sidekick

Sidekick: lokale LLM-Chats mit Zugriff auf Dateien, Ordner und Websites unter macOS

A native macOS app that allows users to chat with a local LLM that can respond with information from files, folders and websites on your Mac without installing any other software. Powered by llama.cpp.

3.311 Sterne148 ForksSwiftMIT

Auf einen Blick

Was ist das?
Sidekick ist eine native macOS-Anwendung, die einen lokalen llama.cpp-Backend mit RAG, Funktionsaufrufen und einem Deep-Research-Agenten verbindet. Der Text beschreibt, wie das Zusammenspiel funktioniert, wo die Konfiguration ansetzt und für wen der Einsatz sinnvoll ist.
Für wen ist es gedacht?
Wer unter macOS mit lokalen GGUF-Modellen arbeiten will und dafür keinen separaten Server aufsetzen möchte, findet in Sidekick eine Anwendung, die llama.cpp, RAG und Funktionsaufrufe in einer Oberfläche bündelt. Wer eine Linux- oder Windows-Umgebung betreibt, ist hier falsch, ebenso alle, die einen headless betreibbaren Dienst oder eine stabile API-Schnittstelle für eigene Automatisierung brauchen.
Darf ich es kommerziell nutzen?
Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
Wird es noch gepflegt?
Ja. Die letzten Commits kamen vor 115 Tagen.
In welcher Sprache ist es geschrieben?
Hauptsächlich Swift, laut der Sprachstatistik von GitHub.

Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.

TIEFGEHENDE OPEN-SOURCE-ANALYSE

Welches Problem Sidekick adressiert

Ein lokales Sprachmodell auf einem Mac zu betreiben ist heute technisch möglich, aber der Weg dorthin führt üblicherweise über mehrere Werkzeuge: eine Inferenz-Engine, ein Skript zum Einlesen von Dokumenten, eine Vektordatenbank und eine Chat-Oberfläche. Sidekick bündelt diese Schritte in einer einzigen nativen Anwendung. Die Beschreibung nennt als Kern: mit einem lokalen LLM chatten, das mit Informationen aus Dateien, Ordnern und Websites auf dem eigenen Mac antwortet, ohne dass weitere Software installiert werden muss. Die Zielgruppe lässt sich aus dem Beispiel im README ablesen: eine Person, die für eine Hausarbeit über die Azteken und spanische Truppen belegen will, ob die Azteken erbeutete spanische Waffen eingesetzt haben. Sidekick antwortet nach dieser Darstellung mit direkten Zitaten, Seitenzahlen und einer kurzen Analyse, und ein Klick auf die Referenz öffnet das zitierte Paper. Das ist ein Recherche-Workflow, kein allgemeiner Chatbot. Wer Belege braucht und die Quellen im Blick behalten will, ist die anvisierte Nutzergruppe.

Experten als Container für Ressourcen

Die zentrale Abstraktion heißt im Projekt Expert. Ein Expert ist eine benannte Sammlung von Dateien, Ordnern und Websites, die thematisch zusammengehören. Das README nennt als Beispiel einen Studenten, der die Experts English Literature, Mathematics, Geography, Computer Science und Physics anlegt und dann Computer Science aktiviert. Erst durch das Aktivieren bekommt Sidekick laut Dokumentation Zugriff auf die zugehörigen Materialien. Das ist eine bewusste Einschränkung: Statt dem Modell pauschal alles verfügbar zu machen, entscheidet der Nutzer pro Anfrage, welcher Wissensbereich durchsucht wird. Neben den dauerhaft angelegten Experts gibt es einen zweiten Weg. Dateien können direkt in das Eingabefeld gezogen werden, sie gelten dann als temporäre Ressource für diese eine Unterhaltung. Für kurze, einmalige Fragen ist das der schnellere Weg, für wiederkehrende Themen der Expert. Die Trennung ist praktisch, weil sie verhindert, dass ein einzelner Expert mit der Zeit zu einem undifferenzierten Haufen aus allem wird.

Wie die Antworten zustande kommen

Sidekick setzt auf Retrieval Augmented Generation, kurz RAG. Das README formuliert den Effekt so, dass man theoretisch unbegrenzt viele Ressourcen in einen Expert legen kann, und Sidekick trotzdem die für die Anfrage relevanten Informationen findet. Der Ablauf ist damit zweistufig: Zuerst wird aus den aktivierten Quellen der relevante Ausschnitt gesucht, dann bekommt das Modell diesen Ausschnitt zusammen mit der Frage und formuliert die Antwort. Die Inferenz selbst läuft über einen eingebauten llama.cpp-Backend, der moderne GGUF-Modelle lädt. Das README nennt Qwen3.5 als Beispiel für ein Modell, das ohne Zusatzschritte funktioniert. Wer ein anderes GGUF-Modell verwenden will, muss es nach dieser Darstellung selbst bereitstellen. Neben dem lokalen Pfad unterstützt Sidekick OpenAI-kompatible APIs. Die Dokumentation beschreibt dafür mitgelieferte Presets für OpenAI, Anthropic, Google AI Studio, DeepSeek, Groq, MiniMax, Mistral und xAI. Man wählt einen Anbieter und trägt einen API-Schlüssel ein. Damit verlässt die Anfrage den Rechner, was dem Grundgedanken der lokalen Verarbeitung widerspricht. Die Formulierung im README, dass ein primär lokaler Workflow erhalten bleibt, ist an dieser Stelle eine Einschränkung, die man bewusst treffen sollte, nicht ein Detail.

Funktionsaufrufe und der Deep-Research-Agent

Modelle rechnen und logisch schließen nicht zuverlässig. Sidekick begegnet dem mit Funktionsaufrufen, die nach Angabe des README sequenziell in einer Schleife ausgeführt werden, bis ein Ergebnis vorliegt. Das README beschreibt zwei Beispiele. Im ersten berechnet Sidekick Finanzkennzahlen für Nvidia im dritten Quartal 2025 und führt dabei 27 Werkzeugaufrufe aus, speichert die CSV-Datei und präsentiert die Ergebnisse. Im zweiten soll eine Einladung zu einer Geburtstagsfeier an einen Freund entworfen werden; Sidekick sucht das Geburtsdatum und die E-Mail-Adresse aus dem Adressbuch und legt einen Entwurf im Standard-Mailprogramm an. Beide Beispiele zeigen, dass die Funktionen nicht nur rechnen, sondern auf lokale Datenquellen wie Kontakte zugreifen und Aktionen auslösen. Laut README laufen solche Agenten vollständig lokal. Der zweite Agent ist Deep Research, der laut Dokumentation lange, mehrstufige Rechercheaufträge bearbeitet. Man gibt ein Thema vor, Sidekick liest nach dieser Beschreibung 50 bis 80 Webseiten und erstellt daraus einen Bericht. Das ist eine Größenordnung, die Laufzeit und Ressourcenverbrauch deutlich über einen normalen Chat hinaus treibt. Ob die Seitenzahl eine feste Vorgabe oder eine Beobachtung aus einem Lauf ist, lässt sich aus dem Material nicht klären.

Installation und Konfiguration

Das README beschreibt Installation und Konfiguration nicht im Detail. Es verweist für die Features und ihre Bedienung auf die Projektseite unter johnbean393.github.io/Sidekick. Konkrete Befehle, Homebrew-Formeln oder Konfigurationsdateien mit Schlüsselnamen nennt der Auszug nicht, und ich habe die Anwendung nicht installiert, um das zu ergänzen. Wer den Einstieg sucht, findet ihn in den Releases: Die jüngsten Einträge sind 1.0.0-rc.18 vom 2. April 2026, davor 1.0.0-rc.17 und 1.0.0-rc.16. Der Stand ist also ein Release Candidate, kein fertiges 1.0.0. Das ist für die Bewertung relevant, weil sich zwischen Release Candidates Schnittstellen und Dateiformate ändern können. Die sichtbaren Einstellpunkte liegen in der Oberfläche: Experts anlegen und aktivieren, Dateien ins Eingabefeld ziehen, einen API-Anbieter aus der Preset-Liste wählen und einen Schlüssel eintragen. Alles Weitere, insbesondere Modellpfade und Speicherorte, müsste man der Projektdokumentation entnehmen.

Wo Sidekick an Grenzen stößt

Die erste Grenze ist das Betriebssystem. Sidekick ist eine native macOS-Anwendung in Swift. Wer Linux-Server oder Windows-Arbeitsplätze betreibt, kann sie dort nicht einsetzen. Die zweite Grenze ist die Hardware. Ein lokales Modell im GGUF-Format läuft auf dem Gerät, und die Qualität der Antworten hängt direkt davon ab, welche Modellgröße der Rechner trägt. Das README macht dazu keine Angaben, es nennt weder Speicherbedarf noch empfohlene Chips. Wer ein großes Modell erwartet und nur wenig Arbeitsspeicher hat, wird die Erfahrung nicht reproduzieren können, die die Screenshots zeigen. Die dritte Grenze betrifft die Funktionen. Das README nennt das Beispiel eines Agenten, der 27 Werkzeugaufrufe ausführt. Solche Ketten sind fehleranfällig: Ein falsch interpretierter Zwischenschritt pflanzt sich durch die restliche Schleife fort, und ein lokales Modell ist bei der Auswahl des richtigen Werkzeugs weniger zuverlässig als ein großes Remote-Modell. Die vierte Grenze ist die Speicherfunktion. Sidekick merkt sich laut README Informationen zwischen Unterhaltungen, um Antworten persönlicher zu machen. Das ist ein Datenspeicher, der wächst, und das README sagt nicht, wie man ihn einsehen, begrenzen oder löschen kann. Wer mit vertraulichen Dokumenten arbeitet, sollte das vor dem Einsatz klären.

Was Sidekick von einem reinen Chat-Client unterscheidet

Die naheliegende Alternative ist ein Chat-Client, der ein lokales Modell über eine OpenAI-kompatible Schnittstelle anspricht, etwa eine Oberfläche, die gegen einen separat gestarteten llama.cpp-Server oder Ollama läuft. Der Unterschied liegt nicht im Modell, sondern in der Umgebung darum. Bei dieser Variante startet man den Server selbst, richtet die Modellablage ein und sorgt dafür, dass der Dienst läuft. Sidekick nimmt einem diese Schritte ab, weil die Inferenz-Engine Teil der Anwendung ist. Der Preis dafür ist Bindung: Die Modellverwaltung, die Ressourcenverwaltung und die Agentenlogik liegen in der Anwendung, nicht in einer Kommandozeile, die man in ein Skript einbinden kann. Wer Sidekick headless auf einem Rechner ohne Bildschirm betreiben oder seine Anfragen aus einer CI-Umgebung heraus auslösen will, hat mit einem separaten Server mehr Möglichkeiten. Umgekehrt gilt: Wer vor allem am Schreibtisch mit Dokumenten arbeitet und keine Serveradministration betreiben will, spart mit Sidekick den größten Teil der Einrichtung. Die Entscheidung hängt also weniger am Modell als daran, ob die Anwendung ein Werkzeug in einer Kette oder der Arbeitsplatz selbst sein soll.

Wartung, Lizenz und was vor dem Einsatz zu prüfen ist

Sidekick steht unter der MIT-Lizenz. Das ist eine permissive Lizenz: Sie erlaubt Nutzung, Änderung und Weitergabe, auch in kommerziellen Zusammenhängen, und verlangt im Wesentlichen die Beibehaltung des Lizenzhinweises. Wer die Anwendung weiterverbreitet oder forkt, sollte den genauen Wortlaut der Lizenzdatei im Repository lesen, statt sich auf eine Zusammenfassung zu verlassen. Das gilt besonders, wenn eigene Änderungen mitgeliefert werden. Für die Wartung ist der Release-Takt ein Anhaltspunkt. Zwischen 1.0.0-rc.16 im November 2025 und 1.0.0-rc.18 im April 2026 liegen mehrere Vorabversionen, und der letzte Push ins Repository datiert auf Mai 2026. Das Projekt wird also aktiv bearbeitet. Solange die Versionsnummer einen Release Candidate trägt, sollte man vor einem Update damit rechnen, dass sich Verhalten oder Datenformate ändern, und die eigenen Experts gegebenenfalls neu aufbauen. Die erste konkrete Prüfung vor dem Adoptionsentscheid ist deshalb die Release-Seite: Steht dort inzwischen 1.0.0 ohne Suffix, und was sagen die Release Notes über Änderungen an den Experts? Die zweite Prüfung betrifft die eigene Hardware und die Modellgröße, die darauf läuft. Die dritte betrifft die Speicherfunktion, weil sie Daten über Unterhaltungen hinweg hält und das README ihre Verwaltung nicht beschreibt.

Redaktionelles Fazit

Wer unter macOS mit lokalen GGUF-Modellen arbeiten will und dafür keinen separaten Server aufsetzen möchte, findet in Sidekick eine Anwendung, die llama.cpp, RAG und Funktionsaufrufe in einer Oberfläche bündelt. Wer eine Linux- oder Windows-Umgebung betreibt, ist hier falsch, ebenso alle, die einen headless betreibbaren Dienst oder eine stabile API-Schnittstelle für eigene Automatisierung brauchen. Vor dem produktiven Einsatz sollte man prüfen, ob die vorhandene Hardware die gewünschte Modellgröße trägt, ob die aktuelle Version noch ein Release Candidate ist und ob die MIT-Lizenz zu den eigenen Verbreitungsplänen passt.

Offizielle Quellen

  1. johnbean393/Sidekick on GitHub
  2. License: MIT
  3. Project website
  4. README
  5. Releases
Community-Notizen

Community-Notizen