Zed Editor einrichten: 12 Schritte, 40 Minuten [2026]

Ein Editor, der Ihre Bearbeitungen vorschlägt, bevor Sie fertig getippt haben. Ein Agent, der eine Datei liest, einen Bug findet und den Fix als Diff präsentiert, den Sie annehmen oder ablehnen. Ein zweiter Entwickler, der live im selben Projekt mitarbeitet, während im Hintergrund ein lokales KI-Modell auf der eigenen GPU läuft, ganz ohne dass ein Byte Code das eigene Netzwerk verlässt. Genau das verspricht Zed, der in Rust geschriebene, GPU-beschleunigte Editor von Zed Industries, und im September 2026 ist die Kombination aus Geschwindigkeit, Agenten-Workflows und lokalen Modellen reif genug für den produktiven Alltag.

Diese Anleitung zeigt Ihnen in 12 Schritten, wie Sie Zed auf macOS, Linux oder Windows installieren, das Agent Panel mit einem Anthropic-Key oder einem lokalen Ollama-Modell verbinden, einen MCP-Server anbinden und am Ende ein komplettes Mini-Projekt mit KI-Unterstützung umsetzen. Rechnen Sie mit rund 40 Minuten für das Basis-Setup, etwas mehr, wenn Sie zusätzlich lokale Modelle testen. Am Ende steht außerdem eine Liste der häufigsten Stolperfallen und eine Tabelle mit Lösungen für die typischen Fehlermeldungen.

Für Leserinnen und Leser in Österreich ist vor allem ein Punkt interessant: Zed lässt sich vollständig mit selbst gehosteten oder lokalen Modellen betreiben, ohne dass Code an einen US-Anbieter geschickt werden muss. Wer aus Datenschutzgründen bisher gezögert hat, GitHub Copilot oder Cursor produktiv einzusetzen, bekommt mit Zed eine Alternative, die diese Kontrolle als Kernfeature und nicht als Nischenoption anbietet.

Diese Anleitung unterscheidet sich bewusst von einem reinen Benchmark-Vergleich. Statt Zed nur gegen andere Editoren abzuwägen, bekommen Sie hier eine praktische Schritt-für-Schritt-Anleitung, die Sie direkt am eigenen Rechner nachvollziehen können, inklusive der Fehler, über die andere Anwenderinnen und Anwender in Foren und Issue-Trackern am häufigsten stolpern. Wenn Sie bereits einen anderen KI-Editor nutzen, etwa Cursor oder VS Code mit GitHub Copilot, lohnt sich der Umstieg vor allem dann, wenn Ihnen Kontrolle über die Modellwahl, native Multiplayer-Funktionen oder schlicht spürbar kürzere Ladezeiten beim Öffnen großer Projekte wichtig sind. Die einzelnen Schritte bauen aufeinander auf, lassen sich aber auch unabhängig voneinander nachschlagen, falls Sie Zed bereits installiert haben und nur einen bestimmten Teil wie die MCP-Anbindung oder die lokale Modellkonfiguration nachholen wollen.

Voraussetzungen: Versionen, Konten und Systemanforderungen

Bevor Sie loslegen, sammeln Sie ein paar Dinge, damit Sie später nicht zwischendurch unterbrechen müssen. Zed selbst ist kostenlos und quelloffen, für die KI-Funktionen brauchen Sie aber je nach gewähltem Weg zusätzlich einen API-Schlüssel oder eine lokale Modell-Runtime.

Ein Rechner mit macOS, Linux oder Windows, jeweils mit einer aktuellen, unterstützten Version des Betriebssystems
Für die Installation per Homebrew auf macOS: eine funktionierende Homebrew-Installation
Für Windows: winget (in aktuellen Windows-10/11-Installationen standardmäßig enthalten)
Ein GitHub- oder E-Mail-Konto zur Anmeldung bei Zed (für Synchronisierung und den Zugriff auf gehostete Modelle)
Optional, aber empfohlen für Schritt 4: ein Anthropic-API-Key aus der Anthropic-Konsole, wenn Sie Claude direkt per BYOK (“Bring your own Key”) nutzen wollen
Optional für Schritt 5: Ollama (aktuelle Version von ollama.com) für lokale Modelle ohne Cloud-Anbindung
Etwa 40 Minuten Zeit für das Basis-Setup, mehr für den lokalen Modell-Teil

Ein Hinweis zur aktuellen Version: Zed folgt einem sehr kurzen Release-Rhythmus mit praktisch wöchentlichen Punkt-Updates. Auf der offiziellen Release-Seite stand Mitte September 2026 die Version 1.20.2 als aktueller Stand. Prüfen Sie beim eigenen Setup kurz, welche Version gerade aktuell ist, statt sich starr an eine Versionsnummer zu klammern, denn neue Punktversionen erscheinen laufend.

Zur Hardware selbst nennt Zed in der öffentlichen Dokumentation keine festen Mindestwerte für Arbeitsspeicher oder Grafikkarte, da der Editor auch auf älteren Rechnern grundsätzlich lauffähig ist. In der Praxis profitieren vor allem zwei Szenarien von zusätzlicher Leistung: sehr große Monorepos mit mehreren hunderttausend Dateien, bei denen mehr Arbeitsspeicher die Indizierung beschleunigt, und der Einsatz lokaler Modelle über Ollama oder llama.cpp, wo eine dedizierte GPU mit ausreichend Videospeicher den größten Unterschied macht. Für den reinen Editor-Betrieb ohne lokale Modelle reicht praktisch jeder Rechner der letzten fünf bis sechs Jahre, egal ob mit integrierter oder dedizierter Grafikeinheit.

Schritt 1: Zed installieren (macOS, Linux, Windows)

Zed bietet für jedes Betriebssystem einen eigenen, dokumentierten Installationsweg. Auf macOS ist Homebrew der schnellste Weg, auf Linux nutzen Sie ein Tarball-Archiv, auf Windows winget oder den grafischen Installer. Öffnen Sie ein Terminal und wählen Sie den passenden Befehl für Ihr System.

macOS, per Homebrew (empfohlen) oder per Installationsskript:

# Variante A: Homebrew, stabiler Kanal
brew install --cask zed

# Variante B: Installationsskript direkt von zed.dev
curl -f https://zed.dev/install.sh | sh

Linux, über das Tarball-Archiv von der Download-Seite:

mkdir -p ~/.local
tar -xvf zed-linux-x86_64.tar.gz -C ~/.local
ln -sf ~/.local/zed.app/bin/zed ~/.local/bin/zed

Windows, per winget aus einer PowerShell mit Administratorrechten:

winget install -e --id ZedIndustries.Zed

Alternativ laden Sie auf allen drei Plattformen das passende Paket direkt von der offiziellen Download-Seite herunter, wenn Sie lieber grafisch installieren. Prüfen Sie unter Linux zusätzlich, ob Ihr System eine aktuelle GPU-Treiberversion mit funktionierendem OpenGL- oder Vulkan-Support besitzt, da Zed für sein Rendering GPU-Beschleunigung voraussetzt. Bei älteren integrierten Grafikchips oder fehlenden Treibern kann es sonst zu Rucklern oder einem komplett schwarzen Fenster kommen, dazu später mehr im Troubleshooting-Teil.

Nach der Installation lohnt sich ein kurzer Funktionstest über das Terminal, bevor Sie mit der eigentlichen Konfiguration beginnen. Die Zed-CLI wird bei allen drei Installationswegen automatisch mitinstalliert und lässt sich direkt aus einem beliebigen Projektordner heraus aufrufen, um Zed mit dem aktuellen Verzeichnis als Arbeitsbereich zu starten.

zed --version
zed .

Gibt der erste Befehl eine Versionsnummer zurück, war die Installation erfolgreich. Der zweite Befehl öffnet Zed direkt im aktuellen Ordner, was sich in der Praxis als schnellerer Einstieg erweist als der Umweg über den Willkommensbildschirm. Windows-Nutzerinnen und -Nutzer sollten nach der winget-Installation ein neues PowerShell-Fenster öffnen, damit die aktualisierte PATH-Variable geladen wird, sonst meldet das System den Befehl zed zunächst als unbekannt.

Schritt 2: Erstes Projekt öffnen und die Oberfläche verstehen

Starten Sie Zed und öffnen Sie über den Willkommensbildschirm oder die Tastenkombination einen Projektordner. Unter macOS ist das Cmd+O, unter Linux und Windows Ctrl+O. Wählen Sie ein bestehendes Repository oder legen Sie einen neuen leeren Ordner an, den Sie für das Praxisbeispiel in Schritt 12 wiederverwenden.

Die Oberfläche gliedert sich in einen zentralen Editorbereich mit Multi-Buffer-Unterstützung (mehrere Codestellen gleichzeitig in einer Ansicht), eine Seitenleiste links für die Projektstruktur und eine rechte Seitenleiste, in der später das Agent Panel erscheint. Machen Sie sich in diesem Schritt vor allem mit der Command Palette vertraut, dem zentralen Einstiegspunkt für praktisch jede Funktion in Zed. Öffnen Sie sie mit Cmd+Shift+P auf macOS oder Ctrl+Shift+P auf Linux und Windows, und tippen Sie einfach den Namen dessen, was Sie suchen, etwa “theme” für die Farbschema-Auswahl oder “agent” für alles rund um KI-Funktionen.

Wer von VS Code oder einem JetBrains-Produkt umsteigt, wird die Multiplayer-Kollaboration als ungewohntestes Element empfinden: Zed ist von Grund auf für gemeinsames Arbeiten in Echtzeit gebaut, nicht als nachträglich aufgesetztes Plugin. Dazu mehr in Schritt 9.

Ein weiterer Unterschied fällt sofort auf: Zed öffnet Projekte spürbar schneller als klassische Electron-basierte Editoren, da die gesamte Anwendung nativ in Rust läuft und für das Rendering direkt auf die GPU zugreift statt über eine eingebettete Browser-Engine. Bei großen Repositories mit tausenden Dateien zeigt sich das vor allem beim ersten Öffnen und bei der Fuzzy-Suche über die Command Palette, die auch in umfangreichen Projekten ohne spürbare Verzögerung reagiert. Nutzen Sie in dieser frühen Phase ruhig etwas Zeit, um verschiedene Farbschemata über die Theme-Auswahl durchzuprobieren und die Schriftgröße über den Parameter buffer_font_size an Ihren Bildschirm anzupassen, das zahlt sich über Stunden täglicher Nutzung spürbar aus.

Schritt 3: Erweiterungen über den Marktplatz installieren

Sprachserver, Themes und Zusatzfunktionen kommen in Zed als Erweiterungen, die Sie direkt über die Command Palette verwalten. Öffnen Sie die Palette und suchen Sie nach “extensions”, um die Erweiterungsliste zu öffnen. Von dort aus durchsuchen Sie den Marktplatz, installieren eine Erweiterung mit einem Klick und aktivieren sie sofort, ohne den Editor neu starten zu müssen.

Für die meisten gängigen Sprachen wie Python, Go, Rust oder TypeScript ist die Sprachunterstützung bereits im Kern enthalten und benötigt keine zusätzliche Erweiterung. Erweiterungen lohnen sich vor allem für zusätzliche Themes, Nischen-Sprachen, Snippet-Sammlungen oder spezielle Linter-Integrationen. Da Erweiterungen über das Netzwerk geladen werden, schlägt die Installation ohne Internetverbindung fehl. Wenn Sie hinter einem restriktiven Firmenproxy arbeiten, prüfen Sie vorab, ob dieser den Zugriff auf den Zed-Erweiterungsserver zulässt, sonst bricht die Installation mit einem Verbindungsfehler ab.

Deaktivieren oder deinstallieren Sie Erweiterungen wieder über dieselbe Liste, wenn Sie sie nicht mehr brauchen. Jede aktive Erweiterung mit eigenem Sprachserver startet einen zusätzlichen Hintergrundprozess, was bei sehr vielen gleichzeitig aktiven Erweiterungen den Arbeitsspeicherverbrauch spürbar erhöhen kann. Für ein schlankes, schnelles Setup reicht es in der Regel, nur die Sprachen zu installieren, mit denen Sie tatsächlich regelmäßig arbeiten, statt vorsorglich alles zu aktivieren, was der Marktplatz anbietet.

Schritt 4: Agent Panel aktivieren und Anthropic-Key hinterlegen

Das Agent Panel ist die zentrale Schnittstelle für alle KI-gestützten Aufgaben in Zed, von einfachen Fragen bis zu mehrstufigen Änderungen über mehrere Dateien hinweg. Öffnen Sie es über die rechte Seitenleiste oder per Command Palette mit der Suche nach “agent panel”. Beim ersten Öffnen fragt Zed, welches Modell für den Zed Agent oder einen externen Agenten konfiguriert werden soll.

Für den direkten Zugriff auf Claude-Modelle ohne Umweg über Zeds eigene, kostenpflichtige Hosting-Option nutzen Sie BYOK, also Ihren eigenen Anthropic-API-Key:

Öffnen Sie im Agent Panel die Einstellungen (Zahnrad-Symbol oder Menü oben rechts im Panel)
Wählen Sie im Bereich für API-Zugriff den Anbieter Anthropic aus
Fügen Sie Ihren Anthropic-API-Key aus der Anthropic-Konsole ein
Bestätigen Sie, damit Zed den Schlüssel im sicheren Schlüsselbund Ihres Betriebssystems speichert, nicht in einer Klartext-Konfigurationsdatei
Wählen Sie anschließend im Modell-Dropdown ein aktuelles Claude-Modell für den Agent aus

Zed unterstützt neben Anthropic direkt rund ein Dutzend weitere Anbieter über dasselbe Prinzip, darunter OpenRouter und andere API-Provider. Wichtig für die tägliche Nutzung: Zed behandelt KI-Änderungen bewusst wie einen Pull Request. Der Agent schlägt einen Patch vor, Zed zeigt den Diff an, und Sie entscheiden pro Datei, ob Sie die Änderung annehmen oder verwerfen. Das ist ein deutlicher Unterschied zu Tools, die Code automatisch und ohne Rückfrage überschreiben.

Die Provider-Schlüssel selbst landen dabei laut Zed-Dokumentation nicht in der settings.json im Klartext, sondern im systemeigenen Schlüsselbund, unter macOS also im Schlüsselbund-Zugriff, unter Windows im Credential Manager und unter Linux je nach Distribution im Secret Service. Das ist besonders relevant, wenn Sie settings.json wie in Schritt 8 beschrieben im Repository versionieren wollen: Der eigentliche API-Key taucht dort nicht auf, nur die Angabe, welcher Provider verwendet wird. Wer den Key dennoch einmal zurücksetzen möchte, findet die Option dafür an derselben Stelle im Agent Panel, an der er ursprünglich eingetragen wurde, ein manuelles Löschen der Konfigurationsdatei ist dafür nicht nötig.

Schritt 5: Ollama für lokale, private Modelle verbinden

Wenn Code oder Projektdaten das eigene Netzwerk aus Datenschutz- oder Compliance-Gründen nicht verlassen dürfen, ist ein lokales Modell die richtige Wahl. Zed unterstützt laut eigener Dokumentation ausdrücklich “Ollama, LM Studio, lokale OpenAI-kompatible Server oder selbst gehostete Modelle” als Alternative zu Cloud-Anbietern. Für Ollama sehen die Setup-Schritte laut der offiziellen Zed-Dokumentation so aus:

# 1. Ollama installieren (siehe ollama.com/download)
# 2. Ein Modell herunterladen
ollama pull mistral

# 3. Sicherstellen, dass der Ollama-Server läuft
ollama serve

Wechseln Sie danach in Zed zurück ins Agent Panel oder in die Modellauswahl und wählen Sie das gerade heruntergeladene Ollama-Modell aus dem Dropdown. Zed erkennt einen lokal laufenden Ollama-Server automatisch über dessen Standard-Port und listet die verfügbaren Modelle direkt auf. Für schwächere Laptops eignen sich kleinere Modelle wie ein 7B-Modell besser als große 70B-Varianten, da lokale Inferenz ohne dedizierte GPU spürbar langsamer ist als ein Cloud-Modell.

Als Alternative zu Ollama unterstützt Zed auch llama.cpp im sogenannten Router-Modus. Die Zed-Dokumentation beschreibt den Ablauf als: llama.cpp installieren, den Server im Router-Modus starten und anschließend das Modell aus demselben Dropdown in Zed auswählen wie bei Ollama. Für die meisten Einsteiger ist Ollama wegen der einfacheren Modellverwaltung per pull-Befehl der bequemere Startpunkt, llama.cpp lohnt sich eher, wenn Sie ohnehin schon damit arbeiten oder mehr Kontrolle über Quantisierung und Performance-Parameter brauchen.

Bei der Modellwahl lohnt sich etwas Experimentieren, da Geschwindigkeit und Codequalität stark vom eingesetzten Modell abhängen. Ein 7B- oder 8B-Modell eignet sich gut für einfache Vervollständigungen und kurze Refactoring-Aufgaben, liefert bei komplexeren, mehrstufigen Anfragen im Agent Panel aber spürbar schwächere Ergebnisse als ein gehostetes Frontier-Modell. Für anspruchsvollere lokale Aufgaben lohnt sich ein größeres, speziell auf Code trainiertes Modell, sofern die eigene GPU über ausreichend Videospeicher verfügt. Testen Sie in der Praxis am besten beide Wege parallel: alltägliche Vervollständigungen und einfache Refactorings über das lokale Ollama-Modell, komplexere Agent-Aufgaben über ein gehostetes Modell per BYOK. So sparen Sie API-Kosten, ohne bei anspruchsvollen Aufgaben Qualität zu opfern.

Schritt 6: MCP-Server für externe Werkzeuge anbinden

Das Model Context Protocol (MCP) erlaubt es KI-Agenten, auf externe Werkzeuge und Datenquellen zuzugreifen, etwa ein Dateisystem, eine Datenbank oder einen internen Ticketservice. Zed tritt dabei ausschließlich als MCP-Client auf: Der Editor installiert lokale oder entfernte MCP-Server und reicht sie über sein eigenes Agentenprotokoll (ACP) an externe Agenten weiter. Zed selbst lässt sich also nicht als MCP-Server ansprechen, sondern nur als Konsument.

Um einen MCP-Server einzurichten, öffnen Sie die MCP-Einstellungen über die Command Palette (Suche nach “mcp”) oder direkt über die MCP-Dokumentation von Zed. Tragen Sie dort Server-Typ (lokal oder entfernt), den Startbefehl beziehungsweise die Verbindungsdaten sowie benötigte Zugangsdaten ein. Ein einfaches Beispiel für einen lokalen Dateisystem-Server ohne API-Schlüssel:

{
  "context_servers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/pfad/zu/ihrem/projekt"]
    }
  }
}

Speichern Sie die Konfiguration, aktivieren Sie den Server und wählen Sie im Agent Panel einen Agenten, der MCP-Werkzeuge nutzen kann. Von da an sieht der Agent Dateien im angegebenen Pfad als zusätzliches Werkzeug und kann sie im Rahmen Ihrer Anfrage lesen oder bearbeiten. Beschränken Sie den freigegebenen Pfad bewusst auf das aktuelle Projektverzeichnis, statt das gesamte Benutzerverzeichnis freizugeben, denn ein MCP-Server läuft mit denselben Rechten wie Ihr Benutzerkonto.

Über dasselbe Prinzip lassen sich auch anspruchsvollere Server einbinden, etwa ein GitHub-MCP-Server für den Zugriff auf Issues und Pull Requests oder ein Datenbank-Server für lesenden Zugriff auf eine lokale Postgres-Instanz. Der Aufbau der Konfiguration bleibt dabei immer gleich: Startbefehl, Argumente und gegebenenfalls Umgebungsvariablen für Zugangsdaten. Weil Zed nur als Client agiert und Server an externe Agenten weiterreicht, funktioniert derselbe MCP-Server, den Sie hier für Zed konfigurieren, in aller Regel unverändert auch in anderen MCP-fähigen Tools, ein Vorteil gegenüber proprietären, editor-spezifischen Integrationen.

Schritt 7: Inline Assist und Edit Predictions im Alltag nutzen

Neben dem Agent Panel für größere, mehrstufige Aufgaben bietet Zed zwei schnellere KI-Werkzeuge für den täglichen Gebrauch. Edit Predictions sind inline-Vervollständigungen, angetrieben von Zeds eigenem, offen gewichtetem Modell namens Zeta. Sie tippen wie gewohnt, Zed schlägt die nächsten Zeichen oder ganze Zeilen vor, und Sie bestätigen mit Tab. Im kostenlosen Personal-Plan sind das laut Zeds eigener Preisübersicht 2.000 akzeptierte Vorschläge pro Monat mit dem aktuellen Zeta2.1-Modell, im Pro- und Business-Plan unbegrenzt.

Der Inline Assist erlaubt gezieltere Änderungen: Sie markieren einen Codeabschnitt, beschreiben in natürlicher Sprache, was passieren soll, und das Modell schreibt den markierten Bereich direkt als Patch um, den Sie wie gehabt prüfen und bestätigen. Das eignet sich besonders für lokal begrenzte Aufgaben wie “diese Funktion mit Fehlerbehandlung versehen” oder “diesen Testfall um einen Edge Case erweitern”, während das Agent Panel eher für Aufgaben gedacht ist, die mehrere Dateien oder Werkzeuge gleichzeitig brauchen.

Schritt 8: settings.json individuell anpassen

Fast jede Einstellung in Zed lässt sich auch direkt über die zentrale Konfigurationsdatei settings.json steuern, was sich vor allem für Teams lohnt, die eine einheitliche Konfiguration versionieren wollen. Öffnen Sie die Datei über die Command Palette mit der Suche nach “open settings” oder direkt über das Menü.

{
  "theme": "One Dark",
  "buffer_font_size": 14,
  "format_on_save": "on",
  "agent": {
    "default_model": {
      "provider": "anthropic",
      "model": "claude"
    },
    "always_allow_tool_actions": false
  }
}

Der Parameter always_allow_tool_actions ist besonders relevant: Steht er auf false, muss jede Werkzeugaktion des Agenten (etwa das Ausführen eines Terminalbefehls) einzeln von Ihnen bestätigt werden. Für den produktiven Einsatz in echten Projekten ist das die sicherere Standardeinstellung, gerade wenn ein MCP-Server angebunden ist, der auf mehr als nur Lesezugriffe zugreifen kann. Eine projektweite settings.json im Repository-Root lässt sich zusammen mit dem Code versionieren, sodass alle Teammitglieder dieselbe Grundkonfiguration erhalten, ohne dass jeder sie einzeln von Hand nachbauen muss.

Neben der projektweiten Datei gibt es zusätzlich eine globale, benutzerbezogene settings.json außerhalb des Repositorys, die für alle Projekte auf Ihrem Rechner gilt. Persönliche Vorlieben wie Schriftgröße oder Theme gehören in diese globale Datei, projektspezifische Vorgaben wie Formatierungsregeln oder Standardmodell dagegen in die versionierte Variante im Repository. Kommt es zu Konflikten zwischen beiden Ebenen, gewinnt üblicherweise die projektspezifische Einstellung, damit ein Team nicht durch individuell abweichende, lokale Konfigurationen unterschiedliche Ergebnisse bekommt, wenn derselbe Agent dieselbe Anfrage bearbeitet.

Schritt 9: Multiplayer-Kollaboration mit KI-Agenten aktivieren

Zeds Multiplayer-Funktion gehört bereits zum kostenlosen Personal-Plan und lässt sich mit den KI-Agenten kombinieren. Laden Sie dazu über die Freigabe-Funktion in der oberen Leiste ein Teammitglied in Ihr aktuelles Projekt ein. Beide Personen sehen dieselben Dateien, Cursor-Positionen und Änderungen in Echtzeit, ganz ähnlich wie bei einem gemeinsam bearbeiteten Dokument.

Ein typischer Ablauf: Eine Person öffnet das Agent Panel und lässt den Agenten etwa die langsamste Funktion im Projekt suchen und mit einem Kommentar zur Ursache sowie einem TODO für den Fix versehen. Der Agent schlägt die Änderung vor, beide Beteiligten sehen den Diff in Echtzeit, und gemeinsam wird entschieden, ob er übernommen wird. Für verteilte Teams in Österreich und Deutschland, die remote zusammenarbeiten, ersetzt das in vielen Fällen einen separaten Screen-Sharing-Call für kleinere Pairing-Sessions. Beachten Sie dabei, dass MCP-Server und lokale Modelle, die Sie in den Schritten 5 und 6 eingerichtet haben, nur auf dem Rechner laufen, auf dem sie konfiguriert wurden. Ihr Kollaborationspartner sieht zwar den vom Agenten erzeugten Diff, braucht für eigene Agenten-Anfragen aber eine eigene, lokale Konfiguration.

Praktisch zeigt sich der Vorteil vor allem bei Code-Reviews im Team: Statt Änderungen erst zu committen, zu pushen und dann in einer separaten Oberfläche zu kommentieren, sitzen beide Personen direkt im selben Buffer und diskutieren Zeile für Zeile, während der Agent im Hintergrund Vorschläge einblendet. Für Onboarding neuer Teammitglieder eignet sich dieselbe Funktion ebenfalls gut: Eine erfahrene Kollegin öffnet gemeinsam mit einer neuen Person ein unbekanntes Modul, lässt den Agenten eine Zusammenfassung der wichtigsten Funktionen erstellen und bespricht anschließend live, worauf es beim jeweiligen Codebereich ankommt.

Schritt 10: Den richtigen Plan wählen (Personal, Pro, Business)

Für die bisherigen Schritte reicht der kostenlose Personal-Plan vollständig aus, solange Sie entweder Ihren eigenen API-Key per BYOK nutzen oder komplett lokal mit Ollama arbeiten. Erst wenn Sie Zeds eigene, gehostete Modelle ohne eigenen API-Key nutzen wollen oder im Team zentrale Governance brauchen, lohnt sich ein Blick auf die kostenpflichtigen Stufen.

Plan	Preis	Edit Predictions	Gehostete Modelle
Personal	0 $ (kostenlos)	2.000 pro Monat (Zeta2.1)	Nur per eigenem API-Key (BYOK) oder lokal
Pro	10 $ pro Nutzer/Monat	Unbegrenzt (Zeta2.1)	Alle Zed-gehosteten Modelle, 5 $ Guthaben inklusive
Business	30 $ pro Sitzplatz/Monat	Unbegrenzt (Zeta2.1)	Alle Modelle plus zentrale Governance und Richtlinien

Im Pro-Plan ist laut Zeds eigener Preisseite ein monatliches Guthaben von 5 Dollar für gehostete Modelle enthalten, darüber hinausgehende Nutzung wird zum jeweiligen Anbieterpreis zuzüglich eines Aufschlags von 10 Prozent abgerechnet. Der Business-Plan kennt keine Mindest-Sitzplatzzahl, für Teams ab 25 Sitzplätzen bietet Zed zusätzlich individuelle Rahmenverträge an. Wechseln Sie einen Plan über die Kontoeinstellungen in der Zed-Weboberfläche, eine Neuinstallation ist dafür nicht nötig.

Schritt 11: Vergleich zu VS Code und Cursor als Entscheidungshilfe

Bevor Sie Zed als tägliches Hauptwerkzeug etablieren, lohnt sich die Einordnung gegenüber den beiden bekanntesten Alternativen. GitHub Copilot ist in erster Linie eine Erweiterung für bestehende Editoren wie VS Code, JetBrains-IDEs oder Neovim und kein eigenständiger Editor, aktuell erhältlich ab 10 Dollar pro Monat im Pro-Plan. Cursor dagegen ist, ähnlich wie Zed, ein vollständiger, eigenständiger Editor, allerdings auf Basis eines VS-Code-Forks statt einer komplett neuen, in Rust geschriebenen Codebasis, mit einem kostenlosen Hobby-Plan und einem Pro-Plan ab 20 Dollar pro Monat.

Kriterium	Zed	GitHub Copilot	Cursor
Form	Eigenständiger Editor (Rust)	Erweiterung für bestehende Editoren	Eigenständiger Editor (VS-Code-Fork)
Einstiegspreis	0 $ (Personal)	10 $/Monat (Pro)	0 $ (Hobby), Pro ab 20 $/Monat
Lokale Modelle (Ollama & Co.)	Nativ als Kernfeature dokumentiert	Ja, per BYOK/OpenAI-kompatiblem Endpunkt	Ja, per Custom-Endpunkt, teils mit Tunneling nötig
Multiplayer-Kollaboration	Nativ eingebaut, auch kostenlos	Nein (rein einzelplatzbezogen)	Nein (rein einzelplatzbezogen)
KI-Änderungen als Diff/PR-Modell	Ja, standardmäßig	Je nach Oberfläche unterschiedlich	Ja, mit stärkerer Automatisierung/Autonomie

Die Positionierung lässt sich so zusammenfassen: Wer maximale Automatisierung und Agenten-Autonomie sucht, findet die eher bei Cursor als bei Zed. Wer dagegen einen schnellen, nativen Editor mit striktem Review-Workflow und echter Multiplayer-Unterstützung will, ohne für die Basisfunktionen zwingend zu bezahlen, ist mit Zed besser bedient. GitHub Copilot bleibt die richtige Wahl, wenn Sie ohnehin in VS Code oder einer JetBrains-IDE bleiben wollen und keinen Editorwechsel anstreben.

Preislich lohnt sich der direkte Vergleich der Einstiegsstufen: Mit dem kostenlosen Zed-Personal-Plan und einem eigenen Anthropic-Key zahlen Sie ausschließlich die tatsächliche API-Nutzung, ohne zusätzliche Aufschläge durch den Editor selbst. Bei Copilot Pro für 10 Dollar im Monat ist die Modellnutzung dagegen bereits in die Pauschale eingepreist, ein Vorteil für alle, die planbare Fixkosten einer nutzungsabhängigen Abrechnung vorziehen. Cursor positioniert sich mit 20 Dollar für den Pro-Plan preislich am oberen Ende der drei Optionen, bietet dafür aber die aktuell größte Automatisierungstiefe bei mehrstufigen Agenten-Aufgaben. Welche Variante sich lohnt, hängt am Ende weniger vom Preis allein ab als davon, wie viel Kontrolle über einzelne Änderungsschritte Sie im Alltag tatsächlich brauchen.

Schritt 12: Ein komplettes Mini-Projekt mit Zed und Agent umsetzen

Zum Abschluss verbinden Sie alle bisherigen Schritte in einem kleinen, aber vollständigen Beispiel: ein einfacher Kommandozeilen-Rechner in Python, den Sie komplett über das Agent Panel erstellen und testen lassen. Legen Sie zunächst einen neuen, leeren Ordner an und öffnen Sie ihn in Zed wie in Schritt 2 beschrieben.

Öffnen Sie das Agent Panel und geben Sie folgende Anfrage ein, entweder an Claude per BYOK oder an Ihr lokales Ollama-Modell aus Schritt 5:

Erstelle eine Datei calculator.py mit einer Funktion calculate(a, b, operator),
die Addition, Subtraktion, Multiplikation und Division unterstützt.
Wirf bei Division durch Null einen ValueError mit aussagekräftiger Meldung.
Erstelle außerdem eine Datei test_calculator.py mit Tests für alle vier
Operationen sowie für den Division-durch-Null-Fall, unter Verwendung von pytest.

Der Agent legt beide Dateien an und zeigt Ihnen den vollständigen Diff, bevor irgendetwas geschrieben wird. Prüfen Sie den Code kurz auf Plausibilität und bestätigen Sie die Änderung. Öffnen Sie danach das integrierte Terminal (Command Palette, Suche nach “terminal”) und führen Sie die Tests aus:

pip install pytest
pytest test_calculator.py -v

Eine typische Ausgabe bei erfolgreichem Durchlauf sieht so aus:

test_calculator.py::test_addition PASSED
test_calculator.py::test_subtraction PASSED
test_calculator.py::test_multiplication PASSED
test_calculator.py::test_division PASSED
test_calculator.py::test_division_by_zero PASSED

===================== 5 passed in 0.02s =====================

Schlägt ein Test fehl, markieren Sie die betroffene Zeile im Editor und nutzen den Inline Assist aus Schritt 7 mit einer kurzen Anweisung wie “behebe diesen fehlschlagenden Test”. Damit haben Sie in einem einzigen Durchlauf Installation, Agent-Konfiguration, Codegenerierung, Review per Diff und Testausführung kombiniert, also genau den Kreislauf, den Sie später auch in größeren, echten Projekten wiederholen.

Erweitern Sie das Beispiel bei Bedarf um eine weitere Anfrage an den Agenten, etwa “füge eine command-line-Schnittstelle hinzu, die Rechenoperationen über Argumente wie calculator.py 5 3 add entgegennimmt”. Der Agent greift dabei auf den bereits bestehenden Code zurück, ergänzt eine neue Funktion und passt bei Bedarf auch die bestehenden Tests an, sofern sich die Signatur der calculate-Funktion ändert. Genau an dieser Stelle zeigt sich der Unterschied zwischen einer einfachen Code-Vervollständigung und einem echten Agenten: Der Agent versteht den Kontext der bereits vorhandenen Dateien im Projekt und muss nicht bei jeder neuen Anfrage erneut mit dem vollständigen Code gefüttert werden.

Häufige Fehler beim Einstieg in Zed

Die folgenden fünf Fehler tauchen in der Praxis besonders häufig auf, meist in den ersten Tagen nach der Installation. Keiner davon ist schwer zu beheben, aber alle kosten unnötig Zeit, wenn man nicht weiß, wo man suchen muss.

API-Key im falschen Feld eingetragen: Wird der Anthropic-Key versehentlich im Feld für einen anderen Anbieter wie OpenRouter eingetragen, bleibt das Modell-Dropdown leer oder zeigt eine Fehlermeldung. Prüfen Sie, dass Anbieter und Schlüssel zueinander passen.
Ollama-Server nicht gestartet: Ein heruntergeladenes Modell taucht in Zed erst auf, wenn der Ollama-Hintergrunddienst tatsächlich läuft. Ein einfaches ollama list im Terminal zeigt, ob der Dienst erreichbar ist.
Zu großzügige MCP-Pfade: Wird der Dateisystem-Server auf das komplette Home-Verzeichnis statt auf den Projektordner beschränkt, bekommt der Agent Zugriff auf weit mehr Dateien als nötig. Das ist selten böswillig gemeint, aber ein unnötiges Risiko.
Zu viele aktive MCP-Server gleichzeitig: Jeder zusätzliche Server vergrößert den Kontext, den das Modell bei jeder Anfrage verarbeiten muss. In der Praxis wählt der Agent dann öfter das falsche Werkzeug oder antwortet spürbar langsamer.
settings.json mit fehlerhafter JSON-Syntax gespeichert: Ein fehlendes Komma oder eine überzählige Klammer führt dazu, dass Zed die komplette Konfigurationsdatei ignoriert und auf Standardwerte zurückfällt, oft ohne eine auffällige Fehlermeldung direkt im Editor.

Troubleshooting: Die häufigsten Probleme und Lösungen

Die folgende Tabelle deckt die Probleme ab, die in Community-Foren und Support-Kanälen am häufigsten gemeldet werden, zusammen mit dem jeweils passenden ersten Lösungsschritt. Arbeiten Sie die Tabelle bei einem konkreten Problem am besten von oben nach unten durch, viele der Ursachen überschneiden sich zwischen mehreren Symptomen.

Problem	Wahrscheinliche Ursache	Lösung
Editorfenster bleibt beim Start schwarz	Fehlender oder veralteter GPU-Treiber unter Linux	Grafiktreiber aktualisieren, Wayland/X11-Modus testen
Extension-Installation schlägt fehl	Firmenproxy blockiert den Erweiterungsserver	Proxy-Freigabe prüfen oder mobiles Netz testen
Anthropic-Modell erscheint nicht im Dropdown	API-Key falsch eingetragen oder ungültig	Key in der Anthropic-Konsole neu generieren und erneut eintragen
Ollama-Modell wird nicht erkannt	Ollama-Server läuft nicht im Hintergrund	`ollama serve` manuell starten, danach Zed neu verbinden
Agent reagiert sehr langsam	Zu viele aktive MCP-Server oder großes lokales Modell auf schwacher Hardware	Nicht benötigte Server deaktivieren, kleineres Modell wählen
settings.json wird ignoriert	Ungültige JSON-Syntax	Datei mit einem JSON-Validator prüfen, Kommas/Klammern kontrollieren
Multiplayer-Einladung funktioniert nicht	Eingeladene Person nicht bei Zed angemeldet	Anmeldung bei Zed prüfen, Link erneut senden
Edit Predictions bleiben aus	Monatliches Kontingent im Personal-Plan aufgebraucht	Auf Pro upgraden oder bis zum nächsten Abrechnungszeitraum warten
MCP-Server startet nicht	Node.js/npx fehlt oder ist veraltet	`node -v` und `npx --version` prüfen, Node.js aktualisieren

Fortgeschrittene Tipps für den produktiven Alltag

Sobald das Grundsetup steht, helfen ein paar Praktiken, aus einer Spielerei ein tägliches Arbeitswerkzeug zu machen. Nutzen Sie die seit Mai 2026 verfügbaren Terminal Threads, um externe Agenten wie Claude Code oder Sourcegraph Amp als zusätzliche Sidebar-Agenten neben dem Zed-eigenen Agent laufen zu lassen. Das eignet sich gut, um etwa einen Agenten für Refactoring und einen zweiten für die Codebasis-Suche parallel arbeiten zu lassen, ohne ständig zwischen separaten Fenstern zu wechseln.

Versionieren Sie projektweite Konfigurationen wie settings.json und die MCP-Server-Liste im Repository, halten Sie aber tatsächliche Geheimnisse wie API-Keys strikt draußen. Eine eingecheckte Konfigurationsdatei mit Platzhaltern für Umgebungsvariablen sorgt dafür, dass jedes Teammitglied dieselbe Grundausstattung bekommt, ohne dass Zugangsdaten geteilt werden müssen.

Für Teams mit sensiblen Daten lohnt sich eine bewusste Kombination: alltägliche, unkritische Aufgaben über ein gehostetes Modell im Pro-Plan, alles, was mit Kundendaten oder internen Systemen zu tun hat, ausschließlich über das lokale Ollama-Setup aus Schritt 5. So bleibt die Produktivität hoch, während sensible Inhalte den eigenen Rechner nie verlassen. Setzen Sie always_allow_tool_actions in produktiven Projekten grundsätzlich auf false, auch wenn das bedeutet, häufiger eine Bestätigung anzuklicken. Der zusätzliche Klick ist ein kleiner Preis für die Kontrolle darüber, welche Terminalbefehle ein Agent tatsächlich ausführen darf.

Ein letzter Tipp betrifft den Umgang mit mehreren Projekten gleichzeitig: Statt für jedes Repository ein eigenes Zed-Fenster offen zu halten, lohnt sich ein Blick auf die Arbeitsbereichs-Funktion, mit der Sie zwischen kürzlich geöffneten Projekten über die Command Palette wechseln, ohne den Editor neu zu starten. Das reduziert die Zahl gleichzeitig laufender Prozesse und damit auch den Speicherverbrauch, gerade wenn im Hintergrund zusätzlich ein lokales Ollama-Modell aktiv ist. Wer regelmäßig zwischen mehreren Projekten mit unterschiedlichen MCP-Servern wechselt, sollte außerdem projektspezifische statt global aktivierte Server bevorzugen, damit ein für Projekt A konfigurierter Datenbank-Server nicht versehentlich auch in Projekt B zur Verfügung steht.

Häufig gestellte Fragen zu Zed

Ist Zed komplett kostenlos nutzbar?
Der Editor selbst inklusive Multiplayer-Kollaboration ist dauerhaft kostenlos. Die KI-Funktionen lassen sich im kostenlosen Personal-Plan entweder über ein monatliches Kontingent an Edit Predictions, über den eigenen API-Key (BYOK) oder komplett lokal über Ollama nutzen. Erst wer Zeds eigene gehostete Modelle ohne eigenen Schlüssel nutzen will, braucht den Pro- oder Business-Plan.

Läuft Zed auch unter Windows genauso gut wie auf macOS?
Ja, Zed unterstützt macOS, Linux und Windows nativ über eigene Installationswege per winget oder Installer. Da der Editor GPU-beschleunigt rendert, hängt die gefühlte Geschwindigkeit stärker von der Treiberqualität als vom Betriebssystem selbst ab.

Brauche ich für lokale Modelle wie Ollama eine leistungsstarke GPU?
Eine dedizierte GPU beschleunigt die Inferenz deutlich, ist aber keine harte Voraussetzung. Kleinere Modelle laufen auch auf reiner CPU-Basis, allerdings spürbar langsamer als bei Cloud-Modellen. Für den Alltag empfiehlt sich, mit einem kleineren Modell zu starten und erst bei Bedarf auf ein größeres zu wechseln.

Kann ich Zed und GitHub Copilot gleichzeitig nutzen?
Technisch ist eine parallele Nutzung möglich, da beide unabhängig voneinander funktionieren. Sinnvoll ist das aber selten, da beide Tools ähnliche Aufgaben abdecken und die doppelte Konfiguration zusätzlichen Aufwand ohne klaren Mehrwert bedeutet.

Was passiert mit meinem Code, wenn ich ein lokales Modell über Ollama nutze?
Bei einer rein lokalen Ollama-Konfiguration verlässt der Code Ihren Rechner nicht, die Inferenz läuft vollständig lokal. Sobald Sie stattdessen ein gehostetes Modell über Zed oder einen Cloud-Anbieter wie Anthropic per BYOK nutzen, gelten die jeweiligen Datenschutzbedingungen dieses Anbieters.

Ist Zed ein MCP-Server oder ein MCP-Client?
Zed ist ausschließlich ein MCP-Client. Der Editor installiert und verwaltet MCP-Server und reicht deren Werkzeuge an KI-Agenten weiter, lässt sich selbst aber nicht als MCP-Server von anderen Anwendungen ansprechen.

Wie unterscheidet sich der Inline Assist vom Agent Panel?
Der Inline Assist bearbeitet einen einzelnen, von Ihnen markierten Codeabschnitt direkt an Ort und Stelle. Das Agent Panel eignet sich dagegen für umfangreichere Aufgaben, die mehrere Dateien, Werkzeuge oder MCP-Server gleichzeitig einbeziehen.

Kann ich in einem Team mit gemischten Editoren trotzdem gemeinsam an MCP-Servern arbeiten?
Ja, solange die MCP-Server als eigenständige Prozesse laufen, können sie von jedem MCP-fähigen Client genutzt werden, unabhängig davon, ob Kolleginnen und Kollegen Zed, Cursor oder VS Code mit GitHub Copilot einsetzen. Die Konfiguration muss lediglich in jedem Tool separat hinterlegt werden.

Lohnt sich der komplette Umstieg von VS Code auf Zed, oder reicht ein paralleler Test?
Ein vollständiger Umstieg ist am Anfang nicht nötig. Da Zed dieselben Projektordner ohne Konvertierung öffnet, lässt sich der Editor problemlos parallel zu einem bestehenden Setup testen, etwa für ein einzelnes Projekt über zwei bis drei Wochen. Erst wenn sich Tempo, Agent Panel und Multiplayer-Funktionen im Alltag bewährt haben, lohnt sich die endgültige Umstellung aller Projekte und gegebenenfalls des gesamten Teams.