MiniMax M3 API: Preise, 1M Kontext & Produktionseinsatz

Die MiniMax M3 API ging am 1. Juni live. Ich begann in dieser Woche mit dem Testen. Zwei Wochen sind das früheste, zu dem ich etwas aufschreibe — davor ist man noch von Demos beeindruckt.

Dies ist eine Arbeitsnotiz, keine Modellrezension. Benchmarks gibt es überall. Was mich interessierte, war enger gefasst: Wo passt das minimax m3 Modell tatsächlich in die Produktion, was kostet der 1M-Kontext in der Praxis, und direkte API oder Aggregator — welches und wann.

Vorab ein paar Dinge.

Die meisten Schlagzeilen-Zahlen (59,0 % SWE-Bench Pro, die >9× / 15× Speedups, 83,5 auf BrowseComp) stammen vom Anbieter. Ich würde sie als Obergrenze unter günstigen Bedingungen behandeln, nicht als Untergrenze für Ihren Codebase.

Der 1M-Kontext ist real. Die Preisgestaltung erfolgt in zwei Stufen. Das ist wichtiger, als die meisten denken.

Open Weights landeten rund um Tag zehn auf Hugging Face. Wenn Sie einen Launch-Artikel lesen, der sagt „Weights stehen bevor”, ist er bereits veraltet.

Was MiniMax M3 ist (für Entwickler)

API-Verfügbarkeit & Zugangswege

Drei Möglichkeiten. Direkt über MiniMax’s offene Plattform. Über einen Aggregator — OpenRouter, Fireworks und andere. Oder Self-Hosting von Hugging Face.

Ich habe die ersten beiden ausprobiert. Self-Hosting überlasse ich Leuten mit den entsprechenden GPUs — die minimax m3 Parameteranzahl beläuft sich auf ~428B insgesamt mit ~23B aktivierten Parametern pro Token (MoE), das ist kein Einzelverbraucher-GPU-Vorhaben.

Die zwei Wege, die ich getestet habe, fühlten sich auf eine Weise unterschiedlich an, die aus den Docs nicht offensichtlich ist. Direkt ist günstiger pro Token. Aggregatoren bieten eine einheitliche Abrechnungsoberfläche über viele Modelle hinweg. Welches davon wichtig ist, hängt von einer Frage ab, die die meisten Teams noch nicht beantwortet haben — und ich werde darauf später zurückkommen, weil genau dort die meisten ins Stocken geraten.

1M Kontext mit garantiertem Minimum von 512K

Dies ist die Zeile, die es wert ist, sorgfältig gelesen zu werden. Die MiniMax M3 API unterstützt bis zu 1M Token Kontext. Die Zahl, mit der Sie planen sollten, ist 512K — das garantierte Minimum. Die 1M-Obergrenze ist bedingt.

Ich habe einen Test bei ~480K durchgeführt (ein zusammengestelltes Repo + Design-Dokumente + ein langer Thread). Es kam konsistent über drei Läufe zurück, Latenz im erwarteten Bereich.

Bei ~700K hochgegangen (das vollständige Issue-Protokoll des Projekts hinzugefügt). Die Latenzstreuung weitete sich deutlich aus. Und die Abrechnungsstufe änderte sich.

In der Praxis also: 512K ist Ihre verlässliche Arbeitszahl. Die obere Hälfte des Fensters existiert, aber sie ist ein Budgetposten, keine freie Kapazität.

Die zugrundeliegende Architektur ist MSA — MiniMax Sparse Attention — dokumentiert im Launch-Post. Das relevante Detail für die Kostenplanung ist, dass die Token-Compute-Kosten bei 1M Kontext auf etwa 1/20 von M2 sinken. Ohne dieses Verhältnis wäre die Langkontext-Stufe wirtschaftlich überhaupt nicht möglich.

Wofür M3 gebaut wurde

Coding- & agentische Workloads

Das minimax m3 Modell ist für langfristige Coding- und Agentenarbeit positioniert. Aus zwei Wochen des Ausprobierens heraus ist diese Einordnung ehrlich.

Einzelne Q&A-Abfragen sind in Ordnung. Unaufregend, aber in Ordnung. Was sich ändert, sind lange Sessions — ein Repo lesen, planen, ausführen, iterieren, sich von einem Fehler in der Mitte erholen. MiniMaxs eigene Demo lässt M3 12 Stunden lang laufen, 18 Commits, ein ICLR-Paper reproduzieren. Das ist der Workload, auf den die Architektur ausgerichtet scheint.

Die relevanten minimax m3 Benchmark-Zahlen — alle vom Anbieter gemeldet — sind 59,0 % SWE-Bench Pro, 66,0 % Terminal Bench 2.1, 74,2 % MCP Atlas. VentureBeats Berichterstattung stellt sie GPT-5.5 und Gemini 3.1 Pro gegenüber. Die Rahmung („übertrifft”) würde ich um 30 % herunterkühlen. Die Zahlen sind real. Die Bedingungen waren MiniMaxs Labor und MiniMaxs Scaffolding.

Was das für Entwickler bedeutet: Wenn Sie einen Coding-Assistenten, einen Desktop-Agenten oder etwas bauen, das mehrstufige Pläne hält, ist M3 auf der Shortlist. Wenn Ihr Workload aus kurzen Prompts bei hoher Parallelität besteht, zahlen Sie für Kontext, den Sie nicht nutzen.

Native Multimodalität (Bild, Video) als Eingabe

Multimodalität ist nativ, nicht angebaut. Text, Bild und Video gehen in denselben Kontext. Die Ausgabe ist Text.

Ich habe ihm einen UI-Screenshot + eine 30-sekündige Bildschirmaufnahme + einen Teil des zugehörigen Backend-Codes gegeben und gefragt, was der Nutzer eigentlich versucht hat. Es hat funktioniert. Nicht auf Anhieb — ich musste es im zweiten Durchgang anstoßen. (Die erste Vermutung war vernünftig, aber falsch.) Das zählt nach meinem Maßstab als funktionierend.

Das Detail, das ich hervorheben möchte, weil es mich in einem anderen Test erwischt hat: Bild- und Video-Token teilen denselben Pool wie Text. Ein kurzer Clip kann einen erheblichen Teil Ihres 512K-Fensters aufbrauchen, bevor überhaupt Prompt-Text hinzukommt. Ich habe die Token-Anzahl eines 15-sekündigen 720p-Clips überprüft — sie war höher als mein mentales Modell. Es lohnt sich zu messen, bevor man extrapoliert.

Produktionskosten & Limits

Ich werde hier keine spezifischen Pro-Million-Token-Zahlen nennen. Anbieterpreise ändern sich, und es gibt einen separaten Beitrag zu den minimax m3 Preis-Mechanismen, der die Mathematik ordentlich behandelt. Was Sie in der Planungsphase brauchen, ist die Struktur.

Standard- vs. Langkontext-Tarif (>512K)

Zwei Stufen in der MiniMax M3 API:

≤512K Eingabe-Token — Standardtarif. Deckt die meisten Chat-, Coding- und Agent-Schleifen ab.
>512K Eingabe-Token — Höherer Langkontext-Tarif. Zielt auf vollständige Repo-Analyse, ultra-lange Dokumente, stundenlange Agent-Sessions ab.

Diese Aufteilung ist das Einzige, um das ich herum entwerfen würde. Ein System, das im 100K–300K-Bereich lebt, hat andere Stückkosten als eines, das routinemäßig 700K streift. Entdeckt auf dieselbe Weise, wie ich vermute, dass die meisten Teams es entdecken: durch Betrachten einer Rechnung.

Was für mich funktioniert hat: Standard-Routing bei 512K deckeln, ein explizites Flag verlangen, um darüber hinauszugehen. Dann tauchen die Kosten an der Aufrufstelle auf, nicht am Ende des Monats.

Gemeinsamer Token-Pool über Modalitäten hinweg

Das habe ich bereits erwähnt, aber es verdient eine eigene Zeile. Es gibt keine separate multimodale Zuteilung. Bilder sind Token. Frames sind Token. Sie nutzen dasselbe Fenster wie Text und überschreiten 512K auf dieselbe Weise wie Text.

Bei Agent-Schleifen, die jeden Turn Screenshots einbeziehen, baut sich das schneller auf als die Überschlagsrechnung vermuten lässt. Überprüfen Sie die Token-Anzahl einer echten Session. Vertrauen Sie nicht dem synthetischen Benchmark.

Direkte API vs. Aggregationsschicht

Die Entscheidung, bei der ich Teams feststecken sehe. Die meisten von ihnen zögern länger als nötig.

Wann jede Option sinnvoll ist

Direkt, wenn:

M3 als primäres Modell festgelegt ist und Sie nicht vorhaben, zu wechseln.
Die Pro-Token-Kosten wichtiger sind als die Integrationsoberfläche.
Sie die volle 1M benötigen (manche Aggregatoren haben eine niedrigere Obergrenze — Fireworks startete mit einer 500K-Obergrenze und hebt diese schrittweise an).
Eine modellspezifische Integration Sie nicht stört.

Über einen Aggregator, wenn:

Sie bereits mehr als ein Modell in der Produktion betreiben oder dies vorhaben.
Sie M3 gegen z. B. Claude Opus oder DeepSeek V4 A/B-testen möchten, ohne den Request-Pfad neu aufzubauen.
Einheitliche Abrechnung, Wiederholungsversuche, Fallback-Routing und Observability wichtig sind.
Sie noch nicht wissen, auf welches Modell sich Ihr Workload einpendeln wird.

Der ehrliche Fall für Aggregation ist nicht der niedrigere Pro-Token-Preis. In der Regel ist er geringfügig höher. Der Fall ist, dass die Freiheit, Modelle zu wechseln, wirtschaftlichen Wert hat, und dieser Wert wächst, je mehr Ihr Produkt die Generierung über Anbieter hinweg berührt. WaveSpeedAI sitzt in dieser Schicht, ebenso OpenRouter und Fireworks — jeder macht unterschiedliche Kompromisse bei Routing, Latenz und Abdeckung.

Meine grobe Faustregel, für das, was sie wert ist: Single-Model-Coding-Agent → direkt. Gemischter Text + Bild + Video über Anbieter → Aggregator. Keine harte Regel. Ein Ausgangspunkt.

Limits & Kompromisse

Open Weights, technischer Bericht und was noch fehlt

Weights sind auf Hugging Face. Community-GGUF-Quantisierungen sind verfügbar. Zwei Dinge, die man wissen sollte:

Lizenzbedingungen sind noch nicht vollständig geklärt. Gehen Sie nicht von Apache 2.0 oder MIT aus — prüfen Sie dies, bevor Sie kommerzielle Produkte auf dem lokalen Deployment-Pfad aufbauen.

Und nicht jede Inferenz-Engine unterstützt MSA bereits. Diejenigen, die es nicht tun, fallen auf Dense Attention zurück, was einen Teil des Geschwindigkeitsvorteils einbüßt. Wenn Sie selbst hosten, überprüfen Sie die Engine-Unterstützung bevor Sie Benchmarks durchführen — andernfalls werden Ihre Zahlen schlechter aussehen als sie sollten.

Die ARC-AGI-Lücke

Eine Sache, die die Launch-Berichterstattung tendenziell überspringt. M3s Coding- und agentische Zahlen übertragen sich nicht sauber auf allgemeine abstrakte Reasoning-Benchmarks wie ARC-AGI. Das Modell ist für das ausgelegt, was es bewirbt — Coding, Tool-Nutzung, langfristige Agenten, multimodales Grounding — nicht für abstrakte Rätsel.

Das ist keine Kritik. Es ist die Form des Modells. Das zu wissen verhindert eine falsche Entscheidung.

FAQ

Ist die MiniMax M3 API bereits live und stabil für den Produktionseinsatz?

Ja. Live seit dem 1. Juni 2026. Stabil genug, dass mehrere Aggregatoren echten Traffic routen. Wie bei jedem Modell, das weniger als drei Monate alt ist, sollten Sie gelegentliche Verhaltensänderungen erwarten, während der Anbieter Anpassungen vornimmt — pinnen Sie Ihre Prompts, halten Sie eine Eval-Suite bereit.

Was ist die tatsächlich garantierte Kontextlänge bei MiniMax M3 (512K oder 1M)?

512K garantiert, 1M Obergrenze. Unter 512K verhält sich konsistent. Darüber hinaus wechseln Sie in höhere Preise und größere Latenzstreuung. Manche Aggregatoren haben beim Launch eine niedrigere Obergrenze als 1M. Planen Sie rund um 512K.

Ist MiniMax M3 nativ multimodal für Bild- und Videoeingaben?

Ja. Nativ, nicht als Adapter. Text, Bild und Video teilen denselben Token-Pool und das gleiche Kontextfenster. Die Ausgabe ist nur Text.

Sind die Open Weights für MiniMax M3 bereits verfügbar?

Ja. Sie landeten rund zehn Tage nach dem Launch auf Hugging Face. ~428B Gesamtparameter, ~23B aktivierte Parameter pro Token (MoE). Ein einzelner Consumer-GPU wird es nicht ausführen — erwarten Sie Multi-GPU oder quantisierte Inferenz. Lizenzbedingungen — vor kommerziellem Einsatz prüfen.

Sollte ich auf MiniMax M3 direkt oder über einen Aggregator zugreifen?

Direkt, wenn Sie sich auf ein einzelnes Modell festgelegt haben und die niedrigsten Pro-Token-Kosten wollen. Aggregator, wenn Sie mehr als ein Modell betreiben oder wechseln möchten. Die Antwort hängt von Ihrem Workload ab, nicht davon, welches „besser” ist.

Fazit

Die MiniMax M3 API ist weniger deshalb interessant, weil sie eine einzelne Achse anführt, als vielmehr wegen der Kombination — Frontier-Level-Coding, native Multimodalität, ein echter (wenn auch gestufter) 1M-Kontext, Open Weights — alles in einem Modell. Diese Kombination reduziert die Integrationsoberfläche, die früher das Zusammenfügen mehrerer Anbieter erforderte.

Was ich tun würde, bevor ich mich für die Produktion entscheide:

Führen Sie Ihren tatsächlichen Workload aus, keinen Benchmark. Messen Sie, wo Prompts relativ zu 512K landen. Entscheiden Sie die Routing-Richtlinie vor dem Launch. Wählen Sie direkt oder Aggregator basierend darauf, wie viele Modelle Sie betreiben werden, nicht allein auf den Listenpreis. Wenn Sie selbst hosten, prüfen Sie MSA-Unterstützung in Ihrer Engine.

Zwei Wochen sind nicht lang. Das Modell wird sich weiterentwickeln und so auch die Preisgestaltung. Das ist das Verfallsdatum dieses Beitrags.

Stets zu verifizieren anhand dessen, was die Docs an dem Tag sagen, an dem Sie tatsächlich bauen.

Vorherige Beiträge: