Wer im September 2026 nach einem KI-gestützten Code-Editor sucht, stößt unweigerlich auf zwei sehr unterschiedliche Geschichten. Auf der einen Seite steht Zed, ein in Rust geschriebener Editor, der sich selbst als “KI-nativ” bezeichnet und mit auffällig kurzen Startzeiten wirbt. Auf der anderen Seite steht Continue.dev, einst einer der bekanntesten Open-Source-Assistenten für VS Code und JetBrains, dessen Geschichte als eigenständiges Produkt im Sommer 2026 endete. Für Entwicklerinnen und Entwickler in Österreich, die ihre Werkzeugkette gerade neu ordnen, ist der Vergleich mehr als eine akademische Übung: Wer noch eine Continue-Installation im Einsatz hat, muss jetzt handeln, weil das Projekt keine Updates und keine Sicherheitspatches mehr erhält.
Dieser Artikel stellt beide Werkzeuge Punkt für Punkt gegenüber, mit Daten zu Preisen, Performance und Plattformen, und zeigt, wohin ehemalige Continue.dev-Nutzer sinnvoll wechseln. Dabei geht es nicht nur um Geschwindigkeit oder Komfort. Wer heute noch produktiven Code mit einer Erweiterung schreibt, die seit Juni 2026 keine Sicherheitsupdates mehr bekommt, trägt ein Risiko, das mit jeder neuen Schwachstelle in den zugrunde liegenden Bibliotheken wächst. Genau deshalb ist dieser Vergleich auch ein Sicherheitsthema, nicht nur eine Frage des persönlichen Geschmacks bei der Werkzeugwahl.
Continue.dev ist tot: Was im Juni 2026 geschah
Continue.dev war über Jahre hinweg die erste Adresse für Entwickler, die einen Open-Source-Ersatz für GitHub Copilot suchten. Das Projekt lief unter Apache-2.0-Lizenz und ließ sich als Erweiterung in VS Code, als JetBrains-Plugin und als Kommandozeilen-Tool nutzen. Der Clou war die freie Wahl des Sprachmodells: Wer ein eigenes API-Konto bei Anthropic, OpenAI oder Google hatte, konnte es einbinden, genauso wie lokale Modelle über Ollama. Continue richtete sich damit gezielt an Teams mit Compliance-Vorgaben, etwa in regulierten Branchen, in denen Code das eigene Netzwerk nicht verlassen darf.
Diese Geschichte endete Mitte Juni 2026. Mehrere Branchenberichte datieren die stille Übernahme durch Anysphere, das Unternehmen hinter Cursor, auf den 16. Juni 2026, mit einer offiziellen Bestätigung durch Cursor zwei Tage später. Auf der Startseite von Continue.dev steht seither ein kurzer Hinweis, dass das Produkt von Cursor übernommen wurde und das ursprüngliche Ziel des Teams, Entwickler zu stärken statt sie zu ersetzen, in der weiteren Arbeit fortbestehe. Der letzte Release trug die Versionsnummer 2.0.0-vscode und erschien am 19. Juni 2026, mit VS-Code-Erweiterung, CLI und JetBrains-Plugin im gleichen Umfang wie zuvor. Seither ist das GitHub-Repository von continuedev/continue auf Nur-Lese-Modus gesetzt, neue Issues und Pull Requests werden nicht mehr angenommen.
Für bestehende Nutzer bedeutete das zunächst keinen sofortigen Ausfall. Lokale Installationen der Version 2.0.0 laufen technisch weiter, solange die eigenen API-Schlüssel gültig bleiben. Der Haken: Die gehosteten Cloud-Dienste von Continue, inklusive Team-Konfigurationen und Abrechnung, wurden zum 15. Juli 2026 abgeschaltet, alle dort gespeicherten Daten wurden gelöscht. Wer bis zu diesem Stichtag nichts exportiert hatte, hat seine Cloud-Konfiguration verloren. Genau diese Lücke sorgt seit Wochen für Suchanfragen von Entwicklern, die jetzt nach einer dauerhaften Lösung suchen, nicht mehr nach einem Workaround für ein sterbendes Projekt.
Was ist Zed? Der Rust-Editor mit KI im Kern
Zed ist ein nativ in Rust entwickelter Code-Editor, der von ehemaligen Mitarbeitern des Atom-Projekts gegründet wurde. Anders als VS Code, das auf der Electron-Technologie und damit letztlich auf einem eingebetteten Chromium-Browser aufbaut, kompiliert Zed direkt zu nativem Maschinencode. Das erklärt einen Großteil des Performance-Unterschieds, den wir im nächsten Abschnitt mit konkreten Zahlen belegen. Die aktuelle stabile Version trägt laut der offiziellen Zed-Downloadseite die Nummer 1.18.0, veröffentlicht am 2. September 2026. Parallel dazu pflegt das Team einen Preview-Kanal, der nahezu täglich neue Builds ausliefert und in dem KI-Funktionen zuerst erprobt werden, bevor sie in den stabilen Kanal wandern.
Zed bewirbt sich selbst als Editor, der Zusammenarbeit zwischen Menschen und KI-Agenten im selben Fenster ermöglicht. Praktisch bedeutet das: Ein Entwickler kann per Multiplayer-Funktion mit Kollegen gemeinsam an einer Datei arbeiten und gleichzeitig einen KI-Agenten Änderungen vorschlagen lassen, ohne den Editor zu verlassen oder eine Browser-Oberfläche zu öffnen. Kernstück der KI-Funktionen ist ein hauseigenes Modell für Code-Vervollständigung namens Zeta, mittlerweile in der Version Zeta2.1, das direkt auf Zeds eigener Infrastruktur läuft und für niedrige Antwortzeiten optimiert ist. Für komplexere Aufgaben lassen sich zusätzlich externe Modelle von Anthropic, OpenAI und Google einbinden, entweder gehostet über Zed selbst oder per eigenem API-Schlüssel.
Wichtig für den Vergleich mit Continue.dev: Der Zed-Editor selbst ist komplett kostenlos und quelloffen, der Quellcode liegt auf GitHub unter zed-industries/zed. Bezahlt wird ausschließlich für die gehosteten KI-Funktionen, nicht für den Editor als solchen. Das ist ein anderes Modell als bei Cursor, wo der komplette KI-Workflow eng an das kommerzielle Produkt gebunden ist.
Die Entscheidung, den Editor komplett neu und nativ zu bauen, statt wie viele Wettbewerber auf Electron zu setzen, war von Beginn an eine strategische Wette auf Performance. Das Zed-Team argumentiert, dass gerade KI-Funktionen wie Agenten oder Live-Vervollständigung sehr viel mehr Ressourcen verbrauchen als klassisches Editieren, sodass ein schlanker Unterbau nötig wird, damit der Editor unter dieser zusätzlichen Last nicht insgesamt langsamer wirkt als eine reine Text-Bearbeitung. Diese Wette zahlt sich in den Benchmark-Zahlen im nächsten Abschnitt sichtbar aus.
Der Deal zwischen Anysphere und Continue.dev wurde nie mit einer großen Pressekonferenz angekündigt. Branchenbeobachter bezeichnen ihn übereinstimmend als “Acqui-Hire”: Anysphere übernahm im Wesentlichen das Team und die Technologie, ohne das Produkt als eigenständige Marke fortzuführen. Zum Zeitpunkt der Übernahme zählte das Repository continuedev/continue nach einer Star-History-Auswertung rund 34.400 GitHub-Stars, knapp 4.800 Forks und 507 Watcher, was das Projekt zu diesem Zeitpunkt auf Rang 872 der aktivsten Open-Source-Repositories brachte. Diese Zahl verdeutlicht, wie etabliert Continue in der Entwickler-Community war, bevor die Übernahme das Ende einläutete.
Für Cursor selbst ergibt der Schritt strategisch Sinn: Statt eine eigene BYOK-Architektur (“Bring your own key”) von Grund auf zu bauen, kaufte sich das Unternehmen Erfahrung und Personal aus einem Projekt, das genau dieses Problem seit Jahren gelöst hatte. Gleichzeitig verschwand mit Continue einer der sichtbarsten kostenlosen Konkurrenten im Copilot-Umfeld, was Anysphere indirekt auch dabei hilft, seine eigene kommerzielle Positionierung zu schärfen. Für die Continue-Community bedeutete der Deal das Gegenteil: Die Roadmap wurde eingestellt, keine neuen Features, keine Sicherheitsupdates, keine Reaktion mehr auf gemeldete Schwachstellen. Genau dieser Punkt macht eine veraltete Continue-Installation im September 2026 zu einem Risiko, das über reine Funktionsverluste hinausgeht.
Bemerkenswert ist außerdem, wie viele Migrationsleitfäden binnen weniger Wochen nach der Ankündigung online erschienen sind. Das zeigt, dass eine große Zahl von Continue-Nutzern nicht automatisch zu Cursor gewechselt ist, sondern aktiv nach Alternativen mit ähnlicher Offenheit gesucht hat. Genau diese Zielgruppe schaut sich aktuell Zed an, weil der Editor ebenfalls BYOK unterstützt, aber im Gegensatz zu Continue aktiv weiterentwickelt wird.
Technische Daten im Vergleich
Die folgende Tabelle stellt die wichtigsten technischen Eckdaten beider Werkzeuge gegenüber. Da Continue.dev seit Juni 2026 eingefroren ist, beziehen sich die entsprechenden Werte auf den letzten aktiven Stand vor der Übernahme.
| Kriterium | Zed | Continue.dev (eingefroren) |
|---|---|---|
| Architektur | Nativer Editor, geschrieben in Rust | Erweiterung für bestehende IDEs |
| Aktueller Stand | Version 1.18.0 (Stable, 2. September 2026) | Version 2.0.0-vscode (19. Juni 2026, letzte Version) |
| Entwicklungsstatus | Aktiv, mit täglichem Preview-Kanal | Eingestellt, Repository nur lesbar |
| Lizenz | Editor Open Source, KI-Layer proprietär gehostet | Apache 2.0, vollständig quelloffen |
| Unterstützte IDEs | Eigenständiger Editor | VS Code, JetBrains-IDEs, CLI |
| KI-Vervollständigung | Hauseigenes Modell Zeta2.1 | Abhängig vom gewählten externen Modell |
| BYOK (eigener API-Key) | Ja, für Claude, GPT und Gemini | Ja, Kernfunktion des Produkts |
| Lokale Modelle | Ja, über Ollama | Ja, über Ollama |
| Multiplayer / Pair-Programming | Ja, nativ im Editor integriert | Nein |
| GitHub-Repository | zed-industries/zed, aktiv gepflegt | continuedev/continue, ca. 34.400 Stars, nur lesbar |
| Cloud-/Team-Funktionen | Aktiv (Business-Tarif) | Abgeschaltet seit 15. Juli 2026 |
| Sicherheitsupdates | Laufend | Keine mehr seit Juni 2026 |
Der auffälligste Unterschied in dieser Tabelle ist nicht technischer, sondern struktureller Natur: Zed bekommt weiterhin Updates, Continue.dev nicht mehr. Für die Wahl des richtigen Werkzeugs ist das oft entscheidender als jedes einzelne Feature.
Erweiterbarkeit und Ökosystem: Plugins, Themes und Sprachunterstützung
Ein Editor lebt nicht nur von seinem Kern, sondern auch davon, wie leicht sich fehlende Funktionen nachrüsten lassen. Continue.dev hatte hier den strukturellen Vorteil, selbst eine Erweiterung für etablierte IDEs zu sein: Wer VS Code oder eine JetBrains-IDE nutzte, hatte automatisch Zugriff auf das riesige bestehende Plugin-Ökosystem dieser Editoren, Continue kam einfach als zusätzliches Werkzeug obendrauf. Debugger, Linter, Versionsverwaltung, Sprachserver für exotischere Programmiersprachen, all das musste nicht neu gebaut werden.
Zed geht einen anderen Weg und baut ein eigenes, jüngeres Erweiterungssystem auf, das eigene Extensions, Themes und Sprachserver-Integrationen über eine eigene Registry bereitstellt. Für weit verbreitete Sprachen wie JavaScript, TypeScript, Python, Rust oder Go ist die Abdeckung inzwischen solide, bei sehr spezialisierten oder unternehmensinternen Werkzeugen kann die Auswahl aber dünner ausfallen als im jahrelang gewachsenen VS-Code-Marktplatz. Wer stark auf einzelne, seltene VS-Code- oder JetBrains-Plugins angewiesen ist, etwa für eine firmeninterne Build-Pipeline oder ein Nischen-Framework, sollte vor dem Umstieg auf Zed konkret prüfen, ob ein Äquivalent existiert. Für die meisten Mainstream-Stacks im Web- und Backend-Bereich ist das nach aktuellem Stand kein Hindernis mehr, für sehr spezialisierte Enterprise-Umgebungen kann es das durchaus noch sein.
Performance-Benchmarks: Start, Arbeitsspeicher, Latenz
Weil Continue.dev als Erweiterung läuft und keine eigenständige Editor-Performance liefert, konzentrieren sich veröffentlichte Benchmarks auf den direkten Vergleich zwischen Zed und VS Code, dem Editor, in dem Continue typischerweise installiert wurde. Mehrere unabhängige Tests aus 2026 kommen dabei zu sehr ähnlichen Werten, was die Zahlen glaubwürdiger macht als eine Einzelmessung.
Der Techblog Markaicode maß auf einem MacBook Pro M2 mit 16 GB Arbeitsspeicher einen Kaltstart von 0,12 Sekunden für Zed, verglichen mit 1,2 Sekunden für VS Code, beim Öffnen mit einem bereits geladenen Projekt lagen die Werte bei 0,18 zu 2,1 Sekunden. Bei einer großen Codebasis mit über 10.000 Dateien wuchs der Abstand weiter: 0,25 Sekunden bei Zed gegenüber 3,8 Sekunden bei VS Code. Die Analyseplattform ByteIota kam bei einem separaten Test zu praktisch identischen Kaltstartzeiten (0,12 zu 1,2 Sekunden) und ergänzte Zahlen zum Arbeitsspeicher: Beim Öffnen eines Projektordners belegte Zed rund 222 MB RAM, VS Code dagegen 3.549 MB, also mehr als das Fünfzehnfache. Für die Reaktionszeit bei Eingaben nannte ByteIota 2 Millisekunden bei Zed gegenüber 25 Millisekunden bei VS Code.
Eine dritte Quelle, ein 2026er Testbericht von Tech-Insider, bestätigt die Größenordnung mit leicht abweichenden Werten: Ein “sauberer” Kaltstart ohne geöffnetes Projekt dauerte demnach 0,4 Sekunden bei Zed gegenüber 3 Sekunden bei VS Code, was einem Faktor von etwa 7,5 entspricht. Sobald KI-Funktionen aktiv liefen, stieg der Speicherbedarf von Zed auf 350 bis 450 MB, während VS Code mit aktivierter Copilot-Erweiterung die Marke von 1 GB überschritt. Ein vierter Bericht, veröffentlicht vom Portal Agmazon, bewegt sich mit 0,12 Sekunden für Zed gegenüber 1,2 Sekunden für VS Code exakt im selben Rahmen wie Markaicode und ByteIota und nennt zusätzlich einen Speicherbedarf von rund 200 MB für Zed gegenüber 1 bis 3 GB für VS Code, je nach installierten Erweiterungen.
Alle vier Quellen bestätigen damit unabhängig voneinander: Zed startet spürbar schneller und verbraucht deutlich weniger Arbeitsspeicher als VS Code, ein Vorteil, der sich besonders bei großen Monorepos und auf älterer Hardware bemerkbar macht, etwa auf gebrauchten Firmen-Notebooks, die in vielen österreichischen Betrieben noch mehrere Jahre im Einsatz bleiben. Für Cursor selbst liegen in den ausgewerteten Quellen keine vergleichbar detaillierten Zahlen vor, Tester beschreiben es aber unabhängig voneinander als spürbar ressourcenhungriger als Zed, da es ebenfalls auf einer Electron-Basis aufbaut. Für Continue.dev als reine Erweiterung gilt ohnehin: Die Editor-Performance hängt komplett vom Host ab, meist VS Code, weshalb ein direkter, eigenständiger Benchmark für Continue selbst wenig Aussagekraft hätte.
Preise und Lizenzmodelle im Vergleich
Beim Preis zeigt sich der größte praktische Unterschied zwischen einem aktiv gepflegten Produkt und einem eingefrorenen Projekt: Zed hat laut seiner offiziellen Preisseite ein aktuelles, mehrstufiges Preismodell, Continue.dev dagegen nur noch den Stand von vor der Übernahme.
| Tarif | Zed | Continue.dev (letzter aktiver Stand) |
|---|---|---|
| Kostenlose Stufe | 0 $/Monat, 2.000 akzeptierte Edit-Vorschläge, rund 50 gehostete KI-Anfragen | Kostenlos und quelloffen (Apache 2.0), unbegrenzt bei eigenem API-Key |
| Einzeltarif | Pro: 10 $/Nutzer/Monat, unbegrenzte Edit-Vorschläge, 5 $ KI-Guthaben inklusive | Kein separater bezahlter Einzeltarif dokumentiert |
| Team-/Unternehmenstarif | Business: 30 $/Sitz/Monat, zentrale Modellrichtlinien, RBAC | Gehostete Team-Funktionen, seit 15. Juli 2026 abgeschaltet |
| Zusätzliche KI-Nutzung | API-Listenpreis plus 10 % Aufschlag über Zed | Direkt beim gewählten Modellanbieter abgerechnet |
| Testphase | 14 Tage mit 20 $ Guthaben im Pro-Tarif | Nicht mehr verfügbar |
| Studierenden-Rabatt | Pro-Funktionen ein Jahr gratis mit Uni-E-Mail | Nicht zutreffend |
| Wiederkehrende Zahlungen | Laufend, aktiv abgerechnet | Automatisch deaktiviert bei der Übernahme |
Wer ausschließlich mit eigenem API-Schlüssel arbeitet und auf die gehosteten Zed-Funktionen verzichtet, kann den Editor faktisch kostenlos nutzen und zahlt nur die Kosten des jeweiligen Modellanbieters. Genau dieses Modell kannten viele Nutzer bereits von Continue.dev, was den Umstieg preislich neutral macht. Der Unterschied liegt eher darin, dass Zed für Teams ein klar definiertes, kostenpflichtiges Angebot mit Support und zentraler Verwaltung bereithält, während bei Continue diese Ebene komplett weggefallen ist.
Für ein kleines Team von fünf Entwicklern ergibt sich daraus eine überschaubare Rechnung: Der Pro-Tarif von Zed kostet bei fünf Lizenzen 50 US-Dollar pro Monat, inklusive 5 US-Dollar Startguthaben für gehostete KI-Anfragen pro Kopf. Wer stattdessen den Business-Tarif für zentrale Modellrichtlinien und Rechteverwaltung braucht, zahlt bei derselben Teamgröße 150 US-Dollar pro Monat. Beide Beträge liegen deutlich unter dem, was ein vergleichbares Team für ein vollwertiges Cursor-Abo mit ähnlichem Funktionsumfang einplanen müsste, auch wenn ein direkter Eins-zu-eins-Vergleich der Tarife wegen unterschiedlicher Kontingente nur begrenzt aussagekräftig ist.
KI-Funktionen im Detail: Zeta2, Agenten und BYOK
Der Kern von Zeds KI-Angebot ist die Kombination aus einem schnellen, hauseigenen Vorhersagemodell für kleine Änderungen und der Möglichkeit, für größere Aufgaben leistungsfähigere externe Modelle zuzuschalten. Das Modell Zeta2.1 übernimmt die klassische Autovervollständigung und Editier-Vorschläge direkt in der Zeile, in der gerade getippt wird, und läuft auf Zeds eigener Infrastruktur, was die niedrigen Latenzen aus dem vorherigen Abschnitt erklärt. Für komplexere Anfragen, etwa das Umschreiben einer ganzen Funktion oder das Erklären eines fremden Codeabschnitts, lassen sich Agenten einsetzen, die auf Modelle von Anthropic, OpenAI oder Google zugreifen. Diese Agenten können laut Zed direkt Dateien bearbeiten, im Projekt navigieren und Tools ausführen, mit Antwortzeiten, die sich an der Geschwindigkeit des nativen Editors orientieren und nicht an einer Browser-Oberfläche.
Für Entwickler, die aus dem Continue.dev-Umfeld kommen, dürfte vor allem die BYOK-Option relevant sein: Wer einen eigenen Anthropic-, OpenAI- oder Google-Schlüssel besitzt, kann diesen in Zed hinterlegen und zahlt dann nur den Preis des jeweiligen Anbieters, nicht den Aufschlag von Zed. Ergänzend unterstützt Zed auch lokale Modelle über Ollama, was für Teams mit strengen Datenschutzanforderungen wichtig ist, etwa im Finanzsektor oder im öffentlichen Bereich, wo Code das eigene Netzwerk aus regulatorischen Gründen nicht verlassen darf. Genau dieses Bedürfnis hatte Continue.dev über Jahre bedient, und Zed deckt es strukturell auf ähnliche Weise ab, wenn auch mit einem anderen Editor-Unterbau.
Ein vereinfachtes Beispiel, wie eine BYOK-Konfiguration in der Praxis aussehen kann, um ein eigenes Anthropic-Modell für Agenten-Aufgaben zu hinterlegen:
{
"language_models": {
"anthropic": {
"api_key": "IHR_EIGENER_API_KEY",
"default_model": "claude-sonnet"
}
},
"agent": {
"default_provider": "anthropic",
"allow_file_edits": true
}
}Die genaue Struktur der Konfigurationsdatei kann sich je nach Zed-Version unterscheiden, das Prinzip bleibt aber gleich: Ein eigener Schlüssel ersetzt die gehostete Abrechnung über Zed vollständig.
Datenschutz und DSGVO: Worauf Teams in Österreich achten müssen
Für Unternehmen in Österreich ist die Frage, wohin Quellcode und Prompts beim Einsatz eines KI-Editors fließen, keine Nebensache, sondern eine DSGVO-relevante Entscheidung. Sobald ein gehostetes Modell verwendet wird, etwa über Zeds eigene Infrastruktur oder direkt über die API eines Anbieters wie Anthropic, OpenAI oder Google, verlässt der bearbeitete Code technisch das eigene Netzwerk und wird bei einem Drittanbieter verarbeitet. Für viele Teams reicht das im Alltag völlig aus, für Unternehmen mit sensiblen Kundendaten im Code, etwa in der Finanzbranche, im Gesundheitswesen oder in der öffentlichen Verwaltung, ist das dagegen oft ein Ausschlusskriterium.
Sowohl Zed als auch Continue.dev lösen dieses Problem grundsätzlich gleich: über BYOK-Verträge mit dem jeweiligen Modellanbieter, bei denen die eigene Organisation die Datenschutzbedingungen direkt mit dem gewählten Anbieter aushandelt, oder über vollständig lokale Modelle mit Ollama, bei denen keine Daten das eigene Gerät oder Netzwerk verlassen. Der Unterschied liegt im Detail der Vertragsgestaltung: Bei Zeds gehosteten Tarifen läuft die Abrechnung über Zed selbst, das Unternehmen hat also mit Zed als zusätzlicher verarbeitender Stelle zu tun, zusätzlich zum eigentlichen Modellanbieter im Hintergrund. Bei reinem BYOK entfällt diese zusätzliche Stufe, der Vertrag besteht direkt zwischen dem eigenen Unternehmen und etwa Anthropic oder OpenAI. Wer in einer regulierten Branche arbeitet, sollte diesen Unterschied vor der Werkzeugwahl mit der eigenen Rechts- oder Compliance-Abteilung klären, unabhängig davon, ob am Ende Zed, eine Continue-Nachfolgelösung oder ein anderes Werkzeug zum Einsatz kommt.
Fünf Praxisbeispiele aus dem Entwickleralltag
Die Theorie hinter beiden Werkzeugen wird erst greifbar, wenn man sie an konkreten Arbeitssituationen misst. Die folgenden fünf Beispiele orientieren sich an typischen Szenarien, wie sie in Österreich und im gesamten DACH-Raum aktuell diskutiert werden.
- Freiberufliche Entwicklerin mit mehreren Kundenprojekten: Sie arbeitet an mehreren mittelgroßen Codebasen gleichzeitig und wechselt oft zwischen Projekten. Die kurzen Ladezeiten von Zed, gemessen mit 0,18 Sekunden bei einem bereits geladenen Projekt, sparen ihr über den Tag verteilt spürbar Wartezeit gegenüber VS Code.
- Fintech-Team in Wien mit Compliance-Vorgaben: Das Team durfte Code aus regulatorischen Gründen nie an fremde Cloud-Dienste senden und nutzte Continue.dev ausschließlich mit lokalen Ollama-Modellen. Nach der Abschaltung der Cloud-Dienste im Juli 2026 musste das Team eine Alternative mit gleichwertiger lokaler Modellunterstützung finden, Zed mit BYOK und Ollama-Anbindung war die naheliegende Wahl.
- Remote-Pair-Programming zwischen zwei Standorten: Ein Backend-Team mit Mitgliedern in Graz und Berlin nutzt die native Multiplayer-Funktion von Zed, um gemeinsam an derselben Datei zu arbeiten, während ein Agent parallel Testfälle vorschlägt. Diese Kombination aus menschlicher und KI-gestützter Zusammenarbeit im selben Fenster war mit einer reinen VS-Code-Erweiterung wie Continue nicht in dieser Form möglich.
- Wartung eines großen Legacy-Monorepos: Ein Industriebetrieb mit einer über 10.000 Dateien umfassenden Codebasis berichtete von Ladezeiten unter VS Code, die den Arbeitsfluss spürbar bremsten. Die gemessenen 3,8 Sekunden Ladezeit bei VS Code gegenüber 0,25 Sekunden bei Zed für dieselbe Projektgröße machen bei mehrfachem täglichem Neustart einen messbaren Unterschied.
- Studierender an einer österreichischen Fachhochschule: Mit begrenztem Budget nutzte er zuvor die kostenlose Continue.dev-Erweiterung mit einem geförderten API-Kontingent. Nach dem Ende des Projekts wechselte er zu Zeds Studierenden-Tarif, der die Pro-Funktionen für ein Jahr kostenlos freischaltet, sofern eine gültige Universitäts-E-Mail-Adresse vorliegt.
Für wen eignet sich was? Sechs Empfehlungen
Nicht jede Empfehlung lautet automatisch “Zed”. Je nach Ausgangslage kann auch ein anderer Weg sinnvoller sein, vor allem wenn ein Team stark an eine bestehende IDE gebunden ist.
- Solo-Entwickler mit eigenem API-Schlüssel: Zeds kostenlose Stufe mit BYOK deckt den Bedarf ab, ohne dass ein Abo nötig wird.
- Teams mit Pair-Programming-Kultur: Der native Multiplayer-Modus von Zed bringt hier einen echten Mehrwert gegenüber reinen Erweiterungen.
- Unternehmen mit strengen Datenschutzvorgaben: Lokale Modelle über Ollama, kombiniert mit BYOK, halten sensible Daten im eigenen Netzwerk, egal ob in Zed oder in einer weiterhin gepflegten VS-Code-Erweiterung.
- Wer unbedingt bei VS Code oder JetBrains bleiben will: Für diese Gruppe ist ein Umstieg auf eine andere, weiterhin gepflegte Erweiterung sinnvoller als ein kompletter Editorwechsel, dazu mehr im Abschnitt zu Alternativen.
- Große, performance-kritische Monorepos: Die gemessenen Start- und Ladezeiten sprechen hier klar für Zed.
- Studierende und Einsteiger mit knappem Budget: Der kostenlose Kern von Zed plus Studierenden-Rabatt bietet einen niedrigschwelligen Einstieg in KI-gestütztes Programmieren.
Migrationsleitfaden: Der Umstieg von Continue.dev
Wer noch eine Continue.dev-Installation im Einsatz hat, sollte den Umstieg nicht auf die lange Bank schieben, da die Version 2.0.0 keine weiteren Sicherheitsupdates mehr erhält. Die folgenden Schritte haben sich in der Praxis bewährt.
- Bestandsaufnahme der aktuellen Konfiguration: Welche Modelle, System-Prompts, benutzerdefinierten Befehle und Regeln sind in der bestehenden Continue-Konfiguration hinterlegt? Diese Angaben liegen meist in lokalen Konfigurationsdateien und sollten vor jedem weiteren Schritt gesichert werden.
- Entscheidung für einen Nachfolger treffen: Wer den Editor wechseln kann, prüft Zed. Wer zwingend in VS Code oder JetBrains bleiben muss, prüft stattdessen eine weiterhin aktiv gepflegte Erweiterung wie Cline.
- Bei der Wahl von Zed: Editor installieren, vorhandene API-Schlüssel für Anthropic, OpenAI oder Google in den KI-Einstellungen hinterlegen und die kostenlose Stufe zunächst im Alltag testen, bevor ein bezahlter Tarif nötig wird.
- System-Prompts und Regeln manuell nachbauen: Da es keinen automatischen Importer von Continue zu Zed gibt, müssen benutzerdefinierte Prompts und Coding-Richtlinien von Hand übertragen werden.
- Lokale Modelle weiterverwenden: Bestehende Ollama-Installationen lassen sich unverändert weiterbetreiben und sowohl in Zed als auch in alternativen Erweiterungen einbinden, sodass Compliance-Anforderungen erhalten bleiben.
- Team-Rollout planen: Für größere Teams lohnt sich der Business-Tarif von Zed mit zentralen Modellrichtlinien, statt jede Konfiguration einzeln auf den Rechnern der Mitarbeiter zu pflegen.
- Alte Continue-Installation dokumentieren und absichern: Falls eine alte Version aus Kompatibilitätsgründen weiterläuft, sollte sie klar als unsicher markiert und möglichst vom Netzwerk mit sensiblen Daten getrennt werden, da keine Patches mehr erscheinen.
Der größte Fehler in der Praxis ist, den Umstieg wegen laufender Projekte immer wieder zu verschieben. Da Continue.dev seit Juli 2026 auch keine Cloud-Wiederherstellung mehr anbietet, wächst mit jeder Woche ohne Migration das Risiko, im Ernstfall keine funktionierende Konfiguration mehr zur Hand zu haben.
Sicherheitsrisiko: Warum eine eingefrorene Erweiterung gefährlich wird
Aus Sicherheitssicht unterscheidet sich eine eingestellte Entwicklerwerkzeug-Erweiterung nicht grundsätzlich von jeder anderen Software, die keine Patches mehr erhält: Bekannt gewordene Schwachstellen in Abhängigkeiten bleiben offen, weil niemand mehr ein Update veröffentlicht. Bei einer Erweiterung, die direkt mit API-Schlüsseln für Cloud-Modelle sowie mit dem gesamten Quellcode eines Projekts arbeitet, wiegt das besonders schwer. Ein kompromittiertes Paket in der Abhängigkeitskette könnte im schlimmsten Fall genau die Zugangsdaten abgreifen, mit denen ein Unternehmen seine KI-Nutzung abrechnet, oder unbemerkt Code aus einem privaten Repository exfiltrieren.
Bei Continue.dev kommt erschwerend hinzu, dass mit dem Wechsel des Repositorys auf Nur-Lese-Modus auch die übliche Reaktionskette bei gemeldeten Schwachstellen wegfällt. Niemand triagiert neue Issues, niemand veröffentlicht einen Sicherheitshinweis, niemand schnürt einen Patch-Release. Für ein einzelnes Hobbyprojekt mag das verschmerzbar sein, für den Einsatz in einem Unternehmensnetzwerk mit Zugriff auf produktiven Code ist eine solche Software-Lieferkette ohne Wartung ein Zustand, den IT-Sicherheitsverantwortliche in Österreich im Rahmen ihrer ohnehin bestehenden Pflichten zur laufenden Risikobewertung eigentlich nicht dulden sollten. Ein aktiv gepflegtes Werkzeug wie Zed oder eine ebenfalls aktiv gepflegte Alternative wie Cline schließt diese Lücke automatisch, weil regelmäßige Updates und eine funktionierende Meldestelle für Schwachstellen Teil des laufenden Betriebs sind.
Vor- und Nachteile im direkten Vergleich
| Werkzeug | Vorteile | Nachteile |
|---|---|---|
| Zed | Sehr kurze Start- und Ladezeiten, geringer Arbeitsspeicherverbrauch, aktive Weiterentwicklung, BYOK und lokale Modelle, native Multiplayer-Funktion, kostenloser Kern | Eigenständiger Editor statt Erweiterung, daher kein Umstieg innerhalb von VS Code oder JetBrains möglich; jüngeres KI-Ökosystem als bei Copilot oder Cursor |
| Continue.dev (eingefroren) | Vollständig quelloffen unter Apache 2.0, maximale Modellflexibilität, lief direkt in vertrauter IDE-Umgebung | Keine Updates oder Sicherheitspatches mehr seit Juni 2026, Cloud-Dienste abgeschaltet seit 15. Juli 2026, Repository nur noch lesbar, keine Zukunftssicherheit |
Diese Gegenüberstellung macht deutlich, dass ein direkter Feature-Vergleich allein nicht ausreicht. Continue.dev war zu seiner aktiven Zeit technisch keineswegs unterlegen, der entscheidende Nachteil ist heute die fehlende Zukunft des Projekts.
Alternativen für ehemalige Continue.dev-Nutzer
Nicht jeder ehemalige Continue-Nutzer will oder kann den Editor wechseln. Für alle, die in VS Code oder JetBrains bleiben möchten, gibt es zwei naheliegende Wege. Migrationsleitfäden, die kurz nach der Übernahme veröffentlicht wurden, empfehlen für Nutzer, die weiterhin mit eigenem API-Schlüssel oder lokalen Modellen arbeiten wollen, den Wechsel zu Cline, einer aktiv gepflegten Open-Source-Erweiterung mit einem sehr ähnlichen BYOK-Ansatz wie Continue. Cline lässt sich als direkter Ersatz innerhalb von VS Code installieren, ohne dass Entwickler ihre gewohnte Umgebung verlassen müssen.
Für Nutzer, denen die reine Funktionsvielfalt wichtiger ist als die Kosten, gilt laut denselben Leitfäden Cursor selbst als naheliegende Option, schließlich ist es das Unternehmen, das Continue ursprünglich übernommen hat. Wer stattdessen eine dritte Option ohne direkte Cursor-Verbindung sucht und bereit ist, den Editor zu wechseln, landet fast zwangsläufig bei Zed, da es als einziges der genannten Werkzeuge sowohl BYOK als auch native Performance-Vorteile mitbringt. Der quelloffene Code von Continue.dev selbst bleibt unter Apache-2.0-Lizenz öffentlich einsehbar und theoretisch forkbar, konkrete, breit genutzte Community-Forks mit eigenständiger Weiterentwicklung sind zum jetzigen Zeitpunkt aber noch nicht in nennenswertem Umfang etabliert.
Cline selbst positioniert sich als Erweiterung, die möglichst nah am ursprünglichen Continue-Ansatz bleibt: freie Modellwahl, Ausführung direkt in VS Code, und eine aktive Weiterentwicklung durch ein eigenes Team statt einer stillen Übernahme. Für Teams, die primär wegen der IDE-Integration und weniger wegen des konkreten Editors bei Continue geblieben waren, ist das der Weg mit dem geringsten Umstellungsaufwand: Die gewohnte Tastenkombinationen, das Look-and-Feel von VS Code und ein Großteil der bekannten Workflows bleiben erhalten, nur die zugrunde liegende Erweiterung wird ausgetauscht.
Das Urteil: Zed vs. Continue.dev im Fazit
Ein fairer Vergleich muss zwei Ebenen trennen: die technische und die strategische. Auf der technischen Ebene punktet Zed mit Zahlen, die sich über mehrere unabhängige Quellen hinweg bestätigen: Kaltstartzeiten von 0,12 bis 0,4 Sekunden gegenüber 1,2 bis 3 Sekunden bei VS Code, ein Arbeitsspeicherbedarf von rund 222 MB gegenüber 3.549 MB, und eine Eingabelatenz von 2 statt 25 Millisekunden. Das sind keine Marketingzahlen eines einzelnen Herstellers, sondern Werte aus mindestens drei unterschiedlichen Testberichten (Markaicode, ByteIota, Tech-Insider), die sich gegenseitig stützen.
Auf der strategischen Ebene ist der Fall noch klarer: Continue.dev ist kein aktives Produkt mehr. Seit der Übernahme durch Anysphere im Juni 2026, dem letzten Release am 19. Juni und der Abschaltung der Cloud-Dienste am 15. Juli 2026 gibt es keinen Grund mehr, neue Projekte auf Continue aufzubauen. Für bestehende Installationen tickt die Uhr, jede Woche ohne Sicherheitsupdate erhöht das Risiko ungepatchter Schwachstellen. Zed bietet mit seinem aktiven Preview-Kanal, dem laufenden Pricing-Modell und der nativen Multiplayer-Funktion die konsequentere Wahl für alle, die BYOK und lokale Modelle weiterhin nutzen wollen, aber ein Werkzeug mit Zukunft brauchen. Wer zwingend in VS Code oder JetBrains bleiben muss, sollte stattdessen auf Cline oder direkt auf Cursor ausweichen. Ein Grund, aktiv bei einer eingefrorenen Continue-Installation zu bleiben, lässt sich aus den vorliegenden Daten nicht mehr ableiten.
Kurz zusammengefasst für die Entscheidung im Alltag: Wer den Editor wechseln kann und Wert auf Geschwindigkeit sowie eine aktiv gepflegte KI-Schicht legt, sollte Zed direkt testen, die kostenlose Stufe reicht dafür meist völlig aus. Wer aus organisatorischen Gründen in VS Code oder JetBrains bleiben muss, sollte den Umstieg auf Cline priorisieren, bevor die eigene, veraltete Continue-Installation zum Sicherheitsproblem wird. Und wer ohnehin plant, in den kommenden Monaten auf ein umfassenderes, kommerzielles Werkzeug umzusteigen, kann diesen Schritt auch gleich mit einem Wechsel zu Cursor verbinden. In allen drei Fällen gilt: Abwarten ist die einzige Option, die mit Sicherheit keine Verbesserung bringt.
Häufig gestellte Fragen
Ist Continue.dev komplett tot oder funktioniert die Erweiterung noch?
Die lokal installierte Erweiterung in Version 2.0.0 läuft technisch weiter, solange eigene API-Schlüssel gültig bleiben. Die gehosteten Cloud-Dienste wurden jedoch am 15. Juli 2026 abgeschaltet, gespeicherte Daten wurden gelöscht, und es erscheinen keine Updates oder Sicherheitspatches mehr.
Ist Zed komplett kostenlos?
Der Editor selbst ist kostenlos und quelloffen. Die kostenlose Stufe umfasst zusätzlich 2.000 akzeptierte Edit-Vorschläge und rund 50 gehostete KI-Anfragen pro Monat. Wer mehr braucht oder unbegrenzte Vorschläge will, zahlt für den Pro-Tarif 10 US-Dollar pro Nutzer und Monat.
Kann ich mit Zed weiterhin mein eigenes Claude- oder GPT-Konto nutzen?
Ja. Zed unterstützt Bring-your-own-Key für Anthropic, OpenAI und Google. In diesem Fall zahlen Nutzer nur die Kosten des jeweiligen Modellanbieters direkt, ohne Aufschlag durch Zed.
Was ist die beste Alternative, wenn ich in VS Code bleiben will?
Für Nutzer, die auf eigene API-Schlüssel oder lokale Modelle setzen, gilt Cline als naheliegender, aktiv gepflegter Ersatz innerhalb von VS Code. Wer stattdessen ein umfassenderes, kommerzielles Werkzeug sucht, kann zu Cursor wechseln.
Unterstützt Zed auch Windows und Linux?
Zed bietet Downloads für mehrere Desktop-Plattformen an. Die ausführlichsten, unabhängig gemessenen Performance-Daten beziehen sich auf macOS-Systeme, aktuelle Angaben zum jeweiligen Plattformstatus finden sich direkt auf der offiziellen Zed-Downloadseite.
Warum hat Cursor Continue.dev überhaupt übernommen?
Nach Einschätzung mehrerer Branchenanalysen ging es Anysphere, dem Unternehmen hinter Cursor, vor allem um Team und Technologie rund um die BYOK-Architektur von Continue, nicht um die Fortführung der Marke als eigenständiges Produkt. Gleichzeitig verschwand damit einer der bekanntesten kostenlosen Open-Source-Konkurrenten im Copilot-Umfeld.
Lohnt sich der Umstieg auf Zed auch für kleine Einzelprojekte?
Ja, gerade weil die kostenlose Stufe von Zed keinen Vertrag oder Team-Setup voraussetzt. Für Einzelentwickler mit eigenem API-Schlüssel ist der Umstieg in der Regel innerhalb weniger Minuten erledigt, ohne dass laufende Kosten über den jeweiligen Modellanbieter hinaus entstehen.
Was passiert mit dem Quellcode von Continue.dev langfristig?
Der Code bleibt unter der Apache-2.0-Lizenz öffentlich auf GitHub verfügbar und ist theoretisch forkbar. Das offizielle Repository selbst nimmt aber keine neuen Beiträge mehr an, jede Weiterentwicklung müsste über einen unabhängigen Fork der Community erfolgen.
Ist die Umstellung von Continue.dev auf Zed DSGVO-konform möglich?
Das hängt von der gewählten Konfiguration ab. Mit BYOK oder rein lokalen Ollama-Modellen lässt sich ein ähnliches Datenschutzniveau wie bei Continue.dev erreichen. Bei gehosteten Zed-Tarifen kommt Zed als zusätzliche verarbeitende Stelle hinzu, was vor dem Einsatz mit der eigenen Rechts- oder Compliance-Abteilung abgeklärt werden sollte.
Wie lange dauert eine typische Migration von Continue.dev zu Zed?
Für Einzelentwickler mit einer einfachen BYOK-Konfiguration ist der technische Umstieg meist innerhalb weniger Minuten erledigt. Bei Teams mit umfangreichen, individuell angepassten System-Prompts und zentralen Regeln kann die vollständige Migration inklusive Tests und Team-Rollout mehrere Arbeitstage in Anspruch nehmen, da es keinen automatischen Importer gibt.