Muse Wonder Full ist nicht das Modell in der API

Meta hat Muse Wonder und Muse Wonder Full am 12. Oktober 2026 veröffentlicht. Das leistungsfähigere Modell Full gibt es allerdings nicht über die Meta Model API, sondern nur mit einem passenden Muse-Code-Abo. Deshalb lese ich den Release anders: Fulls beste Ergebnisse sprechen für einen Test von Full. Für eine API-Integration brauche ich Belege zum tatsächlich verfügbaren Wonder-Modell. [1] [2]

Lässt sich Muse Wonder Full über die API nutzen?

Nein. Meta Developers sagt ausdrücklich, dass Full nur über Muse-Code-Abos verfügbar ist und die Einstellung max beim normalen Wonder nicht Full auswählt. Das API-Modell heißt muse-wonder-1.0. Full ist eine leistungsfähigere Variante mit einem anderen Zugang, kein anderer Name für Wonders höchste Effort-Stufe. [2]

Diese Unterscheidung ist schon vor jedem Benchmark-Vergleich wichtig. Suche ich ein Modell für einen bestehenden API-Agenten, beginne ich mit der Wonder-Spalte. Suche ich einen Terminal-Agenten und bin zu einem Abo bereit, gehört Full in den Vergleich, zusammen mit den Werkzeugen und Limits von Muse Code.

Das Abo ist außerdem an den Muse-Code-Zugang gebunden, der bei der Einrichtung angelegt wird. Laut Metas Abo-Dokumentation darf dieser Zugang nur für Muse Code verwendet werden. Zusätzliche API-Schlüssel werden separat nach Verbrauch abgerechnet. Ein Abo macht Full also nicht zu einem Modell für beliebige API-Clients. [6]

Das ist hilfreicher, als darin nur eine Wiederholung der Verwirrung um den Release und die Benchmarks von Muse Spark 1.3 zu sehen. Meta dokumentiert die Trennung diesmal klar. Beim Lesen muss man trotzdem jedes Ergebnis dem richtigen Modellnamen zuordnen.

Was zeigen die Benchmarks von Muse Wonder tatsächlich?

Der Abstand zwischen Wonder und Full ist bei einem Coding-Test klein und bei einem anderen größer. Meta Developers veröffentlicht fast identische Ergebnisse für DeepSWE 1.1, während Full auf SWE-Marathon um 4,4 Prozentpunkte vorne liegt. Das spricht dafür, die Aufgaben einzeln zu betrachten, statt jeden Full-Wert als großen Fortschritt zu lesen. [3]

Fulls Vorsprung beträgt auf DeepSWE 0,2 Prozentpunkte, auf SWE-Marathon dagegen 4,4. Ohne Angaben zur Unsicherheit oder wiederholte Durchläufe würde ich aus dem ersten Abstand keinen bedeutsamen Vorteil ableiten. Der zweite gibt mir einen konkreteren Grund, Full bei einem größeren Projekt mit vielen Arbeitsschritten auszuprobieren.

Metas Model Card erklärt, warum die Zeilen einzeln gelesen werden müssen. DeepSWE 1.1 umfasst 113 Aufgaben aus 91 Repositories, die mit Funktions- und Regressionstests bewertet werden. Meta nennt Datacurve als Quelle für die Ergebnisse von Wonder und Full. SWE-Marathon bewertet dagegen umfangreiche Projekte anhand ausführbarer Projekttests; dafür nennt die Model Card Abundant AI als Ergebnisquelle. [4]

Laut derselben Model Card verwenden die Konkurrenzwerte auf SWE-Marathon Produkte wie Codex und Claude Code. Die gesamte Zeile ist deshalb kein kontrollierter Vergleich mit einem gemeinsamen Harness. Der Harness ist die Software um das Modell: Werkzeuge, Anweisungen und Ausführungsschleife. Das entwertet die Ergebnisse nicht, verändert aber die Frage, die sie beantworten. Verglichen werden die getesteten Systeme, ohne die Modellqualität zu isolieren. Das ist dasselbe Problem, das hinter ähnlichen Benchmark-Werten bei unterschiedlichen praktischen Fähigkeiten steckt. [4]

Was kostet die API von Muse Wonder?

Meta Developers nennt für Wonder 4 Dollar pro Million Eingabe-Token ohne Cache, 0,20 Dollar pro Million Eingabe-Token aus dem Cache und 20 Dollar pro Million Ausgabe-Token. Für Wonder gibt es in der API keinen Rabatt über den Contributor-Modus. Die veröffentlichten Preise enthalten auch keinen Aufschlag für langen Kontext. Das sind Wonders Tarife, keine Tokenpreise für Full. [5]

Eine hypothetische Anfrage mit 100.000 Eingabe-Token ohne Cache und 10.000 Ausgabe-Token kostet 0,60 Dollar: 0,40 Dollar für die Eingabe plus 0,20 Dollar für die Ausgabe. Käme die gesamte Eingabe aus dem Cache, kostete dieselbe Tokenmenge 0,22 Dollar. Separat berechnete Werkzeuge und weitere Anfragen sind darin nicht enthalten. Für die Websuche berechnet Meta zusätzlich zu den Tokenkosten 2,50 Dollar pro 1.000 Suchanfragen. [5]

Bei einem Agenten interessiert mich der gesamte Versuch. Wiederholte Werkzeugaufrufe senden mehr Kontext, gescheiterte Ansätze verbrauchen Token, und eine Korrektur kann einen weiteren Durchlauf erfordern. Die Preisliste sagt mir, was die Token kosten. Sie sagt mir nicht, wie viele Wonder braucht, um eine Änderung zu liefern, die ich akzeptieren kann.

Ich würde daher nicht Wonders API-Tarife mit Fulls bestem Ergebnis verbinden und das Ganze ein Schnäppchen nennen. Damit würde ich das Ergebnis eines Modells mit dem Preis eines anderen zusammenbringen. Ebenso wenig würde ich den monatlichen Abopreis durch eine angenommene Zahl an Aufgaben teilen: Das Ergebnis hinge von der tatsächlichen Nutzung und den Tariflimits ab. Der Unterschied zwischen Tokenpreisen und gemessenen Kosten pro Aufgabe zählt auch beim Vergleich mit GPT-6.1 Sol.

Ersetzt Active Memory das Kontextmanagement?

Meta AI Research beschreibt Active Memory als das Behalten relevanter Informationen über Gespräche hinweg. Active Focus bezeichnet dagegen das Weiterarbeiten an einem Ziel trotz Hindernissen und Änderungen. Beides lohnt einen Test. Die Beschreibungen allein sagen aber nicht, wie ein bestimmter API-Agent seinen Projektstand bewahrt. [7]

Die Integration muss weiterhin eine praktische Frage beantworten: Welche Informationen erhält das Modell, wenn die Arbeit fortgesetzt wird? Ein Modell, das eine Anforderung abrufen kann, hilft nur, wenn das System diese Anforderung speichert und die richtigen Informationen bereitstellt. Ich würde das mit einer geänderten Anforderung und einer widersprechenden älteren Notiz testen und prüfen, welcher der Agent folgt.

Deshalb würde ich beim Test von Wonder weiterhin auf explizites Kontextmanagement für Coding-Agenten setzen. Ein großes Kontextfenster und eine angekündigte Gedächtnisfunktion machen die aktuellen Repository-Anweisungen, akzeptierten Entscheidungen und offenen Arbeiten nicht von selbst verständlich. Nützlich ist ein Agent, der mit den richtigen Vorgaben weiterarbeitet, statt bloß einen Satz wiederzugeben.

Wann wäre Full sein Abo wert?

Für mich hätte Full seinen Platz verdient, wenn es schwierige Arbeiten mit weniger Korrekturen abschließt als die über die API verfügbare Alternative. Der größere SWE-Marathon-Abstand gibt mir einen Grund, das bei langen Aufgaben zu testen. Bevor ich dem Modell eine Rolle zuweise, würde ich aber akzeptierte Ergebnisse und verstrichene Zeit messen.

Ich würde mit einer bekannten Repository-Änderung beginnen, denselben Ausgangscommit und dieselben Abnahmetests verwenden und gescheiterte wie erfolgreiche Versuche festhalten. Bei Wonder über die API würde ich Token- und Werkzeugkosten erfassen. Bei Full in Muse Code wären es Abonutzung, Wartezeit und meine anschließenden Korrekturen. So bleibt der Unterschied zwischen dem aufgerufenen Modell und dem abonnierten Produkt erhalten.

Vor einem Test mit privatem Code würde ich außerdem den Contributor-Modus prüfen. Laut Metas Abo-Dokumentation ist er standardmäßig aktiv und erlaubt im Austausch gegen mehr Nutzung das Training mit eingereichten Inhalten. Er lässt sich abschalten; Full bleibt in passenden Tarifen in beiden Modi verfügbar. Diese Entscheidung gehört zum Testaufbau, weil sie die Bedingungen für die Verarbeitung des Codes verändert. [6]

Bei einem beeindruckenden Muse-Wonder-Ergebnis frage ich deshalb zuerst nach dem genauen Modellnamen. Danach kann ich einen Test auswählen, der zu meinem tatsächlichen Zugang passt, und herausfinden, was mich die erledigte Arbeit kostet.