Muse Spark 1.3 Tutorial: Ein praxisnaher Guide für Developer

Meta hat Muse Spark 1.3 am 2. September 2026 veröffentlicht, und das Upgrade passt in eine Zeile: Ändere die Model-ID. Bedeutet: gleiche Endpunkte, gleiches Software Development Kit (SDK), gleiche Preise.

Laut Meta erhältst du durch diese Ein-Zeilen-Änderung ein Modell, das dieselbe Aufgabe mit rund 20% weniger Tool-Aufrufen und 25% weniger Tokens als Muse Spark 1.2 erledigt. Diese Zahlen stammen aus Vergleichen von Metas eigenen Engineers, auf nicht benannten Aufgaben, ohne Methodik-Write-up.

Genau solche Aussagen prüfe ich lieber selbst, bevor ich sie weitergebe. 

Also habe ich Muse Code installiert, ein echtes Open-Source-Projekt absichtlich kaputt gemacht und auf beiden Modellen dieselben drei Aufgaben laufen lassen.

Um diesem Muse-Code-Tutorial zu folgen, brauchst du ein Meta-Developer-Konto, ein Terminal, in dem du dich wohlfühlst, und macOS oder Linux für den Muse-Code-Agenten. Windows-Nutzer gehen in der aktuellen Beta noch leer aus.

Kurz zusammengefasst

• Muse Spark 1.3 ist Metas Flaggschiff für multimodales Reasoning, erschienen am 2. September 2026, mit einem Kontextfenster von 1 Mio. Tokens.
• Muse Code startet standardmäßig mit muse-spark-1.3-contributor. Das bedeutet: Meta trainiert mit deinem Code, sofern du nicht umstellst. Training ist Opt-out, nicht Opt-in.
• Über 6 Läufe auf 3 Coding-Aufgaben war 1.3 bei 2 günstiger und bei der dritten 38% teurer, netto ein Kostenplus von 12% über das Set.
• Model-Completions sanken um 23% und 32% bei den 2 Aufgaben, auf denen 1.3 gewann, was Metas Tool-Call-Aussage stützt. Ungecachter Input sank auf allen 3, aber nie um 25%.
• Die Reasoning-Stufe ultra existiert in CLI und Session-Picker, aber das Backend verweigert sie mit einem benannten Feature-Gate.

Was ist Muse Spark 1.3?

Muse Spark 1.3 ist Metas Flaggschiff für multimodales Reasoning, veröffentlicht von den Meta Superintelligence Labs am 2. September 2026 und ausgelegt für lange agentische Sessions sowie Coding über große Repos. Es hält 1.048.576 Tokens Kontext und akzeptiert Text, Bilder, Video und Dateien.

Sechs Dinge haben sich gegenüber Muse Spark 1.2 geändert:

• Effizienz. Etwa 20% weniger Tool-Aufrufe und 25% weniger Tokens in Metas internen Vergleichen.
• Zusammenarbeit. Es stellt Rückfragen bei vagen Prompts und holt Bestätigung vor folgenreichen Aktionen ein.
• Multitasking in einem Thread, sodass eine Nachricht mitten im Flow an die richtige Aufgabe andockt.
• Lange Anweisungen befolgen, mit weniger verlorenen Constraints über mehrere Schritte.
• Bessere Kalibrierung bei irreversiblen Aktionen.
• Sauberer Coding-Stil. Weniger unnötige Turns, weniger Geschwätzigkeit.

Alles klingt gut, aber Metas veröffentlichte Scorecard vergleicht Muse Spark 1.3 mit max Reasoning gegen Muse Spark 1.2 mit xhigh, und max war zum Launch weiterhin gegated. 

Artificial Analysis bewertete die ausgelieferte xhigh-Variante mit Intelligence Index 61 und max mit 62. Also nur ein Punkt Unterschied.

Matt Crabtree hat Benchmarktables, Preisaufschlüsselung und den Vergleich mit GPT-5.6 Sol und Claude Opus 5 bereits in seiner Muse Spark 1.3 Release-Analyse abgedeckt. Ich wiederhole das nicht. Im Folgenden geht es darum, was passiert, wenn du das Ding installierst und ans Laufen bringst.

So kommst du an Muse Spark 1.3

Es gibt drei Wege, und der richtige hängt davon ab, was du baust. Wähle aus der Tabelle und spring dann zum passenden Abschnitt.

Muse Code, der Terminal-Agent

Muse Code ist Metas Terminal-Coding-Agent, in der Beta für macOS und Linux. Es ist das Harness, das Muse Spark ausführt, und beide versionieren unabhängig. muse --version sagt dir daher nichts darüber, mit welchem Modell du sprichst. Halte das im Kopf getrennt.

curl -fsSL https://dev.meta.ai/install.sh | bash

Das lädt ein 230 MB Binary und legt es unter ~/.local/bin/muse ab, was nicht bei jedem im PATH liegt. 

Dann prüfen, was installiert wurde:

muse --version

Am 4. September 2026 bekam ich Muse Code 1.0.2 (1.0.2-R2040.1) zurück. 

Für eine Beta etwas merkwürdig, denn Drittools dokumentierten Muse Code noch Wochen zuvor als 0.2.1. Pinne die Version, die du bekommst, auf das Datum.

Screenshot von der Autorin/dem Autor. Muse Code mit dem Einzeiler installieren und anschließend Version 1.0.2 auf macOS bestätigen.

Jetzt muse starten. Beim ersten Mal druckte es Not logged in. Run muse again to log in. und beendete sich. Also startest du es zweimal – genau die Art kleiner Stolperstein, bei der man denkt, die Installation sei schiefgegangen.

Beim zweiten Lauf startet ein OAuth-Device-Flow. Es druckt eine Anmelde-URL mit Kurzcode, zeigt denselben Code separat und bittet dich zu bestätigen, dass sie übereinstimmen, bevor du im Browser freigibst.

Sign in at this page:
  https://auth.meta.com/oauth/device/?code=XXXX-XXXX
confirm this code matches:
  XXXX-XXXX

Waiting for approval…

Dann solltest du folgende Ansicht sehen: 

Screenshot von der Autorin/dem Autor. Der Anmeldeflow der Meta Model API, Bestätigung der Accountdaten vor der Ausgabe von Credentials. 

Im Browser bestätigst du deinen Namen, akzeptierst die Bedingungen und hinterlegst eine Karte. Lies die Preistafel auf diesem Zahlungsbildschirm, statt einfach weiterzuklicken – warum, wird in etwa dreißig Sekunden klar.

Das Standard-Tier trainiert mit deinem Code

Zurück im Terminal verrät dir der Sitzungsheader, was läuft:

Muse Code 1.0.2
You are logged in.
Model set to muse-spark-1.3-contributor
└ Discounted tokens: your content, including inter-session messages, may be
  used for product improvement.

Lies den Modellnamen noch mal. Die Contributor-Variante, als Default gesetzt, bei einer frischen Installation, ohne Nachfrage.

Meta versteckt das nicht. Der Hinweis steht unter dem Modelnamen, der Zahlungsbildschirm markiert Contributor als DEFAULT, und die Statusleiste hält muse-spark-1.3-contributor während der Arbeit sichtbar. 

Aber die Last ist invertiert gegenüber dem, was die meisten Developer erwarten.

Wenn du Muse Code in einem Kunden-Repo öffnest und loslegst, hast du diesen Code bereits an einen für Training berechtigten Endpunkt gesendet. Prüfe die Statusleiste vor deinem ersten Prompt, nicht danach.

Screenshot von der Autorin/dem Autor. Eine erste Muse-Code-Session, mit Default-Modell muse-spark-1.3-contributor und dem Hinweis zur Produktverbesserung darunter.

Die Statusleiste zeigt auch den Reasoning-Effort, bei mir high. Nicht xhigh, die Variante, die Artificial Analysis benchmarkte. Das ist wichtig, wenn du deine Ergebnisse mit veröffentlichten Zahlen vergleichst.

Tiers auswählen und wechseln

Mit /model bekommst du einen interaktiven Picker mit vier Optionen und deren Preisen. Diese Werte entsprechen Metas Zahlungsbildschirm:

Contributor ist beim Input etwa 12-mal günstiger und beim Output 21-mal günstiger.

Den Rabatt kaufst du mit deinem geistigen Eigentum (IP). Metas Formulierung: "your content, including inter-session messages, may be used for product improvement" – das umfasst mehr als nur den Code, den du übergibst.

Beide Muse-Spark-1.2-Varianten sind im Picker weiterhin zu identischen Preisen gelistet, was für den späteren Vergleich zählt: Da die Tarife zwischen Generationen nicht wechseln, ist ein Token-Vergleich zugleich ein Kostenvergleich ohne Normalisierung.

Screenshot von der Autorin/dem Autor. Der /model-Picker zeigt alle vier Muse-Spark-Varianten mit Preisen für Cache, Input und Output.

Zum Opt-out einfach zu muse-spark-1.3 hochspringen und Enter drücken. Die Zeile "Discounted tokens" verschwindet aus dem Header.

Für Kundenprojekte gibt es eine stärkere Option, die nie im Terminal auftaucht. Meta sagt, es habe Zero-Data-Retention-Anfragen angenommen – via Sales statt Schalter. 

Retention und Training sind getrennte Fragen, und Agenturverträge brauchen in der Regel beides klar beantwortet.

Rate Limits unterscheiden sich zwischen den Tiers, auch wenn Quellen uneins über das Wie sind. Metas Developer-Blog beschreibt das Contributor-Tier als durch Tokens in einem rollierenden 5-Stunden-Fenster gedeckelt statt durch Request-Zahl. Berichte zum 1.2-Launch nannten hingegen 60 Requests pro Minute – ein völlig anderer Mechanismus. Ich traf keinen der Limits über rund 90 Model-Completions an einem Nachmittag.

Die Meta Model API und OpenRouter

Die Meta Model API ist kompatibel zum OpenAI SDK, daher heißt Migrieren: Model-ID wechseln, Client-Code behalten. Model-IDs sind muse-spark-1.3 und muse-spark-1.3-contributor.

OpenRouter führt es unter dem Slug meta/muse-spark-1.3. Das kostet dich: OpenRouter maß rund 81 Tokens/Sekunde gegenüber den 182, die Artificial Analysis direkt gemessen hat, mit einer Verfügbarkeit von etwa 92% über die ersten drei Tage. Meta ist alleiniger Provider, es gibt also keinen Fallback.

Deine erste Muse Spark 1.3 Session

Alles unten läuft gegen python-humanize/humanize, gepinnt auf Commit 823ad6096. Es sind 1.676 Zeilen Source über 6 Module, die Testsuite läuft in unter einer Sekunde, und die Domäne erklärt sich von selbst. Nichts davon modifiziert das Repo. 

Das sind Read-only-Fragen, um zu sehen, wie der Agent eine Codebasis erkundet, bevor ich ihm etwas zum Schreiben gebe.

Zwei Prompts, um ein Gefühl dafür zu bekommen, wie er Code liest. Starten wir mit dem ersten: 

Map the dependency graph of this project and tell me which module has the most inbound imports.

Es führte zwei Kommandos aus, listete die Struktur und schrieb dann einen AST-Parser statt einfach nach import zu greppen. Antwort: i18n mit 4 eingehenden Imports, aufgeschlüsselt in i18n 4, number 2 sowie filesize, lists, time und _version je 1.

Ich prüfte mit meinem eigenen Script und bekam andere Zahlen, was nach einem Treffer aussah. Mein Script lag falsch. Es zählte nur relative Imports (from ._version import ...) und übersah die absolute Form (from humanize.i18n import ...), die in diesem Package meist genutzt wird. Das Modell konnte beides.

Der zweite Prompt lohnt sich, weil du ihn bewerten kannst:

List every public function in src/humanize, grouped by module, with a count per module.

Antwort: 20 insgesamt – filesize 1, i18n 5, lists 1, number 8, time 5. Alles korrekt. Dann ergänzte es ungefragt, dass i18n.get_translation zwar öffentlich benannt ist, aber in i18n.__all__ fehlt, das nur die anderen vier exportiert. Ebenfalls korrekt.

Diese Session kostete $0.01 über 8 Turns.

Die Reasoning-Stufe, über die Meta nicht spricht

muse --help führt Folgendes auf:

--reasoning-effort <EFFORT>
    Meta reasoning effort: none|minimal|low|medium|high|xhigh|ultra
    (default: high)

Der In-Session-/effort-Picker bietet sechs der sieben an und lässt none weg. 

Screenshot von der Autorin/dem Autor. Der /effort-Picker listet sechs auswählbare Reasoning-Level, high ist aktuell.

Beide nennen ein Level namens ultra, das in keiner Meta-Ankündigung auftaucht. Metas öffentliche Position ist, dass max Reasoning "kurz nach Abschluss zusätzlicher Sicherheitstests" kommt.

Also habe ich es angefordert:

muse exec --model muse-spark-1.3-contributor --reasoning-effort ultra 'Reply with exactly: ok'

tbh: reasoning effort ultra is not available (gate ultra_reasoning_effort is closed); using xhigh

Es gibt ein benanntes Feature-Gate, ultra_reasoning_effort, und es ist zu. Die Fähigkeit ist gebaut, der Schalter ist serverseitig aus. Das ist präziser als "pending safety testing" – und kommt in einer Warnung, die auch "tbh" enthält.

Zwei praktische Punkte. Der Client bewirbt ein Level, das das Backend nicht liefert – in CLI und Picker. Und er stuft still auf xhigh herunter, nur mit einer einzelnen Zeile stderr, die in Skripten oder CI-Logs leicht untergeht. Du würdest glauben, du läufst eine Konfiguration, die gar nicht aktiv war.

Dann probierte ich einen Wert, der in keiner Doku steht:

muse exec --model muse-spark-1.3-contributor --reasoning-effort max 'Reply with exactly: ok'

Keine Warnung. Es lief und gab ok zurück. Ein undokumentierter Wert passiert die Validierung ohne Kommentar, während ein dokumentierter gegated ist – und du kannst dem Output nicht entnehmen, welches Effort-Level deine Anfrage tatsächlich bedient hat.

Screenshot von der Autorin/dem Autor. Ultra anfordern liefert ein geschlossenes Feature-Gate und ein stilles Downgrade auf xhigh, während das undokumentierte max ohne Kommentar durchgeht.

Wenn dir das Reasoning-Level wichtig ist, setze es explizit und lies stderr. Verlass dich nicht darauf, dass der gesetzte Flag auch tatsächlich genutzt wurde.

Hält das Effizienzversprechen von Muse Spark 1.3?

Hier der Test. Nimm ein Open-Source-Repo, rolle einen echten Bugfix-Commit zurück, sodass die Tests wirklich fehlschlagen, und führe drei Coding-Aufgaben auf beiden Modellen mit denselben Prompts und Flags aus.

Diese sind getrennt von der Erkundungssession oben. Jede davon schreibt Code.

Das Zurückrollen des Source-Teils von Commit 823ad6096 bei Beibehalt seiner Tests lässt 6 Tests fehlschlagen – Startzustand:

git checkout 823ad6096e1e5ba82ea876ce761fc2efebd76157
git show 823ad6096 -- src/humanize/filesize.py | git apply -R -
python -m pytest tests/test_filesize.py -q

Jeder Lauf nutzte dieselbe Befehlsform, nur Model-ID und Prompt wechselten:

muse exec \
  --model muse-spark-1.3-contributor \
  --reasoning-effort high \
  --no-parallel-tool-calls \
  --approval-mode never \
  'PROMPT GOES HERE'

Aufgabe 1, Bugfix. 

Erfolg ist binär: Die 6 Tests laufen grün, oder nicht. 

The test suite tests/test_filesize.py is failing. 
Fix the source code in src/humanize/ so that all tests pass. 
Do not modify any file in tests/.

Aufgabe 2, kleines Feature.

Genug offen, dass die beiden Modelle über den Scope uneins sein können – was relevant wurde.

Add a function called natural_list_with_limit to src/humanize/lists.py. 
It formats a list but truncates after a given number of items, appending "and N more". 
Export it from the package and add tests.

Aufgabe 3, Refactor.

Die schwerste der drei, greift mehrere Dateien an.

src/humanize/number.py is 571 lines. 
Split it into two modules along a sensible boundary, 
update all imports across the package, and make sure the full test suite still passes.

Die drei Aufgaben liefen nacheinander ohne Reset, sodass Aufgaben 2 und 3 auf dem aufsetzten, was das Modell zuvor erzeugt hatte. Beide Modelle gingen denselben Weg.

Token-Zahlen stammen aus den Session-Logs unter ~/.local/share/muse/sessions/, einmal pro Model-Completion gezählt. Alle sechs Läufe bestanden ihre Tests.

Und die Deltas, wobei negativ heißt, dass 1.3 weniger verbraucht hat:

Das Ergebnis nüchtern lesen

Zwei von drei Aufgaben waren günstiger, mit 23% und 32% weniger Model-Completions. Das passt zu Metas Tool-Call-Claim. Dann lief das Refactoring andersherum: 70% mehr Completions und 38% mehr Kosten.

Über alle drei hinweg kostete 1.3 insgesamt 12% mehr als 1.2. Das Effizienzversprechen ist also real, aber aufgabenabhängig – eine einzelne Prozentzahl verschleiert das komplett.

Ungecachter Input sank bei jeder Aufgabe um 19%, 22% und 5%. Nie um 25%. 

Meta sagt nicht, welche Tokens gezählt wurden – und je nachdem, ob du Input, Output, ungecacht oder total meinst, ändert sich die Antwort deutlich.

Cache-Hit-Raten lagen bei 88% bis 97% und stiegen mit der Aufgabenlänge. Rohe Input-Tokens zu berichten, ohne Cache vs. Uncache zu trennen, wäre nahezu sinnlos, denn die 4,18 Mio. Input im Refactor sind in Wahrheit 109k neuer Kontext plus 4,07 Mio. Re-Reads, die zum Fünfzigstel berechnet werden.

Warum das Refactoring kein klarer Verlust ist

Schau dir an, was 1.3 bei dieser Aufgabe tatsächlich getan hat, bevor du es als ineffizient abstempelst.

Es hat jedes verschobene Blockstück programmatisch Byte-für-Byte mit dem Original verifiziert. 

Es lief mit --doctest-modules auf beiden neuen Dateien. Es testete Import-Resolution aus einem Wegwerfverzeichnis in /tmp. Dann markierte es zwei Dinge, nach denen niemand gefragt hatte: dass die Funktion humanize.scientific das neue Submodul überschattet, und dass ein naturaldelta-Doctest auf dem unveränderten Baum identisch fehlschlägt, der Fehler also nicht an der Änderung liegt.

Muse Spark 1.2 duplizierte eine Helper-Funktion, um einem zyklischen Import auszuweichen, und machte weiter. 1.3 importierte sie und erklärte, warum es keinen Zyklus gibt.

Mit diesem Design kannst du "mehr Tokens verbraucht" nicht von "gründlicher gearbeitet" trennen. Ehrlich ist: 1.3 hat mehr ausgegeben und mehr geliefert – ob das ein Gewinn ist, hängt davon ab, ob du die zusätzliche Strenge wolltest.

Die Feature-Aufgabe zeigt das Gegenmuster und ist der klarste Beleg für Metas "weniger geschwätzig"-These. Muse Spark 1.2 erfand Parameter-Aliasse max_items, n und max_len, die niemand wollte, und schrieb 28 Tests. 

Muse Spark 1.3 schrieb eine Signatur mit sinnvollem Default und 20 Tests – 54% weniger Output-Tokens.

Was ich nicht kontrollieren konnte

Vier Dinge, und ohne sie wäre der Artikel unehrlich.

1. Muse Code hat sich zwischendurch von 1.0.2 auf 1.0.3 aktualisiert, das Harness war also nicht in allen sechs Läufen identisch. 
2. Aufgaben 2 und 3 starteten von der jeweiligen Vorarbeit jedes Modells statt von einem byte-identischen Baum, weil die Sequenz ohne Resets läuft.
3. Jede Zelle ist ein einzelner Versuch, normale Run-to-Run-Varianz bleibt ungemessen. 
4. Und ich lief alles auf dem Contributor-Tier, also dasselbe Modell, aber andere Datennutzungsbedingungen.

Nichts davon kehrt die Richtung der Ergebnisse um. Es heißt aber, dass eine aggregierte 12%-Differenz ein schwächeres Signal ist, als drei passende Läufe pro Zelle es wären.

Mose Spark 1.3 Best Practices und Troubleshooting

Ein paar Dinge, die ich gern am ersten Tag gewusst hätte.

Prompts für die Kollaborations-Features

Muse Spark 1.3 stellt Rückfragen bei mehrdeutigen Prompts. Ein über-spezifizierter Prompt schaltet also ein Feature ab, für das du zahlst. Kontraintuitiv, wenn du zwei Jahre lang gelernt hast, alles vorab hineinzupacken.

Scope bleibt trotzdem wichtig. "Splitte number.py" lässt das Modell die Grenze, die Import-Updates und die Definition von "fertig" raten. Die Version, die ich tatsächlich genutzt habe, präzisiert alle drei:

src/humanize/number.py is 571 lines. Split it into two modules along a sensible boundary, update all imports across the package, and make sure the full test suite still passes.

Noch etwas Nützliches: Mein Refactor-Prompt sagte number.py is 571 lines. Es sind 567. Beide Modelle korrigierten mich ungefragt, und 1.3 tat es im ersten Satz. Meine Zahl kam vom Messen der Repo-Spitze statt des gepinnten Commits.

Kosten niedrig halten

Packe den stabilen Teil deines Prompts nach vorn, damit er cachebar bleibt. Bei 88% bis 97% Hit-Rates beeinflusst dein Cache-Verhalten die Rechnung viel stärker als die Modellauswahl.

Die drei Aufgaben kosteten zusammen $0.034 im Contributor-Tier. Dasselbe auf Standard hätte $0.91 gekostet – ein Faktor 27. Das ist die Tier-Entscheidung in Geld: drei Cent versus neunzig.

Wenn du über OpenRouter gehst, wird Websuche separat mit $2.50 pro 1.000 Aufrufe berechnet.

Wann Muse Spark 1.3 die falsche Wahl ist

• Keine offengelegten Reasoning-Traces. Du siehst, was es entschieden hat, nicht warum – ein schlechtes Refactor wird so schwerer zu debuggen.
• Max Reasoning ist gegated, die Konfiguration hinter jeder Benchmark-Schlagzeile ist also aktuell tabu.
• Geschlossene Gewichte. Kein Self-Hosting, kein Fine-Tuning. Metas Roadmap erwähnt einen "Muse Spark Open-Weights-Release" ohne Version, Datum oder Lizenz.
• Ein Provider. Wenn Metas Endpoint degradiert, gibt es keinen Ausweichpfad.

Häufige Probleme und Lösungen

• muse: command not found nach sauberer Installation. Das Script installiert nach ~/.local/bin/muse, was nicht in jedem PATH liegt.
• Not logged in. Run muse again to log in. Genau das. Der erste muse beendet, der zweite startet den Login.
• Du bist im Contributor-Tier und hast es nicht gewählt. Das ist der Default. Check die Statusleiste und nutze /model, bevor du etwas Proprietäres öffnest.
• ultra Reasoning wird still zu xhigh. Das Gate ist zu. Lies stderr statt dem Flag zu vertrauen.
• Muse Code aktualisiert sich mitten in der Session. Bei mir von 1.0.2 auf 1.0.3 zwischen zwei Läufen. Wenn du etwas misst, pinne und dokumentiere die Version.

Eine Sache, die sich nicht reproduzierte

Es kursierten Berichte, dass EU-Nutzer nach dem 1.3-Release weiterhin Muse Spark 1.1 bekamen. Ich habe alles aus den Niederlanden ausgeführt und durchgehend 1.3 erhalten. Diese Berichte betrafen Meta.ai, den Consumer Assistant, und scheinen nicht für Muse Code oder die Model API zu gelten. Zwei verschiedene Rollouts.

Abschließende Gedanken

Metas Effizienzversprechen hielt bei zwei meiner drei Aufgaben und kehrte sich bei der dritten um – netto ein Kostenplus von 12% über das Set. Der Tool-Call-Teil wirkt solide mit 23% und 32% Reduktion, wo 1.3 gewann. Der Token-Teil hängt komplett davon ab, welche Tokens du zählst.

Wenn du bereits auf der Meta Model API oder in Muse Code bist, kostet das Tauschen der Model-ID eine Minute, und bei Routinearbeit wirst du wahrscheinlich vorne liegen. Wenn du frisch für produktive Agenten auswählst, sind das gegate max-Variant und fehlende Reasoning-Traces handfeste Gründe, ein paar Wochen zu warten.

Was ich wirklich mitnehme, ist nicht die Effizienz-Zahl. Es ist, dass Muse Code dich standardmäßig auf ein trainingstaugliches Tier setzt und dass ein dokumentiertes Reasoning-Level beim Anfordern still herabgestuft wird. Beides ist eine Ein-Zeilen-Prüfung – und beides ist leicht zu übersehen.

Fahr den Vergleich auf deiner eigenen Workload. Meine drei Aufgaben sind nicht deine drei Aufgaben, und die Streuung zwischen ihnen war größer als der Unterschied zwischen den Modellen.

Für das vollständige Benchmark-Bild hat Matts Muse Spark 1.3 Release-Analyse die Tabellen. Um dir die Kompetenzen aufzubauen, Modelle wie dieses selbst zu bewerten, starte mit unserem AI Agent Fundamentals Lernpfad.