Sterne messen nichts: elf Agenten-Orchestratoren im Test

Sterne messen nichts: elf Agenten-Orchestratoren im Test

Ich habe alle elf Werkzeuge selbst installiert und benutzt, im Juli und im August. Sternzahlen, Lizenzen, Releases und Commit-Daten stammen aus der GitHub-API und wurden am 3. August 2026 abgerufen. Firmen- und Finanzierungszahlen stammen aus der Presse. Alles andere stammt von einem laufenden Bildschirm, und wo etwas ein Eindruck statt einer Messung ist, sage ich es.


Solange die meisten von uns Software schreiben, lautete die Antwort auf „Wo arbeiten Sie“: eine IDE. Egal in welcher Sprache, ein Fenster enthielt das ganze Projekt.

Hier ist meines, noch mit allem an seinem Platz.

Eine IDE mit allen geöffneten Bereichen

Die ersten Versionen waren Plugins. Sie behielten Ihre IDE und installierten den Assistenten hinein.

KI als Plugin, in der IDE, die Sie ohnehin schon hatten

Dann wurden die Editoren selbst um den Assistenten herum neu gebaut. Cursor ist ein Fork von VS Code, jenem Editor, auf den sich fast die ganze Branche geeinigt hatte, mit dem Modell in der Mitte. Entwickler wechselten, was gegen VS Code fast nichts je geschafft hatte, und Cursor erreichte 500 Millionen US-Dollar Jahresumsatz schneller als jedes Softwareunternehmen vor ihm. Die Lehre, die der Markt daraus zog: das Produkt war der Assistent, nicht der Editor.

JetBrains kam zum selben Schluss und ging weiter. Im März erschien Air, das JetBrains gar nicht mehr IDE nennt. Es ist ein Agentic Development Environment, um den Agenten herum gebaut statt um einen Texteditor, mit Platz für mehrere Agenten nebeneinander. Es läuft auf den Resten von Fleet, jenem Editor, den JetBrains drei Monate zuvor eingestellt hatte, nachdem man entschieden hatte, VS Code nicht schlagen zu können.

Cursor, um den Agenten herum gebaut

Dann die CLIs. LLM-Anbieter liefern ihre eigenen Kommandozeilenwerkzeuge aus, und neue Fähigkeiten landen zuerst dort. Ein Plugin umhüllt nur das, was der Anbieter freigibt, und folgt seinem eigenen Update-Rhythmus, also hinkt es hinterher. Die Entwickler zogen ins Terminal.

Das CLI des Anbieters, in einem Terminal im Editor

Je mehr vom Tag ins Terminal wanderte, desto mehr richteten die Leute ihr Fenster danach ein. Meines endete als glatte Halbierung: Editor auf der einen Seite, Agent auf der anderen.

Halb Editor, halb Agent

Jeder Schritt ging in dieselbe Richtung: mehr Zeit mit dem Modell, weniger mit der IDE.

Dann stieß ich an die Grenze dieser Aufteilung. Ein Terminal führt ein Gespräch gegen eine Arbeitskopie. Sobald ein Modell gut genug ist, um an zwei Modulen gleichzeitig zu arbeiten, ist das Knappe nicht mehr das Modell. Es ist, dass ich von allem nur eines habe. Eine zweite Aufgabe zu beginnen hieß: Änderungen wegstashen, das Repository noch einmal klonen, oder warten, bis die erste fertig ist.

Also suchte ich ein Werkzeug, das davon ausgeht, dass das Modell die Arbeit macht: mehrere Agenten gleichzeitig, jeder in seinem eigenen Git-Worktree, und die Diffs irgendwo, wo ich sie lesen kann. Daneben etwas Leichtes, um das Projekt zu öffnen. Bei allem Neuen reicht der Anspruch weiter: einer Kette von Agenten eine Aufgabe übergeben und ein fertiges Feature zurückbekommen.

Das Feld, und wo ich stehe

Es gibt eine von der Community gepflegte Liste von Werkzeugen, die das zu können behaupten, awesome-agent-orchestrators. Sie enthielt 153 Repositorys, als ich sie katalogisierte, und die Beschaffenheit dieser 153 sollte man kennen, bevor man von irgendwem eine Empfehlung annimmt, mich eingeschlossen.

Dreiundsiebzig Prozent wurden 2026 angelegt, und nur drei stammen aus der Zeit vor 2025: das mittlere Repository ist damit etwa fünf Monate alt. Elf Prozent sind bereits verwaist oder eingestellt: vierzehn sind verstummt, drei sind archiviert.

Elf davon habe ich installiert und benutzt: die, die ich ohnehin verwendete, plus die, die oft genug auftauchten, um eine Stunde wert zu sein. Das ist keine Stichprobe, und meine Arbeit ist fast ausschließlich Brownfield. Wer auf der grünen Wiese baut, wird sie womöglich in umgekehrter Reihenfolge einordnen.

Eine Offenlegung vor den Befunden. Nahezu jeder veröffentlichte Vergleich dieser Werkzeuge stammt von jemandem, der eines davon verkauft. Nimbalyst setzt sich selbst auf Platz vier, AgentsRoom eröffnet mit „volle Offenlegung: das sind wir“, und die sorgfältigste Recherche des Felds kommt vom CEO eines Orchestrierungsunternehmens, der das oben auf jeder Seite dazuschreibt. Ich verkaufe keinen Orchestrator, niemand hier finanziert mich, und ich habe für keines der elf etwas bezahlt, auch nicht für jenes mit einer kostenpflichtigen Stufe, das ich seit Monaten im Gratistarif betreibe.


Zwei Bauweisen

Sie treten als verschiedene Produkte auf: eine IDE, ein Kanban-Board, ein Unternehmen, eine Kommandozentrale. Lässt man sie laufen, unterscheiden sich die Namen stärker als die Produkte. Was sie trennt, ist der Weg, den eine Aufgabe von dem Satz, den Sie tippen, bis zu dem Pull Request nimmt, den Sie öffnen, und darauf gibt es nur zwei Antworten.

Das sind die Abläufe, wie ich sie fahre, nicht die, mit denen die Werkzeuge werben.

Typ 1. Eine Aufgabe, ein Worktree.

  1. Im Werkzeug einen Worktree anlegen.
  2. Die Spec schreiben.
  3. Der Agent liefert einen Plan zurück. Lesen Sie ihn, bevor irgendetwas läuft.
  4. Ihn bis zum Ende durchlaufen lassen, ohne jede Änderung einzeln freizugeben.
  5. Den Diff lesen.
  6. Einen Pull Request öffnen.
  7. Den Worktree löschen.

Die Schritte 2 bis 4 passieren im Coding-CLI und sehen genauso aus wie im Terminal: plan mode, auto mode, shift+tab zum Umschalten. Das Werkzeug liefert die Schritte 1, 5 und 7 und lässt Sie mehrere davon gleichzeitig fahren. Es ist die Aufteilung aus dem letzten Screenshot, vervielfacht.

Das passt zu einer Aufgabe, die klein genug ist, um vollständig spezifiziert zu werden, bevor sie beginnt. Ein großes Feature zerlegen Sie in kleinere Specs, lassen jede in ihrem eigenen Worktree von einem gemeinsamen Feature-Branch laufen und führen sie anschließend selbst wieder zusammen. Nichts, was ich in diesen Werkzeugen gesehen habe, nimmt Ihnen diesen Schritt ab.

Typ 2. Die Kette konfigurieren, die Aufgabe übergeben.

  1. Die Abfolge der Agenten konfigurieren. Einmal, nicht pro Aufgabe.
  2. Die Spec und den Kontext schreiben, den die Kette brauchen wird.
  3. Die Kette plant, führt aus und prüft ohne Sie.
  4. Build, Tests und Lint laufen als Schranken. Sie müssen bestehen, bevor die Arbeit weitergeht.
  5. Den Entwurf prüfen. Annehmen oder zurückschicken.
  6. Es läuft in der Schleife, bis das Ergebnis der Spec entspricht.
  7. Einen Pull Request öffnen.

Sie handeln bei Schritt 2 und bei Schritt 5. Der Rest läuft von allein.

Zwei Dinge müssen zutreffen, bevor Sie anfangen. Die Spec muss vollständig sein, weil die Kette nicht anhalten und Ihnen eine Frage stellen kann. Und das Feature muss sich vorab beschreiben lassen, ohne dass zuerst bestehende Abhängigkeiten oder externe Dienste untersucht werden müssen.

Liegen Sie bei einem von beiden falsch, merken Sie es spät, denn eine unvollständige Spec scheitert nicht schnell: die Kette läuft bis zum Ende und stellt Ihnen das Ganze in Rechnung. Ivy Tendril lieferte sechzehn gemergte Pull Requests für rund 56 US-Dollar und 600.000 Tokens, verteilt auf die vierzehn gemergten Pläne mit Kostendaten, 1,58 bis 9,52 US-Dollar pro Plan, eine Ausführung allein bei 10,98 US-Dollar. Das ist das günstige Ende von Typ 2, und Dorothy wie Agent Teams verbrauchen mehr.

Wo ein Fehler teuer ist, im Gesundheitswesen, in der Finanzbranche oder überall dort, wo ein Prüfer sitzt, achten Sie auf die Menge statt auf die Fehlerquote. Die Schranken kontrollieren jede Änderung strenger, als es eine Diff-Durchsicht bei Typ 1 je tut. Was sie Ihnen nicht sagen können, ist, ob die Arbeit überhaupt existieren sollte, und das Typ-2-Werkzeug, das ich am höchsten einschätze, erzeugte unablässig mehr davon. Irgendwer muss weiterhin sagen können, warum jede einzelne Änderung in der Codebasis steht.

Typ 1 Typ 2
Superset · Agent Orchestrator · Parallel Code · Emdash · Synara · Vibe Kanban Ivy Tendril · Dorothy · Agent Teams · Paperclip

Nach GitHub-Sternen sortiert

Werkzeug ★ (3. Aug. 2026) Was ich vorgefunden habe
Paperclip 75.473 am weitesten fortgeschritten, am hungrigsten nach Tokens
Vibe Kanban 27.633 dieselben Grundlagen wie Superset, alles Übrige abgeschaltet
Buzz (Block) 21.321 bekam es nicht eingerichtet
Superset 12.748 seit Monaten mein Alltagswerkzeug, im Gratistarif
Agent Orchestrator 8.754 sehr nah an Superset, etwas bessere Oberfläche
Emdash 5.324 aufgeräumt und einfach, guter Einstieg
Agent Teams 1.835 überladene Oberfläche, gefiel mir nicht
Synara 1.435 perfekte Oberfläche, miserable Bedienung
Parallel Code 914 einfach, praktisch, gut für den Alltag
Dorothy 329 die meisten Funktionen, und zu kompliziert
Ivy Tendril 169 der klarste Ablauf der elf; erzeugt reichlich Empfehlungen

Die elf, eines nach dem anderen

Typ 1

Superset. Mein Alltagswerkzeug und der Grund, warum die Aufteilung aus jenen Screenshots so lange überlebt hat. Neue Aufgabe, neuer Worktree, am Ende über die Oberfläche gelöscht. Nichts Kompliziertes, sehr schneller Start. Der Gratistarif hat alles, was ich brauche, und das zählt, denn es ist das einzige Werkzeug, das ich gefunden habe, das noch für sich selbst Geld verlangt: 20 US-Dollar im Monat für Team-Funktionen, die ich nicht nutze. Das Team liefert täglich Updates. Die Oberfläche verträgt noch Arbeit: ein paar Bugs, gelegentliche Aussetzer. Wer nichts Ausgefeiltes braucht, nimmt dieses hier.

Elastic License 2.0 seit dem 4. Februar 2026, als es Apache-2.0 verließ. macOS und Linux, wobei die Linux-Downloads bei etwa einem Prozent der macOS-Downloads liegen.

Superset: eine Änderung in der Durchsicht, acht Dateien und 111 Zeilen

Agent Orchestrator. Sehr nah an Superset, mit einer etwas besseren Oberfläche und einem echten Dashboard für den Sitzungsstand. Eines funktioniert nicht: Sie können ein Projekt oder einen ganzen Workspace hinzufügen, aber eine Sitzung lässt sich nur auf einem Projekt anlegen, und sobald ein Workspace hinzugefügt ist, kommen Sie an die Projekte darin nicht mehr heran. Gute Idee, unintuitive Umsetzung. Apache-2.0, kostenlos, alle drei Plattformen, weiterhin vor 1.0.

Agent Orchestrator

Parallel Code. Recht ähnlich zu Superset und Agent Orchestrator. Einfache, praktische Oberfläche, gut für den täglichen Gebrauch. Projekte links, je eine Aufgabe, und es zählt Merges statt Tokens. MIT, kostenlos, macOS und Linux, gepflegt von einer einzelnen Person, die seit 2017 auch Super Productivity betreibt.

Parallel Code

Emdash. Ein aufgeräumtes, einfaches Werkzeug für die Arbeit mit KI über viele Projekte hinweg. Guter Einstieg. Es erfindet fast kein eigenes Vokabular und lässt die eigene Oberfläche des Coding-Agenten laufen, statt sie zu ersetzen. Apache-2.0, YC W26, und im August 2025 angelegt, was es in diesem Feld zu einem alten Hasen macht.

Emdash

Synara. Perfekte Oberfläche, miserable Bedienung. Das schönste Werkzeug hier und eines der am schwersten zu bedienenden. Schöne Symbole, die eine Bedeutung tragen, die sie nie einführen; Hinweise, formuliert in Begriffen, die das Produkt nicht definiert; eine seltsame Standardkonfiguration. Immerhin hat es Workspaces, die Projekte gruppieren, was nützlich ist und was Agent Orchestrator verspricht und nicht liefern kann.

Nach einer Eingewöhnungszeit würde ich ihm trotzdem eine zweite Chance geben. MIT, v0.6.5, offen erkennbar früh.

Synara

Vibe Kanban. Eines der beliebtesten Werkzeuge des Felds, und seine Cloud-Hälfte ist inzwischen abgeschaltet. Die Grundfunktionen entsprechen mehr oder weniger denen von Superset; alles andere ist deaktiviert. Öffnen Sie ein Cloud-Projekt, bekommen Sie einen Export-Knopf und einen Link zur Abschaltungsankündigung.

Bloop machte am 10. April dicht: „die allermeisten sind Gratisnutzer, und wir konnten kein Geschäftsmodell finden, für das wir uns begeistern konnten.“ Im Beitrag hieß es, das Projekt werde weiterleben, von der Community gepflegt. Es lebt nicht weiter. Seit dem 25. April gibt es keinen Commit mehr. Die letzten beiden sind eine Versionsanhebung und ein Abschaltbanner im README, bei 27.633 Sternen und 535 offenen Issues. Der Blog eines Wettbewerbers erzählt seinen Lesern derzeit, dass Pull Requests aus der Community weiterhin übernommen werden. Werden sie nicht.

Die Software läuft lokal weiterhin. Nicht das Produkt hat aufgehört, das Unternehmen hat es getan.

Deshalb denke ich darüber nach, es wiederzubeleben. Support kostet hier weit weniger als in den Vereinigten Staaten, und ein Projekt, das keinen amerikanischen Maintainer tragen kann, kann einen ukrainischen tragen. Tausende täglicher Nutzer und 27.000 Sterne reichten Bloop nicht. Für eine einzelne Person in der Ukraine könnten sie reichen. Ich habe darüber nachgedacht. Getan habe ich es nicht.

Vibe Kanban

Typ 2

Ivy Tendril. Das vielversprechendste von allen. Fortgeschrittener als Superset, weniger kompliziert als Dorothy, und der Ablauf ist klar: Sie legen einen Plan an, er wird zum Job, der Job erzeugt einen Entwurf, Sie prüfen den Entwurf, übernehmen die vorgeschlagenen Änderungen, schauen noch einmal darüber und öffnen dann einen Pull Request. Es kostete mich fast keine Zeit, herauszufinden, wie das laufen soll.

Es ist außerdem das einzige Werkzeug, das Arbeit programmatisch abriegelt, statt Sie auf einen Diff schielen zu lassen. Build, Tests und Lint müssen bestehen, bevor irgendetwas weitergeht, und die Prüfungen springen direkt neben dem Knopf auf Grün, der den Pull Request öffnet.

Ivy Tendril: die Prüfschranken

Und dann gibt es Recommendations, das nach jeder Ausführung Verbesserungen vorschlägt. Das sieht nützlich aus, und das ist es auch. Genau das ist das Problem. Nehmen Sie eine an, erzeugt sie einen weiteren Entwurf, eine weitere Durchsicht und weitere Empfehlungen. Empfehlungen auf Empfehlungen. Aus ein paar Tickets kann ein Haufen widersprüchlicher Pull Requests werden; zwei von meinen wurden zweimal gemergt. Mit Bedacht einsetzen, und den Plan prüfen, bevor er läuft.

Lizenziert unter FSL-1.1-ALv2, die konkurrierende Produkte nicht erlaubt, unter einem Ankündigungsbeitrag mit dem Titel „Introducing Ivy Tendril: Open Source Coding Orchestration.“

Ivy Tendril: die Empfehlungsliste

Dorothy. Die meisten Funktionen von allem hier, und es beeindruckte mich genug, dass ich es geforkt und seinen Linux-Port geschrieben habe, da das Original nur macOS kennt. Dann trifft man auf den Rest: dreizehn Hauptbereiche, ein Super Agent, der an andere Agenten delegiert, neun vorkonfigurierte Rollenvorlagen, fünf MCP-Server und ein README von 34.000 Byte, das alles dokumentiert. Es ist zu kompliziert, und der Umgang mit solchen Werkzeugen erfordert echte Schulung, was ein Ausschlusskriterium sein kann.

Ich habe es mit einem Agenten an einer Aufgabe betrieben und lief trotzdem gegen diese Wand. Die Maschinerie steht auf dem Bildschirm, ob Sie sie nutzen oder nicht.

Dorothy

Agent Teams. Überladene Oberfläche, und Sie arbeiten mit einem Team statt mit einem Projekt, als führten Sie eine Agentur. Das Team-Dashboard nimmt mehr Platz ein als der Team-Chat, sodass es schwerer ist, Prompts und Ergebnisse zu verfolgen, als es sein müsste. Die Einrichtung beginnt damit, ein Team aus vier vorgeschlagenen Agenten anzulegen, benannt lead, developer, reviewer und so weiter.

Das ist derselbe anthropozentrische Rahmen, den Dorothy für seine Rollenvorlagen verwendet und auf dem Paperclip sein gesamtes Produkt aufbaut, und ich mag nichts davon. Agenten verhalten sich nicht wie Menschen. Der falsche Name weckt die falsche Erwartung darüber, was sie können und was nicht, und das beschert Ihnen falsche oder unerwartete Ergebnisse.

Ich verstehe durchaus, warum sich das verbreitet hat. Für nichttechnische Vibe Coder ist ein Team benannter Kollegen weit leichter vorstellbar als eine Kette konfigurierter Prompts, und genau deswegen ist es online die vorherrschende Metapher. Falsch bleibt sie trotzdem. Lizenziert unter AGPL-3.0.

Agent Teams

Paperclip. Das fortgeschrittenste Werkzeug hier und das mit dem größten Token-Hunger. Es modelliert ein ganzes Unternehmen. Ein Chief of Staff entscheidet, welche Art von Ingenieuren Sie brauchen, stellt sie ein, verteilt die Arbeit und berichtet nach oben an ein Board.

Paperclip: die Organisation, die sich selbst führt

Das ist die Metapher an ihrem äußersten Punkt, und dort verliert sie mich vollständig. Sie stellen niemanden ein. Sie entscheiden, welcher spezialisierte Agent welchen Schritt einer Entwicklungspipeline übernimmt, und das als Rekrutierung zu verkleiden, ist kindisch.

Paperclip: eine Aufgabe auf dem Weg durch die Organisation

Es ist das Werkzeug mit den meisten Sternen, das ich ausprobiert habe, und es kam schnell dorthin: 30.000 Sterne in drei Wochen für einen pseudonymen Maintainer, heute 75.473. Seine Einreichung bei Hacker News bekam drei Punkte und keinen einzigen Kommentar.

Das eine, das ich nicht zum Laufen bekam

Buzz, von Block. Jede Menge innovativer Ideen darin. Aber das Onboarding verlangt einen kryptografischen Identitätsschlüssel, besteht dann darauf, dass Sie einer Community beitreten oder eine gründen, und beim Gründen öffnet sich eine Übergabe an den Browser, aus der man nie zurückkommt. Nach mehreren Versuchen, die Web- und die Desktop-Hälfte zusammenzustöpseln, habe ich aufgegeben. Apache-2.0, öffentlich gestartet am 21. Juli, und offen erkennbar in der Vorabversion.

Buzz

Warum fast niemand dafür Geld verlangen kann

Ich habe die Preisseiten der fünfzig Coding-Orchestratoren aus dieser Liste geprüft. Drei haben je für das Werkzeug selbst Geld verlangt, und zwei davon sind tot: 1code wurde im März archiviert, die kostenpflichtige Stufe von Vibe Kanban ging im April mit Bloop unter. Superset ist das eine, das bleibt, und sein Gratistarif reicht für einen einzelnen Entwickler, und genau der benutzt diese Werkzeuge.

Der Grund ist struktureller Natur. Ein Orchestrator besitzt nichts Teures. Sie bringen Ihren eigenen Schlüssel mit, der Modellanbieter stellt Ihnen direkt in Rechnung, und das Werkzeug ist ein Fenster auf einen Vorgang, für den Sie ohnehin schon zahlen. In diesem Fenster steckt echte Arbeit (Worktrees, Diffs, Warteschlangen, Prüfstände), aber nichts davon kostet den Anbieter pro Token etwas, und nichts davon ist für sich allein schwierig genug, um ein Abonnement zu tragen. Das eine Werkzeug, das noch Geld verlangt, schafft es, indem es Team-Funktionen an Teams verkauft.

Bloop hat den Rest unverblümt ausgesprochen: sie konnten kein Geschäftsmodell finden, für das sie sich begeistern konnten. Dieser Satz trägt das ganze Gewicht. Ein risikokapitalfinanziertes Team braucht ein Ergebnis in der Größenordnung von Risikokapital, und dieselben tausenden täglichen Nutzer, die den einen Eigentümer langweilten, würden jemandem mit niedrigerer Kostenbasis den Lebensunterhalt sichern. Nicht der Vermögenswert ist kaputt. Die Renditeschwelle war es.


Was ich Ihnen raten würde

Typ 2 passt zu Greenfield. Typ 1 passt zu Brownfield.

Der Unterschied liegt im Kontext, nicht im Können. In einer neuen Codebasis sind Sie der Kontext: die Struktur ist das, was Sie festlegen. In einem Altsystem ist der Kontext die über Jahre angehäufte Menge an Abhängigkeiten und Integrationen, und kein Planungsprompt transportiert sie, also plant die Kette voller Zuversicht gegen ein falsches Modell Ihres Systems. Ein Typ-1-Werkzeug, das Ihre Codebasis falsch liest, verschwendet einen Prompt und Sie merken es. Ein Typ-2-Werkzeug schleppt das Missverständnis durch jede Stufe und stellt Ihnen jede einzelne in Rechnung.

Also: bei Brownfield Typ 1. Ich benutze Superset täglich; Parallel Code und Agent Orchestrator sind nah genug dran, dass ich beide nähme; Emdash ist der einfachste Einstieg. Bei Greenfield wird Typ 2 interessant, und Ivy Tendril ist das am besten gebaute davon.

Beurteilen Sie diese Werkzeuge nach Lizenz und Portabilität, nicht danach, wie gesund der Anbieter aussieht. Bei elf Prozent Schwund in einem fünf Monate alten Feld hat „wird es das nächstes Jahr noch geben“ keine Antwort. „Kann ich es weiter benutzen, nachdem das Unternehmen gestorben ist“ hat heute eine. Vibe Kanban ist der Beweis, dass dies die richtige Frage ist. Und lesen Sie die Lizenz selbst, denn Ivy Tendril nennt die FSL „open source“, und Superset wurde noch zwölf Wochen, nachdem es kein Apache-2.0 mehr war, als Apache-2.0 beschrieben.


Der Editor kehrt zurück

Die Agenten bearbeiten den Code in Worktrees, und die Diffs werden im Orchestrator durchgesehen. Was einem lokalen Editor bleibt, ist die Orientierung: den Baum lesen, ein paar Dateien öffnen, ein README prüfen. Das ist die Arbeit eines Betrachters, und eine vollständige IDE ist ein schwerer Weg dorthin. Sie bezahlen Indizierung und Startzeit für Arbeit, die weder das eine noch das andere braucht.

Die Orchestratoren setzen das voraus. Superset bietet den Absprung nach VS Code, Cursor, Windsurf, JetBrains oder Xcode an.

Also benutze ich stattdessen Zed. In Rust geschrieben, schneller als VS Code, weniger Speicher. Das ist ein Eindruck aus der Nutzung, kein Benchmark.

Zed: dieser Artikel in der Vorschau, daneben ein laufender Coding-Agent

Dann habe ich mir angesehen, was Zed dieses Jahr ausgeliefert hat. Angelegt im Februar 2021, viereinhalb Jahre vor fast allem in diesem Feld. 87.944 Sterne, mehr als jeder Orchestrator, den ich getestet habe. Es hat 1.0 erreicht, 44,5 Millionen US-Dollar eingesammelt, liefert ein offenes Protokoll aus, über das Agenten von Anthropic und OpenAI nativ laufen, und betreibt inzwischen parallele Agenten an verschiedenen Teilen einer Codebasis gleichzeitig.

Und es verlangt Geld für die KI. Der Editor ist kostenlos; die kostenpflichtige Stufe verkauft gehostete Modelle. Jeder Orchestrator, den ich ausprobiert habe, reicht Ihren Schlüssel direkt an den Anbieter durch und nimmt nichts davon. Bei einem Goldrausch liegt das sichere Geld in den Schaufeln, und Zed ist hier der Einzige, der welche verkauft.

← Blog