Conductor wurde fast eingestellt. Was ich aus acht Tagen lerne

Am 4. November 2026 hat Conductor angekündigt, dass es zu Meta wechselt. Im Changelog stand an diesem Tag: „We’ll be winding down Conductor over the next weeks and months.“ Conductor Cloud sollte am 13. November nur noch lesbar sein und am 20. November abgeschaltet werden. Die lokale App sollte bis Anfang 2027 noch neue Modelle und kritische Bugfixes bekommen. Laut SiliconANGLE waren neue Anmeldungen und Downloads ab demselben Tag gestoppt.

Acht Tage später, am 12. November, schrieb Mitgründer Charlie Holtz: „CONDUCTOR IS BACK. We’ve decided to continue development of Conductor!“ Auf der Ankündigungsseite steht jetzt: „Plans have changed! We’ll still be developing Conductor.“

Glückwunsch an alle, die mit Conductor arbeiten. Das ist eine gute Nachricht, und ich meine das ernst. Ein Produkt, auf das sich Leute jeden Tag verlassen, geht weiter. Und das Team hat es öffentlich gesagt, mit Humor, auf demselben Kanal wie die schlechte Nachricht.

Ich baue Splitkick, eine kostenlose Open-Source-App für den Mac, mit der viele Agent-Sessions gleichzeitig laufen. Neutral bin ich also nicht, und ich will auch niemanden zum Wechseln bewegen. Acht Tage lang mussten viele Entwickler einen Umzug planen, den sie sich nicht ausgesucht hatten. Darüber lohnt es sich nachzudenken, egal welches Tool du nutzt.

Was Conductor richtig macht

Die Grundidee von Conductor ist einfach. Jeder Workspace bekommt einen eigenen Git-Worktree. In den eigenen Worten: „When you create a workspace, Conductor creates a Git worktree for that workspace and checks out a branch inside it.“ (Conductor docs)

Diese eine Entscheidung macht parallele Agenten erst praktikabel. Zwei Agenten im selben Ordner ändern dieselben Dateien und machen sich gegenseitig den Build kaputt. Bekommt jeder seinen eigenen Worktree und Branch, geht das nicht mehr. Du prüfst jeden Branch für sich, mergst den, der funktioniert, und wirfst die anderen weg. Git konnte das alles schon. Conductor hat es hinter einen Button gelegt und zur normalen Arbeitsweise gemacht.

Eine App brauchst du dafür nicht. Wenn du im Terminal lebst, reicht ein kurzes Skript um git worktree: ein Befehl pro Aufgabe, ein neuer Branch im eigenen Ordner, .env mitkopiert. Meins sind rund 70 Zeilen reines Git um drei Befehle:

git worktree add -b fix-login ../myrepo-fix-login origin/main   # neuer Branch, eigener Ordner
cp .env ../myrepo-fix-login/                                    # ignorierte Dateien, die Git nicht mitkopiert
git worktree remove ../myrepo-fix-login && git branch -d fix-login

Auch mit der schlechten Nachricht ist das Team gut umgegangen. Vom ersten Tag an gab es einen Export, einen Weg, Cloud-Workspaces auf den eigenen Mac zu holen, und die klare Aussage, dass sie „have never sold or trained on Conductor user data“.

Was acht Tage Ungewissheit lehren

Der Plan vom 4. November hatte echte Fristen. Neun Tage später sollten die Cloud-Workspaces nur noch lesbar sein, und laut SiliconANGLE sollte nach der Abschaltung das Löschen der Cloud-Daten beginnen. So ist es nicht gekommen. Acht Tage lang war es aber der Plan, und alle, die Conductor nutzen, mussten sich dieselben Fragen stellen. Es sind gute Fragen für jedes Tool, mit dem du jeden Tag arbeitest.

Wo liegt mein Session-Verlauf, und wer hat die Kontrolle darüber? In einer Session steckt, warum der Code so aussieht: die Sackgassen, die Entscheidung von spät in der Nacht, der Befehl, der am Ende funktioniert hat. Die Cloud-Chats von Conductor liegen auf den Servern von Conductor (Cloud FAQ). Ändert ein Anbieter seinen Kurs, hängt dein Verlauf an seinem Plan. Auch die Agent-CLIs darunter haben ihre eigene Uhr. Claude Code löscht Transkripte, die älter als 30 Tage sind, ab Werk (Claude Code docs). Dazu habe ich einen eigenen Text geschrieben: „Dein KI-Coding-Agent vergisst nach Plan“. Meine Regel heute: Sessions sind Dateien auf meiner Festplatte, in einem Ordner, den ich sichere.

Hängen meine Agenten am Tool, oder laufen sie nur darin? Steuert das Tool die Agent-CLI, die du selbst installiert hast, mit dem Abo, das du schon bezahlst, dann verlierst du mit dem Tool nur ein Fenster. Deine Agenten, Logins und Abos bleiben.

Könnte ich es selbst weiterbetreiben? Produkte wechseln den Besitzer, ändern ihre Pläne und überlegen es sich manchmal anders. Open Source unter einer Lizenz wie Apache 2.0 hält den Code öffentlich. Du oder jemand anderes kann ihn also weiter bauen, wenn die Firma den Kurs ändert.

Wo laufen die Agenten? Cloud-Sandboxes laufen weiter, wenn dein Laptop zugeklappt ist. Lokale Agenten laufen auf deinem Rechner, und nur solange er wach ist. Beides ist in Ordnung. Entscheide dich bewusst, und überleg dir, was mit deiner Arbeit passiert, wenn der Dienst eingestellt wird.

So betreibe ich parallele Agenten in Splitkick

So arbeite ich, Schritt für Schritt, so wie es die Doku beschreibt.

Schritt 1: ein Projekt hinzufügen

Ein Projekt ist ein Ordner auf deiner Festplatte. Klick auf Add project und wähl ihn aus. Splitkick kopiert und verschiebt ihn nicht. Im selben Menü kannst du auch ein Repository klonen. Ein Ordner ohne Git wird ein einfaches Projekt mit einer Session und ohne Worktrees. Das passt für Notizen, Recherche und Dokumente.

Schritt 2: ein Worktree pro Aufgabe

Öffne das Projekt und leg einen Worktree an. Splitkick erstellt einen Git-Worktree mit eigenem Branch unter ~/splitkick/<project name>/. Den Ordner kannst du pro Projekt ändern. Dein Haupt-Checkout bleibt unberührt. Ein Worktree kann von einem bestehenden Branch starten, von einem GitHub-Issue oder von einem Pull Request. Du kannst auch einen Worktree importieren, der schon auf der Festplatte liegt (Worktrees and sessions, englisch). Willst du es neben Conductor ausprobieren: Die Workspace-Ordner von Conductor unter ~/conductor/workspaces/ sind ebenfalls Git-Worktrees, du kannst sie also importieren. Deine Conductor-Chats bleiben in Conductor.

Schritt 3: Sessions starten, so viele du brauchst

Eine Session ist ein Gespräch mit einem Agenten in einem Worktree. Du kannst mehrere im selben Worktree laufen lassen oder eine pro Worktree. Für jede Session wählst du Agent, Modell und Modus:

• Plan: Der Agent liest und denkt nach und zeigt dir dann einen Plan, den du freigibst oder zurückschickst.
• Build: Er ändert Dateien und führt Befehle aus, und wenn er unsicher ist, fragt er.
• Yolo: keine Rückfragen. Nimm das in einem Worktree, den du wegwerfen kannst.

Es gibt zehn Agent-CLIs: Claude Code, Codex, Cursor, OpenCode, Pi, Command Code, Grok, Kimi Code, Antigravity und CodeRabbit für Reviews. Jede nutzt deine eigene Installation und deinen eigenen Login. Bei Claude Code heißt das: dein Pro- oder Max-Abo. Splitkick braucht keinen eigenen API-Key (Agent CLIs and modes, englisch).

Mehrere Projekte, ein Worktree pro Aufgabe und eine Session, die auf eine Antwort wartet.

Die Seitenleiste zeigt den Status jeder Session: läuft, wartet auf dich, fertig, im Review. Stellt ein Agent eine Frage, erscheint sie als Auswahl. Ich antworte und gehe zur nächsten Session.

Schritt 4: das Handy

Die Arbeit macht mein Mac. Mit dem Handy antworte ich, wenn ich nicht am Schreibtisch sitze. Die Einrichtung aus der Anleitung fürs Handy:

1. Tailscale auf Mac und Handy installieren und bei beiden mit demselben Konto anmelden.
2. In Splitkick Settings → Web Access öffnen und einschalten. Du bekommst einen Link mit Token, standardmäßig auf Port 3460.
3. Den Link in Safari öffnen, auf Teilen tippen und dann auf Zum Home-Bildschirm.

Das Handy spricht direkt mit dem Mac, ohne Splitkick-Server dazwischen. Auf dem Handy siehst du jede Session mit ihrem Status, beantwortest Fragen, gibst Pläne frei und schaust dir die Ergebnisse an. Terminal und Diff-Ansicht gibt es nur am Desktop. Web Access ist einfaches HTTP, also nutz Tailscale oder dein lokales Netz. Öffne den Port nicht ins Internet, außer hinter einem Reverse Proxy, der TLS ergänzt.

Dieselbe Frage auf dem Handy, über Tailscale.

Schritt 5: Agenten Splitkick bedienen lassen

Splitkick hat einen eingebauten MCP-Server mit 62 Werkzeugen (MCP server, englisch). Er ist ab Werk für jeden Agenten eingeschaltet. Ein Agent kann andere Sessions finden und lesen, Worktrees anlegen, Sessions starten und briefen, committen und einen Pull Request öffnen. Damit geht ein Muster, das ich oft nutze: Eine Session teilt eine Aufgabe auf, startet für jeden Teil eine Worker-Session in einem eigenen Worktree und sammelt die Ergebnisse ein.

Eine Session startet eine andere und schickt einer dritten eine Nachricht, über die MCP-Werkzeuge.

Es gibt zwei Bremsen. Die maximale Rekursionstiefe ist standardmäßig 3, Agenten können also nicht endlos Agenten starten. Das Limit liegt bei 20 neuen Sessions pro Minute. Außerdem sagt der Server den Agenten, dass sie dich fragen sollen, bevor sie etwas archivieren oder löschen.

Schritt 6: die Ergebnisse ansehen

Vieles, was meine Agenten liefern, ist kein Code: ein Bericht, ein PDF, ein Chart, ein Screenshot. Das Panel neben dem Chat zeigt Markdown formatiert an und öffnet PDFs, Bilder und Videos. HTML- und SVG-Dateien erscheinen gerendert in einer abgeschotteten Vorschau (Session tools, englisch).

Das Ergebnis eines Agenten, gerendert im Chat, mit dem nächsten Schritt.

Dann prüfe ich den Diff, committe, öffne einen Pull Request oder merge. Hat die Idee nicht funktioniert, archiviere ich den Worktree.

Wo der Verlauf landet

Alles, was Splitkick weiß, ist eine Datei unter ~/Library/Application Support/app.splitkick.desktop/, mit einem Ordner pro Session (Files on disk, englisch). Bei einer neuen Installation bleiben archivierte Sessions, bis du sie löschst (Archived items, englisch). Splitkick hat kein Konto und keine Telemetrie.

Ehrliche Grenzen

• Zuerst macOS. Die Mac-Version ist eine signierte und notarisierte DMG für Apple Silicon (M1 oder neuer). Seit v1.5.0 gibt es auch einen Installer für Windows 10 und 11. Er ist aber noch nicht signiert, deshalb warnt SmartScreen. Intel-Macs und Linux-Desktops werden nicht unterstützt (Installieren).
• Die Agenten bringst du mit. Mindestens eine Agent-CLI muss installiert und mit deinem eigenen Konto angemeldet sein, und Git muss in deinem PATH liegen. Das richtet Splitkick nicht für dich ein.
• Deine Prompts gehen weiter an die Modellanbieter. Splitkick speichert deine Sessions auf deiner Festplatte. Die Agenten schicken deine Prompts und die Dateien, die sie lesen, trotzdem an Anthropic, OpenAI oder wer auch immer das Modell betreibt. So funktionieren diese CLIs, in Splitkick und überall sonst.
• Dein Mac muss an sein. Splitkick lässt keine Agenten in Cloud-Sandboxes laufen. Die Handy-Ansicht hat keinen Offline-Modus. Schläft der Mac, erreicht ihn das Handy nicht.
• Eine Person, mehrere Geräte. Conductor hat einen Multiplayer-Modus für Teams. Splitkick ist für eine Person gebaut, die mit Mac und Handy arbeitet.
• Es ist jung. v1.0 kam am 16. Oktober 2026 (Changelog, englisch). Ich veröffentliche oft, und das heißt auch: Es gibt Ecken und Kanten.

So probierst du es aus

1. Lade die DMG von der Download-Seite und zieh sie in den Ordner „Programme“.
2. Öffne Settings und prüfe, ob deine Agent-CLIs gefunden werden.
3. Füg ein Repository hinzu, das du gut kennst, leg einen Worktree an und starte zwei Sessions mit zwei kleinen Aufgaben. Nimm verschiedene Agenten, wenn du sie hast.
4. Schalte Web Access ein, leg es auf den Home-Bildschirm deines Handys und beantworte die nächste Frage vom Sofa aus.

Den Rest erklärt die Doku.

Eine Bitte

Splitkick ist kostenlos, und der Code liegt unter Apache 2.0 auf GitHub. Wenn es dir nützt oder du willst, dass es das gibt, gib dem Repo bitte einen Stern. Das dauert zwei Sekunden. Für ein kleines Open-Source-Projekt sind Sterne der Weg, über den andere es finden. Wenn etwas kaputt ist, mach ein Issue auf.

---

Andreas Zeitler baut Splitkick bei Planetfall Software in Regensburg.