Kurzfassung: Meta hat am 5. August 2026 Muse Code veröffentlicht, den ersten eigenen Coding-Agenten. Er kostet 1,25 US-Dollar je Million Eingabe-Token und 4,25 US-Dollar je Million Ausgabe-Token. Daneben gibt es einen günstigeren Tarif, der die Zustimmung verlangt, die eigenen Daten für das Training zu verwenden.

Der interessante Teil dieser Produktankündigung ist nicht das Produkt. Es ist die Preisliste.

Was Meta gebaut hat

Muse Code ist ein Agent für die Kommandozeile, angetrieben vom Modell Muse Spark 1.2, seit dem 5. August 2026 als Beta verfügbar für macOS und Linux. Er ist nicht für kurze Skripte gedacht, sondern für große Codebasen. Bei umfangreichen Aufgaben startet er mehrere Unteragenten, die gleichzeitig in getrennten Arbeitskopien arbeiten, während der Hauptstand unberührt bleibt.

Das ist solide gebaut und ordnet sich in ein Feld ein, in dem Anthropic und OpenAI seit einiger Zeit vergleichbare Werkzeuge anbieten. Meta positioniert sich darunter im Preis.

Der Tarif, über den geredet werden sollte

Es gibt zwei Wege, Muse Code zu bezahlen.

Der erste ist Abrechnung nach Verbrauch: 1,25 US-Dollar je Million Eingabe-Token, 4,25 US-Dollar je Million Ausgabe-Token.

Der zweite ist ein vergünstigter Tarif für Beitragende. Wer ihn wählt, stimmt zu, dass die eigenen Daten für das Training des Modells verwendet werden.

Das ist ein bekanntes Muster aus dem Verbrauchergeschäft, und dort ist es schon fragwürdig. In einem Werkzeug für Softwareentwicklung ist es etwas anderes.

Warum das bei Code nicht dasselbe ist wie bei einer Foto-App

Wer eine kostenlose Foto-App nutzt und der Trainingsnutzung zustimmt, gibt eigene Bilder her. Es sind seine.

Wer einen Coding-Agenten in einem beruflichen Projekt einsetzt, gibt in aller Regel nicht die eigenen Daten her. Der Quelltext gehört dem Auftraggeber. Er enthält Geschäftslogik, interne Schnittstellen, Kommentare mit Namen von Kundinnen und Kunden, manchmal Testdaten. Die Entwicklerin, die den Rabatt anklickt, trifft damit eine Entscheidung über fremdes Eigentum.

Diese Entscheidung steht denen, die sie in der Praxis treffen, meistens gar nicht zu. Sie fällt in einem Einrichtungsdialog, in einer Zeile, die aussieht wie eine Sparoption.

Für Auftragsarbeit kommt hinzu: Wer im Kundenauftrag entwickelt, hat vertragliche Pflichten zur Vertraulichkeit. Ein Tarif, der Trainingsnutzung zur Bedingung macht, kollidiert damit unmittelbar. Wer Gesundheitsdaten oder andere besonders geschützte Daten berührt, hat das Thema ohnehin nicht zur Wahl.

Was ich Unternehmen empfehle

Den Tarif zur Leitungsentscheidung machen, nicht zur Entwicklerentscheidung. Nicht weil Entwicklerinnen und Entwickler es nicht verstünden, sondern weil sie es nicht entscheiden dürfen sollten. Es ist nicht ihr Eigentum.

Vor der Einführung in den Kundenvertrag schauen. Steht dort eine Vertraulichkeitsklausel, ist die Frage beantwortet.

Den Preisunterschied ausrechnen. Oft ist der Rabatt kleiner, als das Risiko wert ist. Dann erübrigt sich die Diskussion.

Meine Haltung

Ich habe nichts gegen das Angebot. Ein Unternehmen darf Daten gegen Geld tauschen, und wer bewusst tauschen will, soll das tun können.

Falsch finde ich die Stelle, an der der Tausch stattfindet. Er steht in einer Preisliste, nicht in einem Vertrag. Er wird von einer Person angeklickt, die das Eigentum nicht besitzt, über das sie verfügt. Und er ist nicht rückholbar: Was einmal im Training ist, kommt dort nicht wieder heraus.

Ein Rabatt gegen Daten ist ein Kaufvertrag. Er sollte auch so aussehen.

Quellen