Muse Code: nicht der neue Agent, das Ereignisprotokoll

Meta hat am 5. August Muse Code veröffentlicht, einen Coding-Agenten für das Terminal, angetrieben von Muse Spark 1.2. Damit gibt es neben Claude Code und Codex einen dritten Terminal-Agenten aus einem großen Labor. Der Start allein ist keine Nachricht. Interessant sind drei konkrete Entwurfsentscheidungen: ein lokales Ereignisprotokoll, das jeden Lauf wiederholbar macht, ein Plan, der eine Freigabe braucht, bevor gearbeitet wird, und ein mitgeliefertes Skill, dessen einzige Aufgabe es ist, diesen Plan zu zerlegen. Meine These: Der Wettbewerb verschiebt sich vom Modell auf das Gerüst, und genau dort entscheidet sich, ob ein Lauf im Nachhinein prüfbar ist.

Was ist Muse Code?

Muse Code ist ein Terminal-Agent im Beta-Status, den Meta für macOS und Linux über ein Installationsskript ausliefert. Laut Ankündigung übernimmt er komplexe Software-Aufgaben in großen Repositories: Änderungen planen, Code schreiben, Ergebnisse validieren. Er kann dafür mehrere dauerhafte Subagenten koordinieren.

Der Aufbau ist bewusst schlicht beschrieben: eine einfache Agentenschleife plus asynchrone Hintergrundagenten. Der Unterschied zu vielen anderen Umsetzungen liegt in der Lebensdauer. Diese spezialisierten Agenten bleiben über die ganze Sitzung aktiv, statt für einzelne Aufgaben gestartet und wieder verworfen zu werden. Meta begründet das damit, dass so redundantes Sammeln derselben Informationen entfällt. Die Hintergrundagenten führen nächste Schritte aus und entscheiden selbst, wann sie an den Hauptagenten zurückmelden. Das senke Latenz und den Bedarf, bei schwierigen mehrstufigen Aufgaben nachzusteuern.

Warum ist das Ereignisprotokoll der interessanteste Teil?

Weil es aus einem Lauf ein nachlesbares Objekt macht. Muse Code führt ein lokales Ereignisprotokoll, in das jeder Modellaufruf, jeder Werkzeuglauf, jede Freigabe und jede Änderung angehängt wird. Meta nennt das die eine Quelle der Wahrheit für die Laufzeit und beschreibt die Folge so: Die Ausführung ist wiederholgenau und neustartfest, nach einem Absturz kann der Agent exakt dort weitermachen, wo er stehen geblieben ist. Das sei die Voraussetzung für lange Läufe, die nicht an einem Fehler scheitern.

Meta verkauft das als Robustheit. Für die Arbeitspraxis ist die zweite Eigenschaft die wichtigere. Ein Lauf, der sich exakt wiederholen lässt, ist ein Lauf, den Sie im Nachhinein Schritt für Schritt ansehen können. Wenn ein Agent nach vier Stunden ein Ergebnis liefert, ist die Frage selten, ob es kompiliert. Die Frage ist, an welcher Stelle er eine Annahme getroffen hat, die Sie nicht getroffen hätten. Ein Protokoll, das Freigaben und Werkzeugaufrufe in derselben Reihenfolge festhält, ist die Grundlage dafür.

Zwei Einschränkungen gehören dazu. Erstens beschreibt Meta das Protokoll als Laufzeitdesign, nicht als Prüfprotokoll. Zu Format, Aufbewahrung, Export oder Zugriff steht in der Ankündigung nichts. Zweitens ist es lokal. Auf Ihrer Maschine ist das ein Vorteil, in einem Team, das Ergebnisse gemeinsam verantwortet, ist es erst einmal nur eine Datei auf einem Rechner. Ob daraus ein belastbarer Nachweis wird, entscheidet nicht die Ankündigung, sondern was Sie damit tun.

Was leisten /plan, /grill und /goal?

Muse Code bringt mehrere Skills mit. /plan macht aus einer Aufgabe einen Plan, der freigegeben werden muss. /grill setzt diesem Plan zu, bis er standhält. /goal arbeitet auf die Erfüllung eines gesetzten Ziels hin.

Die Reihenfolge ist der Punkt. Die Freigabe sitzt vor der Arbeit, nicht danach, und dazwischen liegt ein Schritt, der den eigenen Plan angreift. Das ist eine ungewöhnliche Stelle für Prüfung. Die meisten Werkzeuge prüfen das Ergebnis, also Tests, Diff, Review. Muse Code prüft zusätzlich die Absicht, bevor Kosten entstehen. Bei Läufen, die über Stunden gehen, ist das die günstigste Stelle, an der ein Missverständnis auffallen kann.

Nur: Ein durchgerüttelter Plan ist keine geprüfte Änderung. Wer einen Plan freigibt, hat einen Plan freigegeben, nicht den Diff, der daraus entsteht. Die Gefahr eines guten Vorab-Gates ist, dass es sich wie eine Abnahme anfühlt. Sie ist es nicht. Die Verantwortung für das, was am Ende im Repository landet, bleibt bei dem Menschen, der den Lauf gestartet hat.

Und das Modell?

Muse Spark 1.2 ist ein auf Code ausgerichtetes Update von Muse Spark 1.1, mit Verbesserungen bei Codegenerierung, komplexem Debugging, Verständnis ganzer Codebasen und durchgehenden Entwickler-Workflows. Meta hat nach eigener Angabe das Trainingsbudget für Coding-Aufgaben deutlich erhöht und die Vielfalt der Trainingsumgebungen ausgeweitet. Trainiert wurde auf langlaufende Aufgaben, darunter die Erzeugung ganzer Repositories, große End-to-End-Projekte und Auto-Research.

Bemerkenswert ist die Kopplung: Modell und Agent wurden gemeinsam trainiert, mit Trajektorien aus dem Harness selbst und mit Anpassungen für Ziele, Kontextverdichtung und Subagenten, dazu die Einbindung des Muse-Code-Werkzeugsatzes. Das erklärt, warum die Zahlen aus der Ankündigung noch schwerer auf Ihren Aufbau zu übertragen sind als sonst. Gemessen wird ein Paar aus Modell und Gerüst, nicht ein Modell. Die Ankündigung zeigt Balkendiagramme zu Terminal-Bench 2.1, DeepSWE 1.1 und einem internen Coding-Benchmark von Meta. Werte nennt der Text nicht, und ich nenne hier keine, die ich nicht belegen kann.

Konkreter ist die Fallstudie zur Kernel-Optimierung. Meta hat das Modell über mehr als 1.000 Werkzeugaufrufe und bis zu 24 Stunden GPU-Kernel optimieren lassen, KDA und MLA auf NVIDIA-Hopper-Karten, gegen eine vorgegebene Referenz. Fremde Kernel-Bibliotheken durfte das Modell nicht importieren, es musste in Triton implementieren. Die MLA-Messung lief gegen eine PyTorch-Referenz bei Batchgröße 1, 64 Köpfen, Sequenzlänge 8192 und latenter Dimension 512. Interessant daran ist weniger die Verbesserung als die Laufdauer. 24 Stunden autonome Arbeit sind genau der Fall, in dem ein neustartfestes Protokoll kein Komfortmerkmal mehr ist.

Was heißt das für Ihre Arbeit?

Erstens: Bewerten Sie einen neuen Agenten nicht danach, was er kann, sondern danach, was er hinterlässt. Die Frage „kann ich einen Lauf nachvollziehen, nachdem er durch ist?“ trennt Werkzeuge deutlicher als jede Rangliste. Muse Code beantwortet sie technisch mit Ja, und das ist der Grund, warum dieser Start mehr ist als ein weiterer Eintrag in einer Liste.

Zweitens: Beta bleibt Beta. Die Installation läuft über ein Skript, das aus dem Netz in die Shell geleitet wird. Sehen Sie es sich an, bevor Sie es ausführen, und geben Sie dem Agenten eine Umgebung mit klaren Grenzen, also einen eigenen Checkout, eingeschränkte Zugangsdaten, eine Maschine, deren Verlust Sie verkraften. Ein Freigabe-Gate im Plan ersetzt das nicht.

Drittens: Das Muster wiederholt sich. Bei Codex Remote war es die Freigabe durch den Menschen, bei der Orchestrierung in Claude Code die Härtung des Gerüsts. Muse Code setzt an derselben Stelle an. Das ist die Linie im Agentic Engineering: Verlässlichkeit steckt nicht im Modell, sondern in der Architektur drumherum. Ein Ereignisprotokoll ist ein Stück dieser Architektur, kein Ersatz für Ihre Prüfung.

Quellen

• Meta AI Research: Introducing Muse Code and Muse Spark 1.2