Meta Muse Spark 1.1 im Test: hohe Decke, tiefer Boden

Was ich unter einem Test verstehe, und was ich nicht prüfen konnte

Muse Spark 1.1 erschien am 9. Juli 2026, es ist also seit rund vier Wochen und nicht erst seit vier Tagen im Einsatz. Das ist wichtig. Inzwischen gibt es unabhängige Daten, nicht nur die Stimmung vom Launch-Tag. Das größere Firmenbild steht in meinem Überblick zu Meta AI.

Es gibt weniger Erfahrungsberichte aus erster Hand, als ein Frontier-Launch normalerweise erzeugt, und der Grund ist strukturell. Die Meta Model API startete nur für die USA. Entwickler berichteten, sie seien am ersten Tag blockiert worden aus Vietnam, Kanada und Argentinien, und erst rund eine Woche später landete es auf OpenRouter. Ein Kommentator brachte die praktische Auswirkung auf den Punkt:

„Dass es auf Openrouter nicht verfügbar ist, macht es wirklich schwer zu testen. Ich wollte es mit Grok 4.5 und GPT-5.6 Luna vergleichen, aber ich will mich nicht extra bei Meta dafür anmelden, solange nicht klar ist, ob es sich lohnt.“

mchusma, Hacker News

Ein Launch-Thread mit 413 Punkten brachte also nur eine Handvoll echter Nutzungsberichte hervor. Alles, was folgt, stützt sich auf drei Arten von Quellen: die unabhängigen Läufe von Artificial Analysis, Metas eigenen 105-seitigen Evaluationsbericht und die wenigen Ingenieure, die es tatsächlich zum Laufen gebracht haben. Wo niemand etwas getestet hat, sage ich das, statt die Lücke zu füllen.

Die eine Grafik, die alle anderen Ergebnisse erklärt

Hier ist das Ranking von Muse Spark 1.1 über die Benchmarks, aus denen sich der Intelligence Index zusammensetzt. Gleiches Modell, gleiche Woche, ein Labor führt alle Tests durch.

Die meisten Modelle sind auf nützliche Weise langweilig. Sie liegen ungefähr in demselben Perzentil, egal wo man testet, sodass eine einzelne Zahl den Rest voraussagt. Bei diesem Modell ist das nicht so. Der Abstand zwischen bestem und schlechtestem Rang ist größer als die gesamte Lücke zwischen der Spitze und dem Ende der meisten Preisklassen.

Deshalb sagt die Schlagzeile, die alle wiederholen – 50,6 gegen die 60,7 von Opus 5 – so gut wie nichts aus, worauf man aufbauen kann. Sie mittelt ein exzellentes Ergebnis mit einem schwachen. Was man wirklich wissen muss, ist, welches der beiden man da eigentlich kauft.

Wo es wirklich gewinnt

Drei Dinge sind hier real, und die Kritik weiter unten soll sie nicht unter den Tisch fallen lassen.

Es schreibt gut Code. Nicht „gut für den Preis“. Einfach gut. Bei SciCode schlägt es Claude Opus 5, GPT-5.6 Sol und Grok 4.5. Der Satz „Meta hinkt beim Coding hinterher“, der nach dem Launch die Runde machte, bezieht sich auf lange Agenten-Läufe, nicht auf das Generieren von Code – und das sind zwei verschiedene Jobs.

Es ist das schnellste im Feld. 217,4 Ausgabe-Tokens pro Sekunde gegenüber 55,7 bei Claude Opus 5, und ein Stück vor Gemini 3.6 Flash mit 213,5. Bei allem, was direkt vor dem Nutzer läuft, spürt man einen 4-fachen Durchsatzunterschied, bevor ihn überhaupt jemand misst.

Der Cache-Preis ist der am besten durchdachte Teil des Produkts. Bei 0,15 $ pro Million Tokens ist das ein Rabatt von 88%, automatisch angewendet, ohne dass man einen Cache-Key verwalten müsste. Ein Ingenieur wies darauf hin, warum dieses Verhältnis wichtiger ist als der Listenpreis:

„Die Preise für gecachte Inputs haben ein gutes Verhältnis. Vergleiche das mit Grok 4.5, das mit 2 $/6 $ startete, dann aber still und heimlich 0,50 $ pro 1M gecachte Input-Tokens berechnet. Das ist so hoch wie bei Opus 4.8!“

Aurornis, Hacker News

Setzt man das zusammen, ergibt sich der gute Anwendungsfall von selbst: kurze Prompts, ein stabiler System-Prompt, riesiges Volumen, eine Entscheidung pro Aufruf. Batch-Klassifizierung, Tagging, Extraktion, Routing. Die vollständige Preistabelle steht in meiner Aufschlüsselung zu den Preisen von Muse Spark 1.1. Für den Rest des Felds lohnt sich der Start bei den Claude-Preisen. Die OpenAI-Modellreihe steht in einer einzigen Tabelle unter alle OpenAI-Modelle.

Wo es auseinanderfällt

Meta hat das hier als Agenten-Modell positioniert. Die Ankündigung stellt Tool-Nutzung und mehrstufige Workflows in den Vordergrund – genau die Linie, die Agenten von Chatbots trennt. Der faire Test sind also die unabhängigen agentischen Evaluationen. Hier dreht sich der Test.

Der Widerspruch ist kaum zu übersehen. Das Modell, das über agentische Tool-Nutzung verkauft wird, ist im unabhängigen Feld der schwächste agentische Performer. Bei GDPval liegt es 481 Elo hinter Opus 5, und die Konfidenzintervalle überschneiden sich mit nichts darüber. Bei agentischer Tool-Nutzung liegt es sogar hinter DeepSeek V4 Flash, das 0,14 $ pro Input und 0,28 $ pro Output kostet.

Meta bestreitet das nicht vollständig. Der eigene Evaluationsbericht räumt ein, dass „bei agentischen Aufgaben mit langem Zeithorizont (z. B. DeepSWE und DeepSearchQA) signifikante Verbesserungen weiterhin hinter den leistungsstärksten Konkurrenzmodellen zurückbleiben oder mit ihnen gleichauf liegen“. Dieses Eingeständnis misst sich an Opus 4.8 und GPT-5.5, beide eine Generation hinter dem, was man heute kaufen würde.

Die Einschätzung der Community ist ungefähr an derselben Stelle gelandet. Ein Kommentator, der es nahe der Spitze eines Coding-Leaderboards auftauchen sah, nahm das als Beweis dafür, dass das Leaderboard kaputt sei:

„euer Benchmark ist offensichtlich kaputt, wenn die Top-3-Modelle für Typescript (Combined) Grok 4.5, Muse Spark 1.1 (lol), Gemini 3.5! Flash sind“

eis, Hacker News

Die schärfste Einordnung kam aus einem Vier-Modelle-Vergleich. Jemand dort war verwirrt, dass Muse Spark das beste einzelne Artefakt im Set produzierte und trotzdem nur 2 von 5 Punkten bekam. Die Klarstellung fasst das ganze Modell in einem Satz zusammen:

„2/5 ist keine Qualitätsangabe, sondern Konsistenz, so wie es dort steht. Die vollständigen Links stehen unten. Die meisten Versuche von Spark sind Fehlschläge“

rsstack, Hacker News

Hohe Decke. Tiefer Boden. Alles andere in diesem Test folgt daraus.

Die längste einzelne Sitzung, die bisher jemand veröffentlicht hat, kommt zum selben Ergebnis. Drei Stunden mit dem Modell, von einem Entwickler, der es über eine Coding-CLI laufen ließ:

„Ich habe es gerade 3 Stunden am Stück ausprobiert, und ich muss sagen, ich bin enttäuscht. Ich weiß nicht, was mit Meta in letzter Zeit los ist, aber man sollte bedenken, dass sie der Llama-Schöpfer waren, der die Open-Source-Welle bei Modellen ausgelöst hat. Selbst closed source (zumindest jetzt) würde ich sagen, liegt es zwischen Kimi 2.7 und GLM 5.2, nicht mal ansatzweise auf dem Niveau von Opus 4.8 medium/Sonnet5“

u/FBIFreezeNow, Reddit

Das sollte man nicht überbewerten. Es ist der Nachmittag einer einzelnen Person, und er nennt keine gemessenen Zahlen. Das tut kaum jemand. Über vier Wochen Reddit und Hacker News hinweg gibt es ungefähr ein Dutzend echte Erfahrungsberichte aus erster Hand zu diesem Modell, und keiner davon veröffentlicht eine selbst gemessene Zahl. Auch hat niemand das 1-Millionen-Token-Fenster öffentlich einem Stresstest unterzogen. Teils wegen der Region-Sperre, teils weil ein Modell, für das man keinen API-Key bekommt, von Hobbyisten nicht benchmarkt wird.

Der Fehlermodus, den Meta selbst dokumentiert

Das ist der Teil, den ich kennen möchte, bevor ich es in irgendetwas einbaue. Er steckt in der Dokumentation, nicht im Launch-Post.

Muse Spark 1.1 hält seine Denkkette privat, was heute normal ist. Ungewöhnlich ist, was auf dem gängigsten Integrationsweg passiert. Metas eigene Reasoning-Dokumentation besagt, dass bei Chat Completions das Feld reasoning_content geschwärzt und leer geliefert wird, bevor die Antwort den Aufrufer erreicht, „sodass es nichts zum Wiederabspielen gibt und jeder Turn wieder bei null anfängt zu denken“.

Metas Leitfaden für Coding-Agenten benennt die Konsequenz klar: Das Modell „kann den Faden seines eigenen früheren Denkens verlieren und sich fehlerhaft verhalten: Arbeit wiederholen, die es schon erledigt hat, früheren Schritten widersprechen“.

Ein Modell, das über mehrstufige agentische Arbeit verkauft wird, vergisst sein eigenes Reasoning zwischen den Turns auf dem Weg, den die meisten Tools standardmäßig nutzen. Reasoning über mehrere Turns hinweg übersteht nur die Responses API, bei der der Server den Kontext über previous_response_id für einen behält.

Nichts davon ist theoretisch. Der beste Praxisbericht seit dem Launch beschreibt genau diese Art von Problem, und er stammt von einem Ingenieur, der Codex innerhalb eines Containers gegen die API zum Laufen gebracht hat:

„Es ist irgendeine Art von Parsing- oder Integrationsfehler, wahrscheinlich weil Codex serverseitiges Tool-Calling und wie meta mit diesen IDs umgeht nicht antizipiert... bei den ersten paar Malen, wo ich Codex mit muse ausgeführt habe, ist es beim ersten Aufruf, der keine Websuche war, fehlgeschlagen.“

weitendorf, Hacker News

Er hat es behoben und blieb dem Modell gegenüber positiv eingestellt. Der Punkt ist, dass zwei unabhängige Quellen – Metas eigene Doku und die erste Person, die es in ein echtes Harness eingebaut hat – bei derselben Grundursache landen. Die agentische Verdrahtung ist maßgeschneidert, und Harnesses von Drittanbietern stolpern darüber.

Die Halluzinationszahl, die alle zitieren, ist die falsche

An dieser Stelle muss ich eine schmeichelhafte Lesart korrigieren, die kursiert – meine eigene frühere Berichterstattung eingeschlossen.

Muse Spark 1.1 hat tatsächlich eine gute Nicht-Halluzinations-Rate, das heißt, es verweigert eine Antwort recht häufig, statt sich etwas auszudenken. Das stimmt und ist etwas wert. Aber der zusammengesetzte Wissenszuverlässigkeitsindex, der richtige Antworten belohnt und Halluzinationen bestraft, setzt es bei 18,0 an. Das ist der niedrigste Wert unter den zwölf Konfigurationen auf der eigenen Modellseite. Claude Opus 5 erreicht 31,3.

Metas eigene Alignment-Tests bestätigen das, mit deutlicheren Worten, als sie je ein Wettbewerber veröffentlicht hat. Aus der Petri-3.0-Bewertung im Evaluationsbericht: „Input-Halluzination (1,67) ist die wichtigste, höher als GPT-5.5 (1,22) und Claude 4.8 Opus (1,34).“ Dieselbe Passage nennt zudem erhöhte Täuschung gegenüber Nutzern und erhöhte Überverweigerung.

Zwei unabhängige Quellen, eine davon Meta selbst, landen also bei derselben Schlussfolgerung: Halluzination ist die schwächste Dimension dieses Modells, nicht die stärkste.

Doch selbst das ist nicht die Zahl, an der ich eine Support-Einführung festmachen würde. Das hier schon:

Jeder Halluzinations-Benchmark misst, ob ein Modell Fakten über die Welt erfindet. Kaum ein Support-Fehler sieht so aus. Ein B2B-Technical-Support-Team, mit dem wir zusammengearbeitet haben und das etwa 200 Tickets pro Monat auf Zendesk bearbeitete und in Richtung 2.000 skalierte, ist auf die echte Version des Problems gestoßen. Der Bot sagte Kunden, er unterstütze Fahrzeuge, die gar nicht in der Datenbank standen, weil das eigene Helpcenter geschrieben hatte: „Wir unterstützen alle Modelle.“ Das Modell war seiner Quelle treu. Die Quelle war falsch.

Kein Score auf keinem Leaderboard fängt das ab. Deshalb ist das Trainieren von KI auf einer Wissensdatenbank zuerst ein Content-Problem und erst danach ein Modell-Problem, und deshalb bringen Confidence-Schwellenwerte mehr für die Antwortqualität als jedes Reasoning-Upgrade.

Dieselbe Logik gilt weiter oben in der Kette. Eine saubere Ticket-Triage bewegt die Lösungsquote zuverlässiger als ein Modellwechsel. Die Fehlermuster sind konsistent genug, dass KI-Chatbot-Probleme sie besser katalogisiert als jede Modellkarte.

Die Geschwindigkeit ist real – aber achte auf die richtige Uhr

Die Durchsatzzahl ist real, und sie ist die beste Einzelkennzahl des Modells. Die Latenzzahl braucht eine Korrektur.

Metas rohe 2,89 s für die Zeit bis zum ersten Token sind der beste Wert im Feld. Das erlebt ein Nutzer aber nicht so. Zählt man die 9,2 Sekunden verstecktes Reasoning dazu, kommt das erste tatsächlich nützliche Token erst nach 12,09 s an. Immer noch klar besser als Opus 5, die Schlussfolgerung bleibt also bestehen. Trotzdem viermal langsamer, als es die Schlagzeile suggeriert.

Genau dieses versteckte Reasoning treibt auch die Kostenstory. 68% der abgerechneten Ausgabe-Tokens sind Denkarbeit, die der Aufrufer nie zu sehen bekommt, mit 15.164 Reasoning-Tokens gegenüber 7.232 Antwort-Tokens pro Aufgabe. Beim vollständigen Index-Lauf von Artificial Analysis flossen 360 $ von insgesamt rund 548 $ ins Reasoning. Billige Tokens, teure Denkgewohnheit. Das ist der Grund, warum die Kosten für KI-Kundenservice sich nie an der Preistabelle orientieren.

Vier Fallstricke, die man vorher kennen sollte

Keiner davon ist ein Dealbreaker. Jeder kostet einen Nachmittag, wenn man kalt darauf stößt.

1. tool_choice akzeptiert nur "auto". Man kann kein bestimmtes Tool erzwingen, und es gibt kein "required" oder "none". Alles andere kommt als 400 zurück.
2. Strukturierte Ausgabe ist standardmäßig deaktiviert. Unter strict: false warnt Metas Referenz für Tool-Calling, dass generierte Argumente „nicht garantiert gegen“ das Schema validieren. Vor jeder Ausführung validieren.
3. Claude Code braucht drei separate Änderungen. Eine Basis-URL ohne /v1, alle fünf Modell-Aliase umgeleitet auf muse-spark-1.1, dann ANTHROPIC_AUTH_TOKEN statt ANTHROPIC_API_KEY.
4. MCP wird behauptet, aber nicht dokumentiert. Der Launch-Post sagt, das Modell verallgemeinere auf MCP-Server und benutzerdefinierte Skills. Die Referenz für Tool-Calling dokumentiert keines von beiden. Vom Entwickler definierte Tools sind der einzige tatsächlich gezeigte Erweiterungsweg.

Es gibt außerdem keine serverseitige Obergrenze für außer Kontrolle geratene Custom-Tool-Schleifen. max_tool_calls begrenzt nur Metas eingebaute Tools – wichtig zu wissen, wenn man schon mal beobachtet hat, wie ein KI-Agenten-Loop sich im Kreis dreht. Die Delegations-Seite davon wird in Subagent-Orchestrierung behandelt, und das Argument, es selbst zu testen, steht bei Agenten-Evaluierungen.

Was Meta immer noch nicht veröffentlicht hat

Lücken sind ebenfalls Teststoff, und diese Liste ist vier Wochen nach dem Launch länger, als sie sein sollte.

Meta erscheint auch nicht im offiziellen Terminal-Bench-Leaderboard, sodass der dort selbst gemeldete Score keine Bestätigung durch Dritte hat. Mein Überblick zu Muse Spark 1.1 behandelt den methodischen Streit um diese Zahl. Er ist weiterhin ungeklärt.

Wer es kaufen sollte – und wer es lieber lässt

Kauf es, wenn du hochvolumige Arbeit mit kurzem Zeithorizont hast: Klassifizierung, Tagging, Extraktion, Routing, Codegenerierung in einer einzelnen Datei – alles, wo ein Aufruf eine Antwort erzeugt und man Millionen dieser Aufrufe macht. Die Geschwindigkeit ist real, der Cache-Preis ist exzellent, und bei rund 0,29 $ pro Aufgabe ist die Ersparnis gegenüber den Opus-5-Preisen groß genug, um zu zählen.

Lass es lieber, wenn dein Workload aus langlebigen Agenten, Deep-Research-Läufen oder allem besteht, was über einen großen Dokumentensatz hinweg denken muss. Die unabhängigen agentischen Zahlen liegen nicht ansatzweise nah beieinander. Das ist einer der wenigen Fälle, in denen GPT-5.6 oder Opus 5 am Ende günstiger sind, sobald man die Wiederholungsversuche mitzählt. Speziell für Coding-Harnesses ist Codex heute der besser dokumentierte Weg.

Warte, wenn du außerhalb der USA bist, eine veröffentlichte Retention-Policy brauchst oder offene Gewichte brauchst. Beim letzten Punkt ist Kimi K3 die nächstgelegene Near-Frontier-Option mit Gewichten, die man wirklich in der Hand halten kann. Der Wechsel zu geschlossenen Gewichten ist der Teil dieses Launches, den die Community am wenigsten verziehen hat.

Die moderate Einschätzung von jemandem, der das Leaderboard verfolgt, ist fair genug, dass ich sie unterschreiben würde:

„Neuer Respekt für Meta Muse Spark. Es scheint an vielen Sweet Spots im Leaderboard zu liegen. Es ist bei nichts Bestimmtem das Beste, aber es balanciert Kosten und Leistung ziemlich gut aus.“

drob518, Hacker News

Was das für eine Support-Warteschlange ändert

Fast nichts. Das sage ich als jemand, dessen Job auch darin besteht zu bemerken, wenn ein neues Modell tatsächlich etwas ändert.

Alle paar Wochen erscheint ein günstigeres, schnelleres Modell, und jemand fragt, ob das den Plan für den eigenen Helpdesk neu schreibt. Die ehrliche Antwort: Das Modell war nie die Beschränkung. In eesels eigenen kreuzvalidierten Tests waren, wenn Agenten einen KI-Entwurf umgeschrieben haben, etwa 65% der Änderungen Länge und Tonfall. Rund 20% brauchten Daten, auf die die KI in einem ERP- oder Logistiksystem nicht zugreifen konnte. Nur etwa 5% waren tatsächlich faktische Fehler der KI. Ein besseres Modell adressiert genau diese letzten 5%. Der Rest sind Prompt Engineering, Retrieval, Agenten-Coaching anhand der eigenen, tatsächlich versendeten Antworten des Teams und Integrationstiefe.

Das ist auch der Grund, warum Copilot-artiges Entwerfen der Punkt ist, an dem die meisten Teams anfangen sollten – das Muster hinter Agent-Assist-Tools – und warum ein sauberer Eskalationspfad wichtiger ist als eine Leaderboard-Position. Wer den Business Case statt den Stack aufbaut, findet in KI vs. menschliche Kosten den nützlicheren Rahmen.

Der Fehler, auf den ich in der Produktion am schärfsten achte, ist der, den kein Benchmark auf Metas Launch-Seite misst. Ein Agent, der eine Suche erzählt, die er nie ausgeführt hat. Der Dateien meldet, die er nie gespeichert hat. Ein Agent, der behauptet, die Arbeit erledigt zu haben, ist ein schwierigeres Problem als ein Agent, der die Arbeit schlecht erledigt, und einem Modell, das sein eigenes Reasoning zwischen den Turns vergisst, würde ich nicht vertrauen, sich selbst korrekt zu berichten.

Probiere eesel für den Support, nicht nur einen rohen Modell-Key

Wenn du eigentlich eine KI willst, die Kundentickets beantwortet, hat die relevante Frage wenig damit zu tun, welches Modell diesen Monat den Index anführt. Sie lautet: Kannst du beweisen, dass die Sache sicher ist, bevor sie irgendjemandem antwortet?

Genau darum ist eesel gebaut. Du kannst einen KI-Agenten in Simulation gegen deine eigenen historischen Tickets laufen lassen und seine Antworten auf echten vergangenen Konversationen lesen, bevor ein einziger Kunde eine davon sieht. Sind die Antworten noch nicht so weit, startest du im Copilot-Modus, in dem entworfen wird und dein Team weiterhin selbst sendet.

Das Setup ist eine Helpdesk-Verbindung, kein Projekt. Es dockt in wenigen Minuten an Zendesk an, liest das Helpcenter, das du bereits geschrieben hast, und rechnet pro gelöstem Ticket ab statt pro Million Tokens, sodass die Rechnung die geleistete Arbeit widerspiegelt und nicht, wie gesprächig das Modell an einem bestimmten Tag gerade war. Kostenlos zu testen, und die Preise sind öffentlich.

Das Fazit

Muse Spark 1.1 ist ein gutes Modell mit dem falschen Etikett. Meta hat einen Agenten verkauft, und die Agenten-Benchmarks sind seine schlechtesten Ergebnisse. Nach den Belegen ist es derzeit das beste schnelle und günstige Ein-Schuss-Modell auf dem Markt, mit einer starken Codegenerierungs-Punktzahl und einem Cache-Preis, den sonst niemand erreicht.

Beurteilt man es nach dem eigenen Job statt nach der Kategorie, in die Meta es einsortiert hat, lässt es sich leicht einordnen. Kauf es für die Millionen kurzen Aufrufe. Halte für die langen Läufe etwas Stärkeres bereit. Und lass dich von einem 1M-Token-Fenster nicht davon abbringen, auf Retrieval zu setzen. Bei rund einem Achtel der Kosten pro Aufgabe im Vergleich zu Opus 5 ist es ein völlig solides Geschäft, bei den richtigen Jobs die zweitbeste Wahl zu sein.