GitHub Copilot Alternative 2026: 6 Tools mit lokalen Modellen

Eine GitHub Copilot Alternative mit lokalen Modellen ist seit Juni 2026 unter anderen Vorzeichen zu bewerten: VS Code kann Chat- und Agenten-Workflows inzwischen ohne GitHub-Konto oder Copilot-Tarif offline ausführen, doch die üblichen Inline-Vorschläge lassen sich weiterhin nicht mit lokalen Modellen betreiben. Für einen Wechsel von GitHub Copilot bleiben damit nur drei Gründe: lokale Tab-Vervollständigung, zentral verwaltetes Self-Hosting oder ein leistungsfähigerer Agenten-Workflow. Die günstigste kostenpflichtige Teamalternative spart bei 10 Plätzen vor Hardware- und Verwaltungskosten lediglich $480 pro Jahr.

Die kurze Antwort: Zed ist die beste GitHub Copilot Alternative

Zed ist die beste GitHub Copilot Alternative, wenn sowohl der Coding-Agent als auch die Inline-Vorschläge auf selbst kontrollierter Infrastruktur laufen müssen. Kilo Code passt besser, wenn ein Editorwechsel nicht infrage kommt. Cline bietet den stärksten spezialisierten lokalen Agenten in VS Code, Tabby eignet sich für einen zentral verwalteten Vervollständigungsserver, Aider ist die geradlinigste Git-orientierte Terminallösung und OpenCode deckt die meisten Oberflächen ab.

Es gibt noch eine siebte Antwort: gar nicht wechseln. Wenn lokaler Chat und Agentenarbeit genügen, verbindet sich die aktuelle VS-Code-Version bereits mit Ollama und anderen lokalen Anbietern. Eine Alternative lohnt sich nur, wenn sie eine konkrete Lücke schließt.

Preise, Limits, Testbedingungen und Produktfunktionen wurden am 25. August 2026 anhand der jeweils aktuellen Herstellerseiten geprüft. „Einstiegspreis“ bezeichnet die Software- oder Plattformgebühr. Ein lokales Modell kann trotzdem Kosten für Hardware, Strom, Einrichtung und Wartung verursachen.

Vor dem Wechsel: Was VS Code inzwischen lokal leistet

VS Code ist inzwischen ein ernst zu nehmender Host für lokale Modelle, allerdings nur für eine Seite des Copilot-Erlebnisses. Mit Microsofts BYOK-Update vom Juni 2026 kann VS Code Ollama, Foundry Local und kompatible Modellanbieter für Chat und unterstützte Agenten-Workflows anbinden. Das funktioniert auch vollständig offline und ohne GitHub-Anmeldung oder Copilot-Tarif.

Dadurch wird GitHub Copilot nicht zu einem lokal gehosteten Produkt. Stattdessen bildet VS Code die Anwendungsschicht, die dem Modell Werkzeuge, Kontext und eine Interaktionsschleife bereitstellt. Das Modell kann lokal laufen, während der Editor die Chat- und Agentenoberfläche liefert.

Vier Begriffe sorgen für einen fairen Vergleich:

• Lokales Modell bedeutet, dass die Inferenz auf dem eigenen Rechner oder auf selbst kontrollierter Hardware stattfindet.
• Selbst gehostetes Modell bedeutet, dass der Endpunkt innerhalb der eigenen Infrastruktur läuft. Er kann sich auf einem anderen Rechner oder in einer privaten Cloud befinden statt auf dem Laptop des Entwicklers.
• Agent bedeutet, dass das Modell Dateien prüfen, mehrere Dateien bearbeiten und Werkzeuge wie ein Terminal unter dem Berechtigungssystem der Anwendung verwenden kann.
• Inline-Vervollständigung bezeichnet den ausgegrauten Text oder mehrzeiligen Vorschlag, der beim Tippen erscheint und üblicherweise mit Tab übernommen wird.

Die Lücke betrifft den letzten Punkt. Laut Microsofts aktueller Dokumentation zu Sprachmodellen gilt BYOK für Chat- und Hilfsaufgaben, nicht aber für die üblichen Inline-Vorschläge. Auch semantische Suche und embeddinggestützte Funktionen bleiben von GitHub- oder Copilot-Unterstützung abhängig. VS Code stellt zwar eine Erweiterungs-API bereit, über die andere Produkte eigene Vervollständigungen anbieten können; der integrierte Pfad für lokale Modelle sendet Inline-Vorschläge jedoch nicht an Ollama.

Aus der alten Frage nach einer „lokalen Copilot-Alternative“ werden damit zwei präzisere Fragen:

1. Soll ein lokales Modell Code in einer sichtbaren Agentenschleife planen und bearbeiten?
2. Soll außerdem jeder Vorschlag, der beim Tippen erscheint, lokal erzeugt werden?

Lautet die Antwort auf die zweite Frage nein, erhöht eine weitere Erweiterung womöglich nur die Komplexität, ohne den Datenschutz zu verbessern. Dann genügt es, den Editor für Sprachmodelle zu konfigurieren, den lokalen Anbieter zu verbinden, das Modell für Chat oder unterstützte Agentenarbeit auszuwählen und beim vorhandenen Editor zu bleiben. Lautet die Antwort ja, werden Zed, Kilo Code oder Tabby relevant, weil alle drei einen lokalen Vervollständigungspfad dokumentieren.

Dieselbe Unterscheidung gilt für Offline-Versprechen. Ein lokaler Chat kann ohne Internet funktionieren, während eine Repository-Suche, ein Erweiterungsupdate, eine entfernte Versionsverwaltungsaktion oder ein gehosteter Embeddingdienst weiterhin Verbindungen nach außen aufbaut. „Das Modell läuft lokal“ und „die gesamte Entwicklungsumgebung ist vollständig isoliert“ sind keine austauschbaren Zusagen.

Welcher Copilot-Preis ersetzt wird

GitHubs aktuelle Einzeltarife sind Free, Student, Pro für $10 pro Monat, Pro+ für $39 pro Monat und Max für $100 pro Monat. Free umfasst bis zu 2,000 Inline-Vervollständigungen pro Monat, Student ist für verifizierte Studierende kostenlos. Die Unternehmenstarife kosten bei Business $19 pro zugewiesenem Platz und Monat sowie bei Enterprise $39 pro zugewiesenem Platz und Monat.

Auf GitHubs aktueller Tarifseite steht außerdem, dass neue Business-Self-Service-Abschlüsse für Organisationen mit GitHub Free und GitHub Team seit dem 22. April 2026 vorübergehend pausiert sind. An der Vergleichsbasis von $19 ändert das nichts, wohl aber möglicherweise am Beschaffungsweg. Ein Ersatz sollte mit dem tatsächlich verfügbaren Tarif verglichen werden, nicht mit einem Checkout-Ablauf aus der Erinnerung.

Nach welchen Kriterien diese Alternativen ausgewählt wurden

Ein Produkt kam nur dann infrage, wenn die aktuelle Herstellerdokumentation einen unterstützten Pfad zu lokalen Modellen für einen Coding-Workflow auswies. Ein Repository, das sich theoretisch für einen lokalen Endpunkt patchen ließe, reichte nicht aus. Ebenso wenig ein Cloud-Assistent mit starken Datenschutzversprechen, dessen Inferenz weiterhin im eigenen Dienst des Anbieters stattfindet.

Die sechs Produkte wurden anhand von fünf Kriterien bewertet:

1. Abdeckung: Funktionieren lokale Modelle für den Agenten, die Inline-Vervollständigung oder beides?
2. Klarheit der Bereitstellung: Dokumentiert der Anbieter Ollama, LM Studio, llama.cpp, einen OpenAI-kompatiblen Endpunkt oder einen selbst gehosteten Server?
3. Passung zum Workflow: Läuft das Produkt in einem Editor, Terminal, einer Desktop-App oder als zentraler Dienst?
4. Betriebliche Grenze: Auf welche erste Einschränkung stößt eine ernsthafte Bereitstellung, etwa Editorwechsel, festes Vervollständigungsmodell, Hardware-Mindestanforderung, Ein-GPU-Limit oder fehlende Identitätskontrollen?
5. Gesamtkosten: Welche öffentlichen Softwaretarife sowie außerhalb davon anfallenden Rechen- oder Inferenzkosten entstehen?

Es wird kein eigener Praxistest zur Leistung behauptet. Lokale Latenz und Ausgabequalität hängen zu stark von Modellgröße, Quantisierung, Kontextlänge, GPU-Speicher, Repository-Struktur und Aufgabe ab, als dass ein Ergebnis auf einem Laptop die gesamte Kategorie repräsentieren könnte. Die Rangfolge stützt sich stattdessen auf aktuell unterstützte Funktionen, exakte Preise, dokumentierte Grenzen und eine normalisierte Kostenanalyse.

Dabei fielen auch einige vertraute Namen heraus. Ein reiner Cloud-Coding-Assistent wird durch einen großzügigen Gratis-Tarif nicht zur Alternative mit lokalen Modellen. Continue wurde aus der Rangliste gestrichen, weil die aktuelle Startseite inzwischen die Übernahme durch Cursor nennt und den verbleibenden Open-Source-Code als Grundlage beschreibt, nicht als eigenständig unterstütztes Produkt für eine neue Bereitstellung. Allein diese Änderung macht mehrere ältere Listen lokaler Copilot-Alternativen überholt.

Einen breiteren Überblick über Cloud- und lokale Angebote liefert der Vergleich der besten KI-Coding-Assistenten 2026. Die Auswahl hier bleibt bewusst eng: Jedes gelistete Produkt bietet einen dokumentierten Weg zu lokaler Inferenz.

1. Zed: die beste vollständige lokale Copilot-Alternative

Zed ist der stärkste vollständige Ersatz, weil lokale Modelle sowohl für den Agent als auch für das Edit-Prediction-System dokumentiert sind. Edit Prediction ist Zeds Ebene für Inline-Vervollständigungen und umfasst ein- wie mehrzeilige Vorschläge. Diese doppelte Abdeckung ist selten und beseitigt die Unklarheit hinter vielen Aussagen, ein Tool „unterstütze Ollama“.

Das Produkt ist ein vollständiger Code-Editor und keine VS-Code-Erweiterung. Lokale Modelle lassen sich über Ollama, LM Studio, llama.cpp oder einen kompatiblen lokalen Server für Agent, Inline Assistant und verwandte KI-Funktionen betreiben. Eine separate Konfiguration für lokale Edit Prediction unterstützt Ollama, vLLM, llama.cpp server, LocalAI und weitere Server, die die OpenAI Completion API implementieren.

Diese Architektur macht Zed zur klarsten Lösung für Soloentwickler, die beide Abläufe lokal betreiben möchten und einen Editorwechsel akzeptieren. Gleichzeitig bedeutet sie die größte Workflow-Änderung in dieser Liste. Erweiterungen, Tastenkürzel, Gewohnheiten bei der Remote-Entwicklung, Debugging-Funktionen und Teamkonventionen müssen vor einer Migration geprüft werden.

Am besten geeignet für: Entwickler, die lokale Agentenarbeit und lokale Inline-Vervollständigung in einem Editor wünschen.
Besonderheit: Dokumentierte lokale Pfade für Agent und Edit Prediction.
Preis: Personal dauerhaft $0; Pro $10/Monat; Business $30/Platz/Monat; gehostete Nutzung über die in Pro enthaltenen $5 hinaus zum API-Listenpreis plus 10%.
Kostenlose Testphase: Pro für zwei Wochen oder bis $20 an Test-Token-Guthaben verbraucht sind; Business ohne kostenlose Testphase.

Zed-Preise und die versteckte Grenze

Zed Personal kostet dauerhaft $0 und umfasst 2,000 akzeptierte gehostete Edit Predictions sowie unbegrenzte Nutzung mit eigenen API-Schlüsseln oder externen Agenten. Zed Pro kostet $10 pro Monat, enthält unbegrenzte Edit Predictions und $5 an gehosteten Tokens; darüber hinaus wird die gehostete Nutzung zum API-Listenpreis plus 10% abgerechnet. Zed Business kostet $30 pro Platz und Monat und bietet unternehmensweite Modellrichtlinien, Datenkontrollen, eine einheitliche Ausgabenübersicht, unbegrenzte Edit Predictions und rollenbasierte Zugriffskontrollen.

Die Bezeichnung „Business“ kann falsche Erwartungen wecken. Der Tarif enthält weder ein festes LLM-Guthaben noch eine kostenlose Testphase; auch SSO, SAML und SCIM sind derzeit nicht verfügbar. Eine Mindestzahl an Plätzen gibt es nicht, Bestellformulare beginnen allerdings bei 25 Plätzen. Für Unternehmen mit hohen Anforderungen an die Identitätsverwaltung können die fehlenden SSO-Funktionen schwerer wiegen als Zeds vollständige Unterstützung lokaler Modelle.

Bei 10 Plätzen kostet Zed Business vor Modellnutzung oder lokaler Rechenleistung $3,600 pro Jahr. Copilot Business kostet bei gleicher Platzzahl $2,280. Allein die Plattformgebühren von Zed liegen damit $1,320 höher. Ausschlaggebend sollten das Editorkonzept und die vollständige lokale Kontrolle sein, nicht vermeintliche Lizenzeinsparungen.

Mini-Tutorial: Zed Agent und Edit Prediction über Ollama betreiben

Zed dokumentiert die beiden lokalen Pfade getrennt. Diese Trennung sollte auch bei der Einrichtung erhalten bleiben, damit ein funktionierender Agent nicht den falschen Eindruck erweckt, die Inline-Vorhersagen liefen ebenfalls lokal.

1. 1

   Lokale Laufzeit starten

   Ollama installieren, für Zeds dokumentiertes Agent-Beispiel ollama pull mistral ausführen und anschließend ollama serve starten, sofern der Dienst nicht automatisch läuft. Zed sollte die heruntergeladenen Ollama-Modelle erkennen und in der Modellauswahl anzeigen.

2. 2

   Agentenmodell auswählen

   Das Agent-Panel öffnen, das erkannte Ollama-Modell auswählen und mit einer begrenzten schreibgeschützten Aufgabe beginnen, etwa der Erklärung eines einzelnen Moduls. Anhand des ausgewählten Anbieters und der lokalen Prozessaktivität prüfen, ob die Anfrage Ollama erreicht.

3. 3

   Edit Prediction separat konfigurieren

   In Zeds Einstellungen edit_predictions öffnen. Das dokumentierte Beispiel des Anbieters setzt den Provider auf ollama, den Endpunkt auf http://localhost:11434, das Modell auf qwen2.5-coder:7b-base, das Prompt-Format auf infer und die maximale Zahl der Ausgabe-Tokens auf 512.

4. 4

   Beide Pfade nachweisen

   Auf einem unkritischen Testrechner die Netzwerkverbindung trennen. Einen Agent-Prompt senden, anschließend in einer repräsentativen Datei tippen und prüfen, ob eine Edit Prediction erscheint. Besteht der Agententest, während die Vervollständigung scheitert, läuft nur die Hälfte der Bereitstellung lokal.

Das konkrete Modell sollte zum Rechner und zur Aufgabe passen. Entscheidend am Tutorial ist die Prüfung beider Pfade, nicht der Name des Beispielmodells. Ein lokales Modell, das Werkzeuge nicht zuverlässig aufrufen kann, bleibt für Agent ungeeignet, selbst wenn seine Vervollständigungen akzeptabel sind.

2. Kilo Code: beste lokale Lösung in VS Code und JetBrains

Kilo Code ist die beste Wahl, wenn der Editor bleiben muss und sowohl Agentenarbeit als auch Inline-Vervollständigung einen lokalen Pfad benötigen. Die Open-Source-Erweiterungen unterstützen VS Code und JetBrains, die CLI ergänzt eine Terminaloberfläche. Damit fällt die Umstellung kleiner aus als bei Zed. Für den Agenten dokumentiert Kilo lokales Ollama, für Autocomplete lokales Codestral über Ollama oder LM Studio.

Diese Stärke ist mit zwei Einschränkungen verbunden. Kilos Autocomplete-Modell ist derzeit auf Codestral festgelegt; „lokale Vervollständigung“ bedeutet hier also keine freie Modellwahl. Auch die Hardware-Anforderung für den Agenten ist ernst zu nehmen: Die empfohlenen lokalen Modelle brauchen für ein vernünftiges Tempo mindestens 24 GB GPU-VRAM oder einen Mac mit mindestens 32 GB gemeinsamem Arbeitsspeicher.

Kilos eigene Dokumentation spricht ungewöhnlich offen über die Qualität. Für Agentenarbeit wird qwen3-coder:30b empfohlen, devstral:24b als Alternative genannt. Zugleich warnt Kilo, dass das kleinere Qwen-Modell häufiger Werkzeugaufrufe verfehlen, in Schleifen geraten oder Syntaxfehler erzeugen kann als ein führendes Cloud-Modell. Empfohlen wird ein Kontextfenster von mindestens 32k; dokumentiert ist außerdem ein standardmäßiges API-Timeout von 10 Minuten. Das sind betriebliche Anforderungen, keine Randnotizen.

Am besten geeignet für: Nutzer von VS Code oder JetBrains, die einen lokalen Agenten und einen unterstützten lokalen Vervollständigungspfad wünschen.
Besonderheit: Der am wenigsten disruptive Weg zu beiden lokalen Workflows in vertrauten Editoren.
Preis: Individual $0; Teams $15/Nutzer/Monat; Enterprise nach Angebot; Inferenz und Cloud-Rechenleistung werden separat berechnet.
Kostenlose Testphase: 14 Tage Enterprise.

Kilo-Preise: drei Rechnungen statt einer

Kilos Plattformtarife sind Individual für $0, Teams für $15 pro Nutzer und Monat sowie Enterprise zu einem individuellen Preis. Teams ergänzt Analysen, gemeinsam genutzte Agentenmodi, zentrale Abrechnung, gemeinsames BYOK, Datenschutzkontrollen und bevorzugten Support. Enterprise bringt SSO, OIDC, SCIM, Audit-Logs, Anbieterlimits, BYOK über ein privates Gateway, SLA-Zusagen und dedizierten Support hinzu. Die 14-tägige Testphase schaltet Enterprise-Funktionen frei; danach entscheidet sich der Kunde für Teams oder Enterprise.

Die Inferenz ist eine separate Entscheidung. Auto Free, BYOK oder lokal kosten $0 pro Monat an Kilo-Plattformgebühren für Inferenz. Kilo Gateway hat kein Abonnement und berechnet die exakten Anbieterpreise ohne Aufschlag. Kilo Pass bietet Starter für $19 pro Monat mit bis zu $26.60 monatlichem Guthaben, Pro für $49 mit bis zu $68.60 und Expert für $199 mit bis zu $278.60. Auf Guthabenkäufe fällt eine Bearbeitungsgebühr von 5% an.

Cloud-Funktionen erzeugen eine dritte Rechnung. Code Review kostet $0.33 pro Stunde. Cloud Agent Docker und Small kosten jeweils $0.60 pro Stunde. Gas Town und Cloud Agent Standard liegen jeweils bei $1.20 pro Stunde. Abgerechnet wird sekundengenau; die Modellinferenz bleibt davon getrennt.

Für 10 Entwickler kostet Kilo Teams $1,800 pro Jahr, Copilot Business dagegen $2,280. Die Differenz von $480 ist die lokale Kostengrenze: Sobald zusätzliche Hardware und Verwaltung zusammen mehr als $40 pro Monat kosten, verschwindet die scheinbare Plattformeinsparung. Schon wenige Wartungsstunden eines Entwicklers am lokalen Dienst können diese Grenze überschreiten.

3. Cline: bester transparenter lokaler Agent in VS Code

Cline ist die beste spezialisierte Lösung für einen lokalen, zustimmungsgesteuerten Coding-Agenten in VS Code. Dateiänderungen, Terminalaktionen und die Wahl des Modellanbieters bleiben sichtbar, ohne dass für Einzelnutzer ein Plattformabonnement anfällt. Der lokale Pfad über Ollama, LM Studio und Atomic Chat ist klar dokumentiert.

Cline ersetzt nicht jede Copilot-Aufgabe. Das Kernprodukt ist ein Agent und kein eigener Ersatz für Tab-Vervollständigungen. Wer beim Tippen lokal erzeugten Vorschautext benötigt, kombiniert Cline mit einer separaten Vervollständigungserweiterung oder wählt Zed, Kilo Code oder Tabby. Eine zweite Erweiterung kann architektonisch sinnvoll sein, führt aber zu zwei Richtlinien, zwei Updatepfaden und möglicherweise zwei zu verwaltenden Modellservern.

Am besten passt Cline zu Entwicklern, die einem lokalen Modell eine klar begrenzte Aufgabe übergeben, jeden vorgeschlagenen Schritt prüfen und ihre bestehende VS-Code-Umgebung behalten möchten. Der passende Auftrag lautet eher „Analysiere diesen fehlgeschlagenen Test und schlage einen Patch vor“ als „Sage bei jedem Tastendruck die nächsten sechs Tokens voraus“. Diese Arbeitsweise ist langsamer und bewusster als Copilot-Vervollständigung, kann dafür aber einen größeren Teil einer Aufgabe über mehrere Dateien übernehmen.

Am besten geeignet für: VS-Code-Nutzer, die eine sichtbare, kontrollierbare lokale Agentenschleife wünschen.
Besonderheit: Kostenlose Agentenoberfläche für Einzelnutzer mit dokumentierten lokalen Laufzeiten und ohne Pflichtabonnement.
Preis: Open Source kostenlos; Enterprise nach Angebot; Inferenz wird separat bereitgestellt.
Kostenlose Testphase: Keine Enterprise-Testphase angegeben; der Open-Source-Tarif dient zur Evaluierung.

Cline-Preise und die Hardwareleiter

Cline Open Source ist für einzelne Entwickler kostenlos. Es gibt weder Abonnement- noch Platzgebühren; gehostete Inferenz wird jedoch nutzungsabhängig berechnet, sofern der Entwickler keinen eigenen Schlüssel oder ein lokales Modell verwendet. Der kostenlose Tarif nennt die VS-Code-Erweiterung und CLI, eine sichere clientseitige Architektur, MCP Marketplace, Multi-Root-Workspaces und Community-Support.

Cline Enterprise wird individuell bepreist. Enthalten sind die JetBrains-Erweiterung, SSO, SLA, dedizierter Support, zentrale Abrechnung, Konfigurationsverwaltung, rollenbasierte Zugriffskontrolle, Limits für Inferenzanbieter, ein Team-Dashboard und Authentifizierungsprotokolle. Auf der aktuellen Preisseite ist keine kostenlose Enterprise-Testphase angegeben.

Die Hardwareanleitung setzt eine nützlichere Grenze als der Plattformpreis von $0. Cline ordnet 16 bis 32 GB RAM kleinen oder quantisierten Modellen zu, 32 bis 64 GB mittelgroßen Modellen und 64 GB oder mehr größeren Modellen und Kontextfenstern. Die standardmäßigen lokalen Endpunkte sind http://localhost:11434 für Ollama und http://localhost:1234 für LM Studio.

Diese Abstufung sollte den Pilotversuch bestimmen. Ein Laptop mit 16 GB kann die Verbindung erfolgreich nachweisen und dennoch am vorgesehenen Workflow scheitern: durch langsame Generierung, zu wenig Kontext oder unzuverlässige Werkzeugnutzung. Bereit für den Einsatz ist die Konfiguration erst, wenn das Zielmodell genug vom Repository lesen und die repräsentative Aufgabe innerhalb der Geduldsschwelle des Teams erledigen kann.

Clines Rolle in einer gemischten lokalen Konfiguration

Eine praktikable Aufteilung nutzt Cline für explizite Agentensitzungen und einen eigenen lokalen Anbieter für den Schreibfluss bei der Vervollständigung. Diese Architektur kann ein einzelnes Allzweckmodell übertreffen: Ein Agent braucht Werkzeugnutzung und Schlussfolgern über lange Kontexte, Vervollständigung dagegen niedrige Latenz und Fill-in-the-Middle-Training. Der Preis dafür ist doppelter Betriebsaufwand.

Für Soloentwickler besteht diese Verdopplung womöglich nur aus einigen Einstellungen. In einem Unternehmen bedeutet sie zwei freigegebene Modelle, zwei Endpunktrichtlinien, zwei Telemetrieprüfungen und zwei Rollbackpfade. Der Vergleich von Coding-Agenten für Unternehmen behandelt Governance ausführlicher. Die unmittelbare Cline-Entscheidung ist einfacher: Das Tool passt, wenn Transparenz des Agenten wichtiger ist als die Vollständigkeit eines einzigen Produkts.

4. Tabby: bester zentraler selbst gehosteter Vervollständigungsserver

Tabby ist die beste Wahl, wenn vor allem die Copilot-Vervollständigung durch einen zentral betriebenen, selbst gehosteten Dienst ersetzt werden soll. Der Open-Source-Coding-Assistent ist darauf ausgelegt, dass ein Team seinen eigenen LLM-gestützten Vervollständigungsserver betreibt. Entwickler verbinden sich über Editor-Erweiterungen, während die Organisation den dahinterliegenden Dienst kontrolliert.

Dieses serverzentrierte Konzept gehört in eine andere Produktkategorie als ein Agent, der lokal auf dem Laptop läuft. Es ist sinnvoll, wenn zehn oder fünfzig Entwickler gemeinsam freigegebene Modelle, Repository-Kontext, Zugriffskontrollen und Beobachtbarkeit nutzen sollen, statt Ollama jeweils selbst zu betreiben. Zugleich übernimmt die Organisation die Verantwortung für Verfügbarkeit, Upgrades, GPU-Kapazität, Authentifizierung und Störungsbehebung.

Am stärksten passt Tabby zu einer regulierten oder datenschutzsensiblen Entwicklungsgruppe, die zentrale Vervollständigung höher gewichtet als autonomes Agentenverhalten. Answer Engine und Code-Browsing erweitern den Funktionsumfang, doch die Vervollständigung bleibt der Grund, Tabby einem desktoporientierten Agenten vorzuziehen. Ein Soloentwickler kann Community betreiben, kommt mit Aider, Cline, Kilo Code oder Zed in der Regel aber mit weniger Infrastruktur aus.

Am besten geeignet für: Teams, die einen einzigen kontrollierten, selbst gehosteten Vervollständigungsserver wünschen.
Besonderheit: Zentralisierte, auf lokalen Betrieb ausgelegte Bereitstellung mit Editor-Erweiterungen und Teamtarifen.
Preis: Community $0/Nutzer/Monat; Team $19/Nutzer/Monat; Enterprise nach Angebot; Pochi-Cloud-Nutzung separat.
Kostenlose Testphase: Keine zeitlich begrenzte Team- oder Enterprise-Testphase angegeben; Community unterstützt bis zu 5 Nutzer.

Tabby-Preise: Datenschutz ohne Lizenzrabatt

Tabby Community kostet $0 pro Nutzer und Monat für bis zu 5 Nutzer. Tabby Team kostet $19 pro Nutzer und Monat für bis zu 50 Nutzer. Tabby Enterprise ist ein individuell bepreister, jährlich abgerechneter Tarif mit unbegrenzter Nutzerzahl, SSO, maßgeschneiderter Bereitstellung, einem dedizierten Slack-Supportkanal und Priorisierung auf der Roadmap.

Pochi von Tabby Cloud hat eine separate nutzungsbasierte Modellrechnung. Die aktuelle Preisseite umfasst $20 kostenloses Monatsguthaben, rechnet automatisch ab, sobald die Nutzung $10 überschreitet, oder bei kleineren Beträgen am Monatsende und bezeichnet Tab Completion als stets kostenlos ohne Nutzungslimit. Dieses Cloud-Angebot darf nicht mit den Rechenkosten des selbst gehosteten Servers verwechselt werden.

Bei 10 Plätzen kosten Tabby Team und Copilot Business als Plattform jeweils $2,280 pro Jahr. Tabby benötigt zusätzlich Infrastruktur. Die Dokumentation nennt rund 8 GB VRAM für CodeLlama-7B im int8-Modus und weist darauf hin, dass eine Instanz nur eine GPU unterstützt. Der konkrete Serverpreis hängt von vorhandener Hardware, Auslastung, Redundanz und Supportanforderungen ab, doch die Richtung ist eindeutig: Tabby wird für Kontrolle gekauft, nicht als günstigere Lizenz.

Die Ein-GPU-Grenze

Das Limit von einer GPU pro Tabby-Instanz ist die betriebliche Grenze, die eingeplant werden muss. Eine einzelne GPU kann für ein kleines Team vollkommen ausreichen und bei einer gleichzeitig aktiven Programmierphase zur Warteschlange werden. Skalierung verlangt dann zusätzliche Instanzen und Routingentscheidungen, statt mehrere GPUs an eine Instanz anzuschließen.

Gemessen werden sollten die Zeit bis zur ersten Vervollständigung und die akzeptierten Vorschläge bei Spitzenlast, nicht auf einem unbeschäftigten Server. Ein schneller Durchschnitt kann eine schlechte Erfahrung am 95. Perzentil verbergen, durch die Entwickler Vorschläge zu ignorieren lernen. Zu testen sind außerdem Modellneustarts, das Fallback-Verhalten der Erweiterung und der Ausfall des Dienstes. Vervollständigung ist auch deshalb wertvoll, weil sie im Schreibfluss verschwindet; regelmäßiges Warten zerstört diesen Vorteil.

5. Aider: bester Git-nativer Terminal-Workflow

Aider ist die beste Alternative mit lokalen Modellen für Entwickler, die ihre Agentensitzung über Repository und Git-Verlauf statt über die Editoroberfläche organisieren möchten. Das Tool läuft im Terminal, erstellt eine Übersicht der Codebasis, bearbeitet Dateien, legt automatisch Commits an und kann Linter sowie Tests ausführen. Für die Apache-2.0-Software fällt kein Plattformabonnement an.

Der Ablauf ist konkret: Repository öffnen, relevante Dateien hinzufügen oder die Repository-Übersicht den Kontext steuern lassen, eine Änderung anfordern, den Diff prüfen und die Änderung mit Git behalten oder rückgängig machen. Das spricht Entwickler an, die Terminal- und Versionsverwaltungswerkzeugen bereits vertrauen. Weniger natürlich wirkt es für alle, die einen Agenten in der Seitenleiste, visuelle Prüfpunkte und Hintergrundvervollständigung beim Tippen erwarten.

Aider verbindet sich mit nahezu jedem Cloud- oder lokalen LLM, darunter Ollama. Die Ollama-Dokumentation empfiehlt das Modellpräfix ollama_chat/ und weist auf einen tückischen Fehler hin: Ollama verwendet standardmäßig ein Kontextfenster von 2k und verwirft darüber hinausgehendes Material stillschweigend. Eine Sitzung kann dadurch funktionsfähig wirken, obwohl Repository-Kontext verloren geht — schlechter als eine eindeutige Fehlermeldung.

Am besten geeignet für: Terminalorientierte Entwickler, die einen Git-zentrierten lokalen Agenten wünschen.
Besonderheit: Repository-Übersicht, automatische Commits, Diffs, Linting und Tests in einer einzigen Open-Source-Schleife.
Preis: $0 für Apache-2.0-Software; Modellnutzung oder lokale Rechenleistung separat; keine kostenpflichtigen Plattformtarife.
Kostenlose Testphase: Nicht zutreffend, da die Software kostenlos und quelloffen ist.

Aider-Preise und die Solo-Kostengrenze von $120

Aider bietet weder Personal-, Pro-, Team- noch Enterprise-Plattformtarife. Die Software ist unter Apache 2.0 kostenlos. Bezahlt werden der Modellanbieter oder der Rechner, auf dem das Modell läuft.

Der Ersatz eines Copilot-Pro-Abonnements für $10 pro Monat spart höchstens $120 pro Jahr. Das ist die lokale Kostengrenze für eine Einzelperson. Werden eine neue GPU, zusätzlicher Arbeitsspeicher, Einrichtungszeit oder langsamere Ausgaben allein gekauft beziehungsweise akzeptiert, um das Abonnement einzusparen, geht die Rechnung selten auf. Ist leistungsfähige Hardware bereits vorhanden und sind Datenschutz, Offline-Arbeit oder Modellkontrolle der eigentliche Grund, wird aus den $120 ein Nebenvorteil.

Zuerst sollte der Kontext geprüft werden, nicht die Raffinesse des Prompts. Aider dokumentiert ein Ollama-Serverbeispiel mit 8k und passt den Kontext an, um stilles Abschneiden zu reduzieren. Größere Repositories können deutlich mehr benötigen. Wenn ein lokales Modell Anforderungen vergisst, Dateien wiederholt neu öffnet oder das falsche Symbol ändert, sollten Kontextfenster und Repository-Übersicht geprüft werden, bevor das Interaktionsformat verantwortlich gemacht wird.

6. OpenCode: bester lokaler Agent für mehrere Oberflächen

OpenCode ist die beste Wahl für einen Open-Source-Agenten, der Entwickler über Terminal, IDE-Erweiterung und Desktop-App hinweg begleitet. Das Tool unterstützt mehr als 75 Modellanbieter, darunter lokale Modelle, und verlangt für die Kernsoftware kein kostenpflichtiges Abonnement. Diese Flexibilität der Oberflächen ist der Vorteil gegenüber Aiders terminalzentriertem Konzept.

Lokales Ollama funktioniert über einen OpenAI-kompatiblen Anbieterendpunkt unter http://localhost:11434/v1. Die Anbieterdokumentation legt die Konfiguration offen, statt sie zu verbergen. Wenn Werkzeugaufrufe scheitern, empfiehlt sie unter anderem, mit einem Kontextfenster von ungefähr 16k bis 32k zu beginnen. Für Teams, die explizite Kontrolle wünschen, ist das ein Vorteil; Nutzer, die automatische Erkennung erwarten, haben mehr Arbeit.

OpenCodes lokales Konzept dreht sich um Agentensitzungen und ist kein vollständiger Ersatz für Copilots Inline-Vervollständigung. Das Tool kann in einer IDE arbeiten, seine prägende Fähigkeit bleibt jedoch derselbe mehrstufige Agent über mehrere Oberflächen. Entscheidend sind Portabilität der Oberfläche und Anbietervielfalt, nicht Tab-Vorschläge.

Am besten geeignet für: Entwickler, die denselben lokal betreibbaren Agenten in Terminal, IDE und Desktop einsetzen möchten.
Besonderheit: Mehr als 75 Anbieter und drei Interaktionsoberflächen.
Preis: Kernsoftware $0 Open Source; optional Go $10/Monat; Enterprise individuell pro Platz.
Kostenlose Testphase: Interner Pilot mit der Open-Source-Version vor einem Enterprise-Vertriebsgespräch.

OpenCode-Preise und Datenverarbeitung

Die Kernsoftware von OpenCode ist kostenlos und quelloffen; Nutzer wählen ein lokales, BYOK-, kostenloses oder gehostetes Modell. OpenCode Zen ist ein optionales Pay-as-you-go-Gateway mit Modellpreisen pro Token. OpenCode Go ist ein optionales Abonnement für $10 pro Monat mit gehosteten offenen Coding-Modellen. Die aktuellen Limits sind als Wertobergrenzen formuliert: $12 pro 5 Stunden, $30 pro Woche und $60 pro Monat.

OpenCode Enterprise wird individuell pro Platz bepreist. Stellt ein Kunde sein eigenes LLM-Gateway bereit, berechnet OpenCode nach eigener Aussage keine Gebühren für die verwendeten Tokens. Zur Evaluierung dient zunächst ein interner Test des Open-Source-Produkts; anschließend folgt ein Vertriebsgespräch zu zentraler Konfiguration, SSO, internem Gateway und Implementierungsunterstützung.

Die Standardaussage zur Datenverarbeitung ist deutlich: OpenCode speichert nach eigenen Angaben weder Code noch Kontext; die Verarbeitung findet lokal oder über direkte Aufrufe beim gewählten Anbieter statt. Die Ausnahme ist die optionale Gesprächsfreigabe, durch die Sitzungsdaten nach außen übertragen werden. Die Enterprise-Dokumentation empfiehlt, die Freigabe während des Tests zu deaktivieren. Eine Datenschutzprüfung sollte sowohl den Standardpfad als auch jede optionale Ausleitung erfassen.

Welches Tool passt zu welchem Bedarf?

Zuerst die fehlende Fähigkeit bestimmen und dann die kleinste Workflow-Änderung wählen, die sie liefert. Produktbegeisterung ist hier eine schlechte Entscheidungsmethode, weil jede Option Kosten und Komplexität auf eine andere Ebene verlagert.

Bei VS Code bleiben, wenn lokale Agentenarbeit genügt

Der native VS-Code-Pfad verursacht die geringste Umstellung für Entwickler oder Teams, die lokalen Chat, Planung und unterstützte Agentenaufgaben wünschen, aber die gehostete Copilot-Vervollständigung behalten oder ganz darauf verzichten können. Erweiterungen, Debugging-Gewohnheiten, Remote-Umgebungen und das Supportwissen des Teams bleiben erhalten. Der Wendepunkt ist die Inline-Vervollständigung: Müssen auch diese Daten lokal bleiben, reicht der integrierte BYOK-Pfad nicht aus.

Für einen kleinen Pilotversuch ist das besonders sinnvoll. Einen lokalen Anbieter konfigurieren, nicht genehmigte Modelle ausblenden, wo nötig ein Hilfsmodell auswählen und dokumentieren, welche Funktionen weiterhin von GitHub abhängen. Eine weitere Agentenerweiterung sollte erst hinzukommen, wenn eine repräsentative Aufgabe zeigt, dass der native Aufbau etwas Wesentliches vermissen lässt.

Zed wählen, wenn Vollständigkeit wichtiger ist als Editor-Kontinuität

Zed gewinnt bei technischen Soloentwicklern oder kleinen Produktgruppen, die im Gegenzug für ein einheitliches lokales System aus Agent und Edit Prediction zu einem neuen Editor wechseln. Der Wendepunkt ist die Editorkompatibilität. Scheitert auch nur eine erforderliche Erweiterung, ein Debugger, eine Remote-Umgebung oder ein Barrierefreiheits-Workflow, ist Kilo Code die sicherere Wahl.

In größeren Organisationen kann die Identitätsverwaltung noch vor der Editorpassung den Ausschlag geben. Die aktuellen Business-Kontrollen umfassen Modell- und Datenrichtlinien, SSO, SAML und SCIM sind jedoch nicht verfügbar. Ein Unternehmen, das diese Kontrollen verlangt, darf eine Roadmap nicht wie eine vorhandene Sicherheitsfunktion behandeln.

Kilo Code wählen, wenn VS Code oder JetBrains bleiben muss

Kilo Code gewinnt, wenn sowohl lokale Agentenarbeit als auch lokales Autocomplete in einem vorhandenen Editor erforderlich sind. Statt die gesamte Entwicklungsumgebung auszutauschen, ändern Entwickler nur Erweiterung und Modellkonfiguration. Gegen Kilo spricht ein anderes zwingend erforderliches Vervollständigungsmodell als Codestral oder Hardware, die den dokumentierten Speicherbedarf des lokalen Agenten nicht erfüllt.

Auch die Kostengeschichte ist bei Kilo besonders verlockend und leicht zu übertreiben. Zehn Teams-Plätze sparen gegenüber Copilot Business vor Rechenleistung und Arbeitsaufwand $480 pro Jahr. Das Produkt sollte wegen passender Erweiterungsoberflächen und Anbietersteuerung gewählt werden; die Preisdifferenz ist dann ein kleiner Ausgleich.

Cline wählen, wenn der Agent explizit und beaufsichtigt arbeiten soll

Cline gewinnt, wenn Entwickler in VS Code eine bewusste Agentenschleife wünschen und dasselbe Produkt keine Inline-Vorschläge erzeugen muss. Es passt zu aufgabengroßen Arbeiten, bei denen Dateizugriffe, Änderungen, Befehle und Zustimmungen sichtbar bleiben sollen. Die Wahl kippt zu Kilo oder Zed, wenn ein zweites lokales Vervollständigungssystem zu viel Konfigurationsaufwand erzeugen würde.

Für Teams ist außerdem die Lücke in den veröffentlichten Preisen relevant. Die Einzelnutzung ist kostenlos, Enterprise wird individuell bepreist. Zuerst sollte der Open-Source-Workflow geprüft werden; ein Angebot vom Vertrieb ist erst sinnvoll, wenn erforderliches SSO, Anbieterlimits, Dashboard und JetBrains-Oberfläche feststehen.

Tabby wählen, wenn die Organisation den Dienst betreibt

Tabby gewinnt, wenn ein Plattform- oder Sicherheitsteam einen zentralen Vervollständigungsdienst statt einer Modelllaufzeit auf jedem Laptop möchte. Es ist die klarste Lösung für ein gemeinsam genutztes, freigegebenes Modell und eine vorhersehbare Editor-Erweiterung. Fehlt der Gruppe ein Verantwortlicher für Verfügbarkeit, Upgrades, Kapazität und Entwicklersupport, kippt die Entscheidung.

Diese Verantwortung sollte nicht stillschweigend „dem Infrastrukturteam“ zugewiesen werden. Person oder Gruppe benennen, ein Serviceziel definieren und die GPU vor dem Rollout kalkulieren. Ein lokaler Dienst ohne Betreiber wird zu einer unzuverlässigeren Ausgabe des Cloud-Produkts, das er ersetzen sollte.

Aider oder OpenCode wählen, wenn das Terminal im Mittelpunkt steht

Aider gewinnt, wenn Git-Diffs und automatische Commits die natürliche Kontrolloberfläche sind. OpenCode gewinnt, wenn derselbe Agent zwischen Terminal, IDE und Desktop wechseln und dabei eine breite Auswahl an Modellanbietern behalten soll. Keines der beiden Tools ist eine direkte Antwort auf lokale Inline-Vervollständigung.

Der Tie-Breaker ist die Struktur des Workflows. Aider passt zu einem Repository, einem Terminal-Thread und einer engen Diff-Prüfschleife. OpenCode passt zu mehreren Oberflächen, Sitzungen und Anbieterkonfigurationen. Der Leitfaden zu Claude-Code-Alternativen ist der passende Nachbarvergleich, wenn die Entscheidung überwiegend Terminalagenten statt Copilot-ähnliche Vervollständigung betrifft.

Kostenvergleich: die lokale Kostengrenze berechnen

Lokale Modelle ermöglichen es, die Inferenz selbst zu betreiben — sie lassen Kosten nicht verschwinden. Bei 10 Plätzen betragen die öffentlich angegebenen jährlichen Plattformgebühren:

• Kilo Teams: $1,800
• GitHub Copilot Business: $2,280
• Tabby Team: $2,280
• Zed Business: $3,600

Kilo ist in diesem Vergleich von vier kostenpflichtigen Teamtarifen das einzige Produkt mit einer öffentlich bezifferbaren Einsparung. Sie beträgt $480 pro Jahr oder $40 pro Monat. Dieser Betrag ist die lokale Kostengrenze: die maximale zusätzliche Monatsausgabe, die die Bereitstellung verkraftet, bevor der Plattformvorteil verschwindet.

Zur Grenze gehört mehr als der Kaufpreis einer GPU. Einzurechnen sind annualisierte Hardwarekosten, Strom, Hosting oder Rack-Zuordnung, Monitoring, Backups, Modelldownloads, Patches, Endpunktsicherheit, Störungsbehebung und die Zeit für Entwicklerhilfe bei einem langsamen Dienst. Hinzu kommt der Qualitätsnachteil, wenn ein kleineres lokales Modell mehr Versuche oder zusätzlichen Prüfaufwand verursacht.

Bei Tabby Team liegt die lokale Kostengrenze gegenüber Copilot Business bei null, weil die Platzpreise identisch sind. Durch jede Ausgabe für Rechenleistung und Verwaltung wird Tabby in baren Kosten teurer. Richtig kann die Entscheidung trotzdem sein, wenn Datenkontrolle, Verfügbarkeit in isolierten Netzen, Modellunabhängigkeit oder einheitliches Vervollständigungsverhalten den Gegenwert bilden.

Zed Business liegt bei 10 Plätzen bereits $1,320 über Copilot Business. Diesen Aufpreis muss die Editor- und Kontrollschicht verdienen. Für Solo-Nutzer sieht die Rechnung anders aus: Personal ist kostenlos und kann lokale Modelle verwenden, während Pro beim gleichen Plattformpreis von $10 pro Monat wie Copilot Pro zusätzliche gehostete Zed-Funktionen bietet.

Aider, Cline Open Source, OpenCode Core, Kilo Individual, Zed Personal und Tabby Community können die Softwarekosten in ihrem jeweiligen Einsatzbereich auf $0 senken. Für einen Nutzer von Copilot Pro beträgt die maximale Abonnementersparnis $120 pro Jahr. Mit bereits vorhandener leistungsfähiger Hardware kann das nützlich sein. Einen Rechner hauptsächlich zur Rückgewinnung von $120 pro Jahr zu kaufen, lohnt sich nicht.

Welche Optionen zu vermeiden sind

Continue ist in dieser Kategorie das eindeutigste Produkt, das für eine neue unterstützte Bereitstellung nicht gewählt werden sollte. Die aktuelle Startseite nennt die Übernahme von Continue durch Cursor und erklärt, der Open-Source-Code bleibe als Grundlage verfügbar. Eine bestehende Community kann Code auf dieser Basis forken oder pflegen. Das ist jedoch nicht dasselbe wie ein aktiv positioniertes, unabhängiges Produkt mit aktuellem Preis- und Supportpfad.

Bestehende Continue-Nutzer müssen nicht in Panik geraten. Versionen festschreiben, Repository und Lizenz prüfen, Modellendpunkte dokumentieren und die Verantwortung für die Wartung klären. Neue Käufer sollten Continue nicht neben Zed, Kilo Code, Cline, Tabby, Aider und OpenCode einordnen, ohne diese Veränderung beim Support zu berücksichtigen.

Zu vermeiden sind auch Cloud-first-Assistenten, deren „lokal“-Versprechen lediglich lokale Dateiindizierung, eine Desktop-Anwendung oder ein privates Cloud-Konto meint. Entscheidend ist, wo die Modellinferenz für genau die benötigte Oberfläche stattfindet. Chat, Agentenaufrufe, Inline-Vervollständigung, Embeddings, Telemetrie, Absturzberichte, Updates und optionale Freigaben müssen getrennt abgefragt werden.

Ebenso ungeeignet ist das größte lokale Modell, das sich gerade noch in den Rechner laden lässt. Belegt ein Modell fast den gesamten verfügbaren Speicher, bleibt wenig Platz für Kontext, Editor, Build-Werkzeuge, Container und Betriebssystem. Ein kleineres Modell mit konsistenten Werkzeugaufrufen und akzeptabler Latenz erledigt häufig mehr Arbeit als ein größeres, das auslagert, Timeouts produziert oder Kontext verliert.

Der Schritt am Montag: Pilot mit zwei Entwicklern

Vor einer Änderung des Teamtarifs sollte ein Repository eine Woche lang mit zwei Entwicklern getestet werden. Ziel ist nicht, anhand eines synthetischen Prompts ein Modell zum Sieger zu erklären, sondern die erste betriebliche Grenze im vorgesehenen Workflow zu finden.

1. 1

   Die fehlende Copilot-Aufgabe benennen

   Eine primäre Aufgabe auswählen: agentische Ticketarbeit, Inline-Vervollständigung, zentrales Self-Hosting oder terminalgesteuerte Änderungen. Ein Pilot, der gleichzeitig jede Copilot-Funktion ersetzen will, liefert ein uneindeutiges Ergebnis.

2. 2

   Ein repräsentatives Repository auswählen

   Ein Repository mit dem üblichen Sprachmix, den normalen Tests und Build-Zeiten sowie typischer Abhängigkeitsstruktur und Sicherheitsanforderungen verwenden. Beide Entwickler erhalten dieselben drei begrenzten Aufgaben: ein Modul erklären, eine kleine Änderung über mehrere Dateien umsetzen und einen fehlgeschlagenen Test reparieren.

3. 3

   Bereitstellung festschreiben

   Toolversion, lokale Laufzeit, Modell und Quantisierung, Kontextfenster, Endpunkt, Hardware, Netzwerkzustand, Freigabeeinstellung und jedes gehostete Fallback dokumentieren. Ohne diese Angaben lässt sich ein gutes Ergebnis nicht reproduzieren und ein schlechtes nicht diagnostizieren.

4. 4

   Den Workflow statt der Token-Ausgabe messen

   Zeit bis zur ersten brauchbaren Antwort, Zeit bis zu einem gültigen Diff, gegebenenfalls akzeptierte Inline-Vorschläge, fehlgeschlagene Werkzeugaufrufe, manuelle Eingriffe, Wiederholungen und Prüfzeit erfassen. Auch die Spitzenlatenz notieren, wenn beide Entwickler den Dienst gleichzeitig verwenden.

5. 5

   Budgetentscheidung treffen

   Die jährlichen Plattformkosten mit Rechenleistung und dem geschätzten monatlichen Betriebsaufwand vergleichen. Der lokale Pfad bleibt nur, wenn er die benannte Kontrollanforderung erfüllt und innerhalb der lokalen Kostengrenze liegt — oder wenn der Kontrollvorteil das Überschreiten dieser Grenze eindeutig rechtfertigt.

Die Entscheidung am Montag sollte klein ausfallen: beim vorhandenen lokalen VS-Code-Pfad bleiben, den Pilotversuch um eine gelistete Alternative erweitern oder aufhören. Weder Plätze kaufen noch Editoren migrieren oder gemeinsam genutzte GPUs bereitstellen, bevor der Pilot zeigt, welche konkrete Copilot-Aufgabe ersetzt wird.

Häufig gestellte Fragen

Kann GitHub Copilot lokal verwendet werden?

VS Code kann ein lokales Modell ohne GitHub-Konto oder Copilot-Tarif für Chat, unterstützte Agenten-Workflows und Hilfsaufgaben verwenden. GitHubs gehostete Copilot-Modelle laufen dadurch nicht lokal, und der integrierte lokale Pfad umfasst keine üblichen Inline-Vorschläge.

Lässt sich Copilot lokal ausführen?

Die präzise Antwort lautet: VS Code bindet das lokale Modell über BYOK ein. Dazu wird ein Anbieter wie Ollama verbunden und das Modell für Chat oder unterstützte Agentenarbeit ausgewählt. Inline-Vervollständigung, semantische Suche und embeddinggestützte Funktionen haben eigene Abhängigkeiten.

Kann Copilot in VS Code lokale Modelle verwenden?

Ja, für Chat und unterstützte Agentenarbeit über die Modellsteuerung von VS Code. Nein, für das übliche Modell der Copilot-ähnlichen Inline-Vorschläge. Kilo Code und Tabby können lokale Vervollständigung in VS Code ergänzen; Cline fügt einen lokalen Agenten hinzu.

Gibt es eine kostenlose GitHub Copilot Alternative mit lokalen Modellen?

Ja. Zed Personal, Kilo Individual, Cline Open Source, Tabby Community, Aider und OpenCode Core bieten alle einen Softwarepfad für $0. Hardware, gehostete Inferenz, Team-Governance und Wartung können trotzdem Kosten verursachen.

Die Checkliste für das KI-Business-Workflow-Audit und die nächste evidenzbasierte Build-Analyse gibt es mit einer Anmeldung zum Newsletter.