Tabby ist einer der ersten Namen, auf die Teams stoßen, wenn sie einen Programmierassistenten suchen, dessen Code das interne Netz nie verlässt. Es ist ein selbst gehosteter KI-Programmierassistent mit Schwerpunkt auf Codevervollständigung, ergänzt um Fragen und Chat, und wird oft als lokal einsetzbare Alternative zu GitHub Copilot gesehen. Der Reiz ist direkt: Der Dienst läuft auf dem eigenen Server, die Inferenz bleibt im Netz, er funktioniert offline und sendet keine Telemetrie nach außen. Für Teams mit strengen Compliance-Regeln kann diese Voraussetzung mehr wiegen als eine etwas klügere Vervollständigung.
Angaben zum offiziellen Repository
Die Plattform ist GitHub, die Organisation heißt TabbyML, das Projekt tabby, das auf GitHub mehr als 33.000 Sterne gesammelt hat. Das Projekt liefert Erweiterungen für gängige Editoren, darunter VS Code und die JetBrains-Familie, und kann angebundene Repositories indexieren, sodass die Vervollständigung den Kontext des aktuellen Projekts nutzt statt aus einer einzelnen Datei zu raten.
Warum Teams es wählen
Cloud-Werkzeuge starten schnell, doch Code muss an einen externen Dienst gehen, und in Finanzwesen, Verwaltung und großer Fertigung scheitert genau das oft an der internen Prüfung. Tabby zieht die Grenze innerhalb des Netzes: Der offizielle Aufbau ist ein eigenständiger Dienst, der mit einem einzigen Docker-Befehl startet, ohne Abhängigkeit von einer externen Datenbank oder einem Cloud-Backend. Eine Maschine mit Grafikkarte genügt für den Anfang, Karten für Endverbraucher werden unterstützt, und der Betrieb geht vollständig offline. Ein gemeinsamer Dienst erleichtert es der Verwaltung zudem, den Zugang an einer Stelle zu bündeln, statt dass jede Person einzeln einen Außendienst abonniert.
Zwei Rechnungen: Hardware und Betrieb
Die erste Rechnung ist die Grafikkarte. Das Code-Modell im Hintergrund wählen Sie selbst; gängige Kandidaten dieser Klasse sind etwa StarCoder, CodeLlama, DeepSeek-Coder und die Qwen-Code-Modelle, und die Obergrenze der Vervollständigungsqualität setzt das gewählte Modell. Ein größeres Modell vervollständigt meist besser und frisst zugleich mehr Videospeicher; für einen geteilten Teamdienst braucht es Reserve für gleichzeitige Nutzer, und eine ständig laufende GPU-Maschine bringt Strom und Kühlung in die Langzeitkosten. Die zweite Rechnung ist der Betrieb. Der Containerstart ist erst der Anfang: Die Repository-Indexierung pflegen Sie selbst, und Modellwechsel, Versionswechsel und die Fehlersuche bei Speichermangel bleiben auf Ihrer Seite. Prüfen Sie vor dem Einsatz auch die Grenze: Nutzerverwaltung auf Teamebene und feinere Analysen gehören zum Umfang der Unternehmensversion, trennen Sie also vorab, was der quelloffene Selbstbetrieb abdeckt und was gesondert zu entscheiden ist, statt die Lücke erst nach der Einführung zu entdecken.
Die echten Fallen und Grenzen
Die deutlichste Lücke ist die Vervollständigungsqualität. Gegenüber führenden Cloud-Programmierwerkzeugen bewältigt ein lokales kleines Modell kurzen Code und Routinefragmente gut, tut sich aber mit komplexem Schließen über Dateien hinweg schwer, und seine Vorschläge brauchen mehr menschliche Kontrolle. Wer das stärkste Cloud-Erlebnis eins zu eins ersetzen will, spürt den Abstand deutlich. Auch die bequeme Option ist es nicht: Index, Modelle und Erweiterungsverträglichkeit verlangen laufende Aufmerksamkeit, ohne den Öffnen-und-loslegen-Komfort eines Cloud-Dienstes. Sein Wert wächst nur, wenn die Bedingung, dass Code das Netz nicht verlassen darf, wirklich gilt und das Team bereit ist, dafür Maschinen- und Betriebskosten zu tragen; Selbstbetrieb aus anderen Gründen geht selten auf.
Für wen es passt, für wen nicht
Es passt zu kleinen Teams mit Compliance- oder Intranet-Auflagen, zu Offline-Umgebungen und zu Teams, die ihren Vervollständigungsdienst unter einem Dach bündeln wollen; solche Teams nehmen etwas schwächere Vervollständigungen in Kauf, um den Code innen zu halten. Es passt nicht zu einzelnen Entwicklern, die die stärkste Vervollständigungsqualität jagen und mit einem Cloud-Werkzeug meist besser fahren, und nicht zu Teams ohne GPU-Server oder ohne jemanden, der den Betrieb übernehmen will. Vor der Entscheidung: eine Woche am echten Repository laufen lassen und Vervollständigungstreffer, Antworttempo und Speicherverbrauch beurteilen, bevor es zum Dauerbetrieb wird.
