Muse Code einrichten: Von der Installation zum ersten Merge
Metas Terminal-Coding-Agent ist bewusst minimalistisch im Setup: ein Befehl, ein Browser-Login — und du steuerst eine Multi-Agenten-Session im eigenen Repository. Hier ist der komplette Weg, inklusive der Stellen, an denen sich Innehalten lohnt.
Ein Befehl, ein Binary
Muse Code ist als Beta für macOS und Linux verfügbar, und die Installation ist ein Einzeiler:
curl -fsSL https://dev.meta.ai/install.sh | bashDas Skript legt ein muse-Binary in deinen PATH; muse --version bestätigt, dass es angekommen ist. Ein Remote-Skript direkt in die Bash zu pipen ist bei jedem Anbieter ein Bequemlichkeits-Trade-off — vorsichtige Teams laden das Skript also erst herunter (curl -fsSL https://dev.meta.ai/install.sh -o install.sh), lesen es und führen es dann aus. Beachte, was bewusst fehlt: Es gibt kein IDE-Plugin und keine Desktop-App. Anders als manche konkurrierende Agenten ist Muse Code absichtlich reines Terminal.
Anmeldung im Browser, Keys für Maschinen
Beim ersten Start von muse öffnet sich der Browser zum Login auf dev.meta.ai mit einem Meta-Developer-Account. Die Zugangsdaten werden danach lokal gecacht — du musst dich also nicht in jeder Session neu anmelden. Alles — Zugriff wie Abrechnung — läuft über denselben Meta-Model-API-Account, der auch die Muse-Spark-Modelle direkt bedient.
Für CI-Pipelines, Skripte und Headless-Maschinen sparst du dir den Browser: Erzeuge im Model-API-Dashboard einen Key (API keys → Create API key) und exportiere ihn als MODEL_API_KEY. Das Key-Format sieht aus wie LLM|{numeric_id}|{secret} — ab damit in eine Umgebungsvariable oder einen Secrets-Manager, niemals in den Code.
Wähl eine erste Aufgabe, die den Loop beweist
Wechsle per cd in ein beliebiges Git-Repository und starte muse. Der Agent liest den lokalen Kontext ein und öffnet eine Task-Schleife; du beschreibst gewünschte Ergebnisse in normaler Sprache. Widersteh der Versuchung, mit einem großen Refactoring zu starten. Der schnellste Weg, den Charakter von Muse Code zu verstehen, ist eine kleine, überprüfbare Aufgabe — etwas wie „ergänze einen fehlenden Test für die Funktion parseDate und stell sicher, dass er durchläuft“.
Innerhalb weniger Minuten siehst du die Arbeitsteilung, die das Produkt ausmacht: Ein Worker-Agent entwirft die Änderung, ein Reviewer-Agent kritisiert sie im Hintergrund, und der Test läuft tatsächlich. Dieses Worker-und-Reviewer-Muster ist bei jeder Aufgabe standardmäßig aktiv — deshalb beschreibt Meta das Produkt als multi-agent by default und nicht als Multi-Agent auf Wunsch.
Zwei Kostenhebel, die du an Tag eins lernen solltest
Muse Spark ist ein Reasoning-Modell: Es denkt, bevor es antwortet, und diese Denk-Token werden als Output abgerechnet. Der Befehl /effort regelt das Reasoning hoch oder runter — ein routinemäßiges Rename bezahlt so nicht für tiefes Grübeln, während ein fieser Concurrency-Bug es bekommen kann. Zweitens: Feste Regeln — dein Ton, dein Format, deine Konventionen — gehören einmal in eine System-Message, nicht wiederholt in jeden Prompt. Mit beidem zusammen bleiben die Rechnungen am ersten Tag langweilig — genau das, was du willst.
Wie es weitergeht
Sobald sich der Loop vertraut anfühlt, strukturieren drei eingebaute Skills die größere Arbeit: /plan macht aus einer Aufgabe einen freigabepflichtigen Plan, /grill testet diesen Plan auf Belastbarkeit, bis er hält, und /goal hält den Agenten auf Kurs zu dem Ziel, das du gesetzt hast. Ausführlich behandeln wir sie im Beitrag zu den mitgelieferten Skills, die vollständige Referenz steht in den Docs.