Superconductor : orchestrer des agents de code en parallèle sur macOS, sans friction

📌 Superconductor centralise l’exécution de plusieurs agents de code en parallèle dans une seule application macOS, avec des worktrees Git isolés, un terminal natif rendu sur GPU et un flux “review → commit → push → PR → merge” pilotable au clavier.

Quand les agents deviennent une façon normale de travailler, le goulot d’étranglement n’est plus le modèle mais l’interface autour. Lancer deux sessions ici, une autre dans un terminal séparé, jongler entre des branches, retrouver quel agent parle de quel fichier, ouvrir un diff, pousser une branche, créer une PR, puis revenir répondre à un agent qui attend… ce sont des micro-frictions qui s’empilent. Superconductor vise exactement cette zone grise entre “un agent en CLI” et “un vrai poste de pilotage”.

L’idée est simple: chaque agent tourne comme un sous-processus local, et chaque session peut vivre dans son propre worktree Git. Résultat: plusieurs tâches peuvent avancer en même temps sans se marcher dessus, tout en gardant un historique Git propre. L’interface met côte à côte le terminal brut et une vue conversationnelle plus lisible, pour passer du “je veux voir la sortie exacte” au “je veux suivre le raisonnement” sans perdre le contexte.

Au quotidien, ça change surtout la manière de découper le travail. Une session peut préparer une refactor, une autre explorer une piste de bug, une troisième écrire des tests, pendant qu’une quatrième relit un diff ou met à jour une documentation. Le point clé n’est pas de multiplier les agents pour le plaisir, mais de rendre naturel le fait de paralléliser des sous-tâches sans se retrouver avec un dépôt dans un état confus.

Superconductor reste volontairement agnostique: il peut orchestrer Claude Code, Codex, Gemini CLI, OpenCode, Cursor Agent, ou n’importe quel agent en ligne de commande. Chaque session peut choisir son provider, son modèle et son niveau de “reasoning effort”, sans proxy ni encapsulation: les abonnements et identifiants restent ceux déjà utilisés en local par les outils CLI.

Au milieu de tout ça, Git n’est pas un détail. Le workflow met en avant la gestion de branches, la revue de diffs et le chemin vers la livraison. Une fois une session terminée, l’étape suivante ne devrait pas être “ouvrir une autre appli”, mais “valider, pousser, ouvrir une PR, résoudre un conflit si besoin, puis merger”. Superconductor propose même un bouton d’action “intelligent” qui enchaîne ce qui vient ensuite (commit, push, création de PR, résolution, merge), avec la possibilité d’adapter les étapes au style de travail.

points clés

• ⚙️ Worktrees Git isolés pour lancer plusieurs chantiers sans interférences
• 🧠 Support d’agents CLI variés, y compris des commandes personnalisées
• 🚀 Démarrage très rapide et interface native (Rust) avec rendu Metal sur GPU
• 🧰 Multiplexeur de terminal intégré + bascule terminal brut / vue chat
• 🧩 Layouts multiples, Picture-in-Picture, thèmes et polices par workspace
• 🔒 Architecture local-first: sessions, diffs et conversations stockés localement, sans télémétrie

La performance est un argument central. L’application est construite en Rust, s’appuie sur Metal pour le rendu, et cherche à éviter la pile web classique (pas de runtime Electron, pas de navigateur embarqué, pas de terminal “web”). L’intérêt est concret: un lancement quasi instantané, un terminal fluide même avec plusieurs onglets, et une sensation d’outil “du système” plutôt qu’un site emballé dans une fenêtre.

La flexibilité est traitée comme une fonctionnalité produit, pas comme un bonus. Les dispositions de panneaux peuvent s’adapter à différents rythmes: terminal empilé, horizontal, ou un terminal en bas; on peut aussi sortir un onglet dans une fenêtre séparée en Picture-in-Picture, le garder épinglé et visible pendant une autre tâche. Les thèmes (clair/sombre/système) et les couleurs “chrome” peuvent varier par workspace, avec le choix des polices d’interface, monospace et terminal.

Un point souvent sous-estimé avec les agents: la reprise de contexte. Superconductor met en avant le fait de retrouver chaque session exactement là où elle a été laissée. Fermer l’application, la rouvrir, et récupérer l’état des onglets et des conversations évite l’effet “redémarrer et réexpliquer”, surtout quand plusieurs threads de travail coexistent.

Pour les workflows un peu plus industrialisés, l’app ajoute une couche d’automatisation par dépôt: scripts de setup, d’exécution et de teardown, configurables une fois et versionnables via Git. C’est utile pour standardiser un environnement (installer des dépendances, préparer des variables, lancer une suite de tests, nettoyer un workspace) sans transformer chaque session d’agent en bataille d’initialisation.

La partie “multi-repo” existe aussi: un workspace peut regrouper frontend et backend, ou plusieurs services, afin de coordonner des changements transverses. L’intérêt est d’éviter de fragmenter l’attention entre plusieurs fenêtres et plusieurs conventions de terminal, tout en gardant une vision unifiée de ce qui est en cours.

Sur la confidentialité, l’approche est explicite: local-first, pas de collecte de données, pas d’analytics, pas de télémétrie. Les sessions, diffs et conversations restent sur la machine. Les agents étant lancés comme sous-processus natifs, les identifiants ne sont pas “absorbés” par un service intermédiaire: chaque outil CLI continue de fonctionner comme il le fait déjà en local.

Démarrer est volontairement direct. Le parcours type suit trois étapes: télécharger l’app sur macOS, ouvrir un dépôt Git, puis créer des worktrees et lancer des agents en parallèle. Ensuite, la boucle de livraison se fait dans le même espace: revue du diff, gestion de la branche, suivi de statut de PR, et merge quand c’est prêt.

macOS est la plateforme supportée aujourd’hui, avec une emphase sur les performances Apple Silicon. Des ports Windows et Linux sont annoncés comme prévus, mais l’orientation actuelle reste celle d’un outil natif, optimisé, et focalisé sur une expérience clavier.

À retenir: Superconductor est un poste de pilotage pour l’ingénierie “agentique” quand le vrai problème n’est plus d’avoir un agent, mais de faire tourner plusieurs chantiers en parallèle sans perdre le contrôle de Git, du contexte et du chemin jusqu’à la PR.