MiniMax M3: Het Open-Weight Model Dat Me Versteld Deed Staan
Een model heeft 24 uur lang eigenhandig een GPU-kernel herschreven, 147 benchmark-inzendingen gedaan, bijna 2.000 tool-aanroepen afgevuurd en de hardware-benutting van 7,6% naar 71,3% geduwd — zonder één enkele menselijke toetsaanslag. Dat is ruwweg een 9,4x versnelling van een FP8 CUDA-kernel voor NVIDIA Hopper GPU's — vertrekkend van een Triton-skelet dat niet eens draaide.
Het model dat dit deed is MiniMax M3. En het is open-weight.
Ik wil even stilstaan bij die tweede zin, want dat is het deel dat me deed stoppen met scrollen. We zijn gewend geraakt aan een bepaalde orde in AI: de frontier-capaciteiten zitten achter gesloten API's van een handvol Amerikaanse labs, en de open modellen lopen een of twee generaties achter — nuttig, maar nooit echt concurrerend aan de top. MiniMax M3, dat het MiniMax-team op 1 juni 2026 lanceerde, is de eerste open-weight release die ik dit jaar heb gezien die specifiek gebouwd lijkt om die orde te doorbreken — frontier-coding, een contextvenster van een miljoen tokens en native multimodaliteit, alles in één enkel model dat je kunt downloaden en zelf hosten.
De lanceringsclaims zijn luid. GPT-5.5 en Gemini 3.1 Pro verslaan op belangrijke benchmarks. Opus 4.7 benaderen in coding. Een actieprijs die een afrondingsfout is naast propriëtaire frontier-tarieven. Sommige van die cijfers zijn onafhankelijk verifieerbaar, andere zijn eigen benchmarks van MiniMax, en een paar verdienen het type scepsis dat ik bij elke modellancering hanteer. Dit is dus een eerste blik — wat M3 daadwerkelijk beweert, wat ik kan verifiëren, waar ik vraagtekens bij zou zetten, en of het een plek in jouw stack verdient. Laat me je er doorheen leiden.
Waarom een open-weight frontier-model nu belangrijk is
De timing is hier het hele verhaal, dus laat me het verankeren.
De afgelopen maanden volgde elke interessante modellancering een van twee scripts. Ofwel een gesloten Amerikaans frontier-model — Opus 4.7, GPT-5.5, Gemini 3.1 Pro — waarbij je intelligentie per token huurt en nooit de gewichten aanraakt. Of een capabel open release van een Chinees lab dat goed is maar duidelijk een laag onder de frontier gepositioneerd. Ik heb er veel van het tweede type beoordeeld: mijn hands-on met DeepSeek V4-Pro en mijn analyse van Kimi K2.6 kwamen beide in de categorie "oprecht nuttig, niet helemaal frontier" terecht.
MiniMax M3 is gepositioneerd als de eerste die dat plafond niet accepteert. Volgens MiniMax is het het eerste en enige open-weight model dat drie dingen tegelijk combineert: frontier-level coding, een 1M-token contextvenster en native multimodaliteit. Elk daarvan bestaat apart in andere open modellen. Alle drie samenbrengen in één downloadbaar checkpoint is de eigenlijke kop — niet een enkel benchmarkcijfer.
Dit is waarom het je zou moeten interesseren, zelfs als je prima tevreden bent met betalen voor Opus. Open gewichten veranderen de economie en het controleoppervlak. Je kunt M3 op je eigen infrastructuur draaien, fijnafstemmen op je domein, auditen en nooit een token naar andermans servers sturen. Voor iedereen die agents bouwt die gevoelige data verwerken — juridisch, medisch, financieel — is dat geen luxe, het is het verschil tussen "we kunnen dit gebruiken" en "compliance zei nee". Ik heb precies dat gesprek meer dan eens veelbelovende interne AI-projecten zien stranden.
En de prijs. De lanceringsactie halveert de gebruikskosten naar $0,30 per miljoen input-tokens en $1,20 per miljoen output-tokens (tegenover de standaard $0,60 / $2,40), met een tokenplan van $20/maand dat ruwweg 1,7 miljard M3-tokens koopt. VentureBeat presenteerde M3 als een model dat concurrerende benchmarkprestaties levert "voor slechts 5-10% van de kosten" van de propriëtaire leiders. Als dat standhoudt onder echte werkbelastingen, kantelt de bouw-vs-koop-berekening voor veel teams van de ene op de andere dag.
Maar goedkoop en open betekenen niets als het model het werk niet daadwerkelijk kan doen. Voordat ik enthousiast word, moet ik de architectuur begrijpen die dit allemaal mogelijk moet maken — want daar wordt de lancering echt interessant.
Wat is MiniMax Sparse Attention (MSA)?
MiniMax Sparse Attention (MSA) is het architectonische mechanisme dat M3 in staat stelt om een context van een miljoen tokens betaalbaar te verwerken door volledige aandacht te vervangen door selectieve KV-blok-aandacht — aandacht berekenen over alleen de blokken die ertoe doen in plaats van elke token tegen elke andere token.
Dat is de versie van één zin. Dit is waarom MSA de dragende muur is van deze hele release.
Een korte opmerking over de naam, want de automatisch gegenereerde transcripten hebben het flink verminkt. Ik heb het zien schrijven als "Multi-Scale Attention" en "Miniax sparse attention". De juiste term, volgens MiniMax' eigen technisch materiaal, is MiniMax Sparse Attention (MSA). Dezelfde familie van ideeën als het sparse- en lightning-attention-werk dat MiniMax in eerdere generaties heeft geleverd, verfijnd voor M3.
Standaard transformer-aandacht heeft een brutale eigenschap: de kosten schalen ruwweg met het kwadraat van de sequentielengte. Verdubbel je context, verviervoudig je berekening. Daarom zijn contextvensters van een miljoen tokens historisch ofwel schreeuwend duur ofwel stilletjes gedegradeerd — het model accepteert technisch een lange invoer maar stopt met echt aandacht besteden aan het meeste ervan. Je hebt dit waarschijnlijk meegemaakt. Je plakt een enorm document, stelt een vraag over pagina 40, en het model antwoordt zelfverzekerd op basis van pagina 2.
MSA valt dit direct aan. In plaats van dat elke token aandacht besteedt aan elke andere token, selecteert het de relevante KV-blokken en berekent de aandacht daarover. De gerapporteerde winst is dramatisch: MiniMax zegt dat MSA ruwweg 15,6x snellere decodering en 9,7x snellere prefill levert ten opzichte van de vorige M2-generatie bij contexten van een miljoen tokens, en de kosten bij 1M tokens terugbrengt tot ongeveer een twintigste van de vorige generatie. De decoderdekking gepubliceerd bij de lancering beschrijft dat de langcontexttrap boven 512.000 tokens in werking treedt.
Ik wil eerlijk zijn over mijn vertrouwensniveau hier. De richting van deze claims is geloofwaardig — selectieve aandacht is een goed gevestigde manier om de kwadratische curve te doorbreken, en meerdere labs convergeren op varianten ervan. De exacte vermenigvuldigers zijn MiniMax' eigen metingen, en ik heb ze niet onafhankelijk geprofileerd. Behandel "9,7x prefill" dus als een fabrikantenbenchmark, niet als een natuurwet. Wat ik kan zeggen is dat de architectuur de juiste vorm heeft voor het probleem, en het engineering-verhaal intern consistent is.
Er is een tweede architectonische beslissing die net zo belangrijk is, en het is degene waarvan ik denk dat mensen hem zullen onderschatten.
Native multimodaliteit is niet hetzelfde als aangebouwde visie
M3 is vanaf stap nul getraind op tekst- en visuele data — native multimodaal — in plaats van een sterk tekstmodel te nemen en er achteraf een visie-encoder op te enten.
Dit onderscheid klinkt academisch totdat je het verschil in de praktijk ziet. Aangebouwde visiemodellen hebben de neiging om beelden te behandelen als een apart zintuig dat wordt vertaald in tekst-achtige tokens en op afstand wordt beredeneerd. Native multimodale modellen bouwen een gedeelde representatie op waarin visueel en tekstueel begrip vanaf het begin verweven zijn. De lanceringsdemo die dit voor mij duidelijk maakte was een formulierinvultaak: M3 kreeg een leeg formulierbeeld en een set datapunten, en plaatste elke waarde in het juiste veld met de juiste spatiëring en tekenpositionering — stap voor stap redenerend door coördinaten, veldplaatsing en lay-out.
Dat is niet "lees de tekst in het beeld". Dat is ruimtelijk redeneren over een visuele lay-out. En MiniMax meldt dat M3 70,06% scoort op OSWorld-Verified, een computer-use benchmark — het soort resultaat dat je alleen krijgt wanneer visueel en actiegericht redeneren nauw gekoppeld zijn.
De architectuur belooft dus frontier-redenering bij lange context, goedkoop, met ingebouwd visueel vermogen. Gedurfd. Laten we nu bekijken of de benchmarks de architectuur ondersteunen — en hier word ik voorzichtiger.
De benchmarks: wat echt is, wat van de fabrikant komt en waar ik vraagtekens bij zou zetten
Laat me eerst de hoofdcijfers op tafel leggen, dan gaan we ze ondervragen. Elk cijfer hieronder komt uit MiniMax' lancering of breed gerapporteerde berichtgeving erover — ik zal markeren wat door derden is bevestigd tegenover wat puur eerstehandsinformatie is.
| Benchmark | MiniMax M3 (beweerd) | Wat het meet | Context |
|---|---|---|---|
| SWE-bench Pro | 59,0% | Autonome software-engineering-taken | Gemeld vóór GPT-5.5 (~58,6%); achter Opus in coding |
| Terminal-Bench 2.1 | 66,0% | Terminal-/agent-taakafronding | Sterk agentisch resultaat |
| SWE-fficiency | 34,8% | Efficiëntie van code-wijzigingen | Middenklasse, eerlijk gezegd |
| KernelBench Hard | 28,8% | Low-level GPU-kernel generatie | De moeilijke — let op het absolute getal |
| MCP Atlas | 74,2% | Toolgebruik via Model Context Protocol | Sterke tool-orkestratie |
| BrowseComp | 83,5 | Webbrowsing-/onderzoeksagent | Toptier browsing |
| OSWorld-Verified | 70,06% | Computergebruik (visie + actie) | Ondersteunt de native-multimodaliteitsclaim |
| SVG-Bench | Overtreft Opus 4.7 | SVG-generatiekwaliteit | Eerstehandsvergelijking |
Nu de eerlijke lezing.
Het meest geciteerde resultaat is SWE-bench Pro op 59,0%, wat M3 nipt voor GPT-5.5 plaatst met ruwweg 58,6% en voor Gemini 3.1 Pro op die specifieke benchmark. Dat is het cijfer dat het zware PR-werk doet, en het is het cijfer dat je scepsis het meest verdient — niet omdat het verzonnen is, maar omdat een voorsprong van een half procentpunt op één benchmark ruim binnen de ruis valt van hoe deze evaluaties worden uitgevoerd, opgebouwd en gerapporteerd. Een open-weight model dat in hetzelfde cluster als GPT-5.5 landt op een echte agentische coding-benchmark is het oprecht indrukwekkende feit. "Verslaat GPT-5.5" als kop overdrijft een statistisch gelijkspel.
Waar de framing het meest uitmaakt: MiniMax beweert niet Opus te verslaan in coding. De rapportages die ik heb gezien tonen Opus 4.8 leidend in coding met circa 69,2% op SWE-bench Pro tegenover M3's 59,0%. De correcte uitspraak is dus "M3 nadert het Opus-niveau en gaat de strijd aan met GPT-5.5 en Gemini 3.1 Pro" — niet "M3 is de nieuwe koning". Ik heb de propriëtaire frontier in detail vergeleken in mijn Opus 4.7 vs GPT-5.4 vs Gemini 3 Pro analyse, en de verschillen aan de top zijn klein maar reëel.
Een getal dat ik je correct wil laten lezen: KernelBench Hard op 28,8%. Uit context ziet dat er laag uit, en mensen zullen ermee spotten. Maar KernelBench Hard is brutaal — het vraagt een model om performante, correcte GPU-kernels te schrijven, een taak waarop de meeste modellen in de enkele cijfers of lage tieners scoren. 28,8% op de moeilijke split is eigenlijk een sterk resultaat voor een open model, en direct relevant voor dat 24-uur CUDA-kernel verhaal waarmee ik opende. Absolute getallen zonder de moeilijkheidsbasislijn van de benchmark is hoe lanceringsposts je misleiden.
De benchmarks waar M3's open-weight status het resultaat echt verrassend maakt, zijn de breedte-benchmarks — BrowseComp, SVG-Bench, KernelBench Hard, MCP Atlas en de documentbegrip-evaluaties — waar een open model naar verluidt propriëtaire rivalen evenaart of verslaat over categorieën heen, niet op slechts één uitgepickte metriek. Breedte is moeilijker te manipuleren dan een enkel getal. Dat is het deel van deze lancering dat ik het serieusts neem.
Als je hulp nodig hebt om signaal van ruis te scheiden bij releases als deze, is dat precies het type evaluatie dat ik voor klanten doe — modellen testen tegen echte werkbelastingen in plaats van de lanceringspresentaties te vertrouwen. Je kunt het soort projecten dat ik aanneem bekijken op fiverr.com/s/EgxYmWD.
Dat is de klassement-weergave. Maar benchmarks zijn abstracties. De reden waarom ik aandacht besteed aan M3 zijn de twee langetermijn-autonomiedemo's — want die zijn veel moeilijker te faken dan een klassementrij.
De 24-uur kernel en de zelftraining-test: langetermijn-autonomie
Hier is de demo die me deed besluiten dit artikel te schrijven, goed verteld.
MiniMax gaf M3 een taak waar de meeste senior engineers voor zouden terugdeinzen: een FP8 GEMM (matrixvermenigvuldiging) kernel optimaliseren op NVIDIA Hopper GPU's. De vangst — M3 kreeg alleen een taakbeschrijving, een benchmark-evaluatiescript en een niet-functionerend Triton-skelet. Geen referentie-implementatie. Geen startcode die draaide. Het moest het ding werkend krijgen en snel maken, vanuit praktisch niets.
Toen lieten ze het draaien.
Gedurende ruwweg 24 uur deed M3 147 benchmark-inzendingen en 1.959 tool-aanroepen, werkend door baseline-implementatie, autotuning, knelpunt-diagnose, CUDA Graph-integratie, persistent-kernel herschrijving en host-side scheduling. De piekbenutting van de hardware klom van 7,6% naar 71,3% — een 9,4x versnelling. Het detail dat ik het meest veelzeggend vind: MiniMax meldt dat de meeste andere modellen binnen hun eerste 30 inzendingen stopten met nieuwe vooruitgang boeken; alleen Opus 4.7 en M3 bleven verbeteringen vinden voorbij dat punt.
Dat laatste punt is het echte signaal. Veel modellen kunnen één goede klap uitdelen op een probleem. Maar heel weinige kunnen een campagne volhouden — diagnosticeren waarom poging 89 stagneerde en wat te proberen bij poging 90 — zonder in herhaling te vervallen of vooruitgang te hallucineren die er niet is. Langetermijn-coherentie is het vermogen dat een chatbot scheidt van een agent, en het is wat ik het hardst test in mijn eigen werk. Ik ging dieper in op waarom aanhoudende autonomie zo moeilijk is in mijn MiniMax M2.7 review, waar de zelfevolutie van de vorige generatie de kop was.
De tweede autonomietest is, zo mogelijk, nog gedurfder. Op een "Post-Train Bench" die meet of een model de volledige machine-learning-lus zelf kan uitvoeren — trainingsdata synthetiseren, een model trainen, het evalueren, itereren — kreeg M3 vier basismodellen die alleen pretraining hadden afgerond en voerde het hele datasynthese-tot-iteratie-cyclus uit over ongeveer 12 uur zonder menselijke interventie. Het eindigde naar verluidt als derde, achter alleen Opus 4.7 en GPT-5.5, vóór elk ander getest model.
Een model dat autonoom andere modellen kan verbeteren, dat bij de top drie ter wereld hoort in deze discipline, en dat open-weight is — dat is het soort zin dat achttien maanden geleden als sciencefiction had geklonken.
Mijn eerlijke voorbehoud, zoals altijd: dit zijn demonstraties van MiniMax, uitgevoerd door MiniMax, gerapporteerd door MiniMax. Ze zijn niet peer-reviewed en niet adversarieel. De cijfers zouden best-case runs kunnen zijn, geselecteerd uit vele pogingen. Maar — en dit is belangrijk — de structuur van deze tests is moeilijk overtuigend te faken, omdat de artefacten (een werkende, snelle CUDA-kernel; getrainde modelcheckpoints) verifieerbare eindproducten zijn, niet slechts scores. Ik zou ze willen reproduceren voordat ik een productiesysteem op M3's autonomie verwed. De richting is echter onmiskenbaar.
Benchmarks en autonomiedemo's zijn één ding. Wat mij als bouwer echt interesseert, is of het ding goede code schrijft die ik zou uitleveren. Laten we dus naar de bouw-tests kijken.
Hoe presteert MiniMax M3 bij echte front-end en creatief coderen?
MiniMax M3 produceert productiegericht front-end-output — schone componentstructuur, meerdere typografiesystemen en werkende animaties — en in de lanceringssvergelijkingen presteerde het beter dan Qwen's nieuwste "Max"-model en produceerde het minder bugs dan Gemini Flash op dezelfde prompts.
Eerst een naamcorrectie, aangezien de transcripten het verminken: het vergelijkingsmodel is Qwen (Alibaba's vlaggenschip, de propriëtaire "Max"-laag per medio 2026), niet "Quen 3.7". En het lichtere Google-model is de Gemini Flash-reeks — ik testte die familie apart in mijn Gemini 3.5 Flash hands-on. De vergelijkingsset correct identificeren is belangrijk, want "verslaat Qwen Max" en "verslaat een klein Flash-model" zijn heel verschillende claims.
Dit is wat de bouw-demo's daadwerkelijk lieten zien en hoe ik ze interpreteer.
De landing page-test. Bij een prompt voor een landing page met kleurblokken en een variabel kleursysteem produceerde M3 een schoon, goed gestructureerd ontwerp met dynamische interacties — en in de directe vergelijking was Gemini's output buggier. Dit komt overeen met mijn algemene ervaring: het verschil tussen modellen bij UI-werk is meestal niet "kan het een div centreren", maar "blijft het spacing-systeem consistent over componenten en werkt de interactiviteit echt?". M3 hield naar verluidt beide vast. Dat is de productierijpheids-drempel.
De browsergebaseerde Windows 11-kloon. Dit is degene die me mijn wenkbrauwen deed optrekken. Vanuit één enkele prompt omvatte M3's build opstartsgeluiden en -animaties, een functionele login met PIN-invoer, werkende replica's van Kladblok en Paint, een Rekenmachine, een Opdrachtprompt, een Instellingen-app met volumeregeling — en, ongevraagd, een 3D trench-run game. Het ongevraagde spel is de interessante aanwijzing: het suggereert dat het model niet simpelweg patroonherkenning deed op het letterlijke verzoek maar elaboreerde op de geest van "bouw een desktop-besturingssysteem". De enige gemelde misser was het SVG-coderen van elk app-icoon. Die ruil neem ik graag.
De 3D- en fysica-test. Gevraagd om negen kanalen te simuleren op een concaaf tv-scherm uit de jaren 1990, leverde M3 precies 3D-rendering met 3D Gaussian Splatting (3DGS) — dat is het "3GS" dat het transcript verminkte — met UI-besturingselementen, animaties, fysicasimulatie, procedurele graphics en ingebouwd geluid. Een immersieve 3D-kamer, vanuit een tekstprompt. Als je ooit hebt geworsteld om een model coherente Three.js of WebGL te laten produceren, weet je hoe zeldzaam schone fysica-bewuste 3D-output is.
De SVG-op-schaal-test. Drie SVG-uitdagingen: een geanimeerde vlinder (hoge kwaliteit, vergelijkbaar met Gemini), een PS4-controller (nauwkeurige lay-out en toetsenblok, Qwen verslagen) en een NYC-skyline met dag/nacht-overgang die meer dan 2.000 regels SVG omvatte met geanimeerde scène-overgangen en geen opvulling. Die laatste is de echte test. 2.000 regels betekenisvolle markup genereren zonder dat het model opgeeft, gaat herhalen of de output opvult met repetitieve rommel is een echte langetermijn-output stresstest — en het is direct verbonden met die MSA langcontext-architectuur.
De rode draad door alle vier: M3 produceert niet alleen code die compileert, het produceert code met smaak — lay-out-discipline, ongevraagde uitwerking, aanhoudende coherentie over lange outputs. Dat is de kwalitatieve sprong die benchmarks moeilijk kunnen vastleggen.
Hoe kom je er dan daadwerkelijk aan? Dat deel is verfrissend eenvoudig.
Hoe krijg je toegang tot MiniMax M3 (API, CLI en OpenRouter)
Je kunt MiniMax M3 vandaag via drie hoofdwegen gebruiken: de MiniMax API rechtstreeks, het MiniMax-codingplatform/CLI en OpenRouter — en de gewichten worden naar verwachting binnen ongeveer tien dagen na de lancering publiekelijk vrijgegeven voor zelfhosting.
Hier is de praktische uitsplitsing, met gecorrigeerde naamgeving (de "M Code", "Open Code" en "Open Router" van het transcript staan voor het MiniMax-codingplatform/CLI en OpenRouter respectievelijk):
-
MiniMax API — Haal een API-sleutel op van het MiniMax-platform en roep M3 direct aan. De prijzen tijdens de lanceringsactie zijn $0,30/M input en $1,20/M output tokens (de helft van de standaard $0,60 / $2,40). Rate limits bij lancering werden gemeld rond 200 RPM en 10M TPM. Dit is je route voor productie-integraties.
-
MiniMax-codingplatform / CLI — MiniMax levert zijn eigen codingtool, en bij de lancering werd een codeplatform vermeld dat gratis M3-toegang biedt. Omdat de API OpenAI-compatibel is, kun je ook je sleutel invoeren in tools zoals Claude Code, Cline of OpenCode en ze naar M3 richten — hetzelfde patroon dat mensen met eerdere MiniMax-modellen hebben gebruikt. Als je de volledige setup-handleiding wilt voor het routeren van third-party codingtools naar MiniMax, heb ik de workflow behandeld in mijn MiniMax M2.7 review.
-
OpenRouter — M3 staat vermeld op OpenRouter (
minimax/minimax-m3), wat de snelste manier is om het te testen tegen modellen die je al gebruikt zonder een tweede API-sleutel te beheren. Hier zou ik beginnen als je gewoon een middag wilt rondkijken. -
Zelfhosting (binnenkort) — Zodra de gewichten op Hugging Face en GitHub verschijnen, kun je M3 op je eigen infrastructuur draaien. Dit is de optie die de compliance- en finetuning-gebruikscases ontgrendelt die ik eerder noemde — en de reden waarom het label "open-weight" meer is dan een marketingwoord.
Een specifieke kostenopmerking die de moeite waard is om te internaliseren: het 1M-token contextvenster komt met een trap. MiniMax garandeert een bruikbaar minimum van 512.000 tokens tegen het standaardtarief; verzoeken boven 512K worden gefactureerd tegen het langcontext-tarief, gemeld op ruwweg het dubbele van het standaardtarief per token. "1M context" is dus echt, maar de tweede helft van dat venster kost meer. Plan dienovereenkomstig — ontwerp geen agent die bij elke aanroep achteloos voorbij 512K tokens schiet zonder de berekening gemaakt te hebben.
Pro-tip: als je M3 evalueert voor een agent die het volledige miljoen-token-venster nodig heeft, instrumenteer dan je tokenverbruik voordat je je vastlegt. Ik heb langcontext-agents stilletjes hun kosten 4x zien vermenigvuldigen omdat niemand merkte dat de context bij elke lus voorbij de goedkope trap zwol. Meet eerst.
En nu — moet je dit daadwerkelijk adopteren? Hier scheid ik de hype van wat ik oprecht tegen een klant zou zeggen.
Het eerlijke verhaal: waar ik M3 zou vertrouwen en waar niet
Ik geef je de eerlijke versie — degene die ik een vriend bij de koffie zou geven, niet het lanceringsdag-enthousiasme.
Wat me oprecht onder de indruk maakt. De combinatie is de prestatie, niet een enkel getal. Frontier-nabij coding plus 1M native multimodaal context plus open gewichten plus een prijs in het enkele-cijfer-percentagebereik van propriëtaire frontier-modellen — dat pakket bestond niet vóór 1 juni 2026. Voor een solo-oprichter of een klein team dat geprijsd was uit het draaien van serieuze agents op Opus, verandert M3 wat betaalbaar is. De breedte over benchmarks (niet alleen het SWE-bench-kopgetal) en de langetermijn-autonomiedemo's zijn de delen waar ik het meeste gewicht aan toeken, omdat ze het moeilijkst te faken zijn.
Waar ik zou remmen. Elk prestatiecijfer hierboven is van MiniMax zelf, gemeten onder MiniMax' omstandigheden. Het "verslaat GPT-5.5"-kader rust op een half punt voorsprong dat statistisch een gelijkspel is. M3 verslaat Opus niet in coding, en iedereen die je vertelt dat het "de nieuwe frontier-koning" is, verkoopt je iets. Fabrikantenbenchmarks hebben een lange geschiedenis van het niet overleven van onafhankelijke reproductie — ik heb genoeg lanceringsdag-klassement-koplopers zien zakken naar "heel goed, niet het beste" zodra de gemeenschap ze adversarieel testte. Totdat derden M3 op hun eigen teststanden profileren, behandel ik deze resultaten als veelbelovend, niet bewezen.
De afweging die niemand op lanceringsdag noemt. Open gewichten zijn een geschenk en een verantwoordelijkheid. Een 1M-context multimodaal model zelf hosten is geen weekendproject — je hebt echte GPU-infrastructuur nodig, en de langcontext-trap is oprecht duur op de tweede helft van het venster. Het "gratis" en "goedkoop"-kader geldt duidelijk voor de API-laag en kleine contexten. Ga in miljoen-token-agentlussen en de kosten zijn echt. Laat "open-weight en goedkoop" je niet verleiden tot het ontwerpen van iets dat je budget niet kan dragen op schaal.
Mijn voorspelling. Ik denk dat M3 het begin is van een patroon, geen eenmalig geval. De kloof tussen open en gesloten frontier-modellen krimpt al een jaar, en M3 is de eerste release waarvan ik zou zeggen dat de kloof aan de top nu een kwestie van maanden is, niet van generaties — tenminste op coding en agentische taken. Tegen het einde van 2026 verwacht ik dat "gebruik een open model voor 90% van het agentwerk, val terug op een gesloten frontier-model voor de moeilijkste 10%" een volledig gangbare architectuur zal zijn. M3 maakt die architectuur vandaag haalbaar.
Hier is de ongemakkelijke vraag die boven het hele propriëtaire frontier-bedrijfsmodel hangt: als een open-weight model je 90% van de weg brengt tegen 5-10% van de kosten, waarvoor betaal je dan precies die andere 90%? Voor sommige werkbelastingen is het antwoord "de laatste 10% betrouwbaarheid, en dat is het waard". Voor veel werkbelastingen plotseling niet meer.
Hoe ziet het adopteren van M3 er dan in de praktijk uit, en hoe zou je weten dat het werkt? Laat me het concreet maken.
Wat te verwachten als je M3 daadwerkelijk adopteert
Realistische verwachtingen, gebaseerd op het mechanisme in plaats van verzonnen metrieken.
Als je momenteel agentische werkbelastingen draait op een propriëtair frontier-model en het merendeel ervan overzet naar M3, is het kostenmechanisme eenvoudig: bij $0,30/$1,20 per miljoen tokens (actie) versus propriëtaire frontier-tarieven die vele malen hoger liggen, daalt je uitgave per taak voor routinematig agentwerk aanzienlijk — VentureBeat's "5-10% van de kosten"-kader is de orde van grootte om mee te plannen bij vergelijkbare benchmarkprestaties. Het eerlijke voorbehoud is dat de besparingen afnemen zodra je voorbij de 512K langcontext-trap gaat, dus de grootste winsten zitten bij kort-tot-middelgrote contexttaken op hoog volume.
Wat je daadwerkelijk moet meten zodra je test:
- Taakafrondings-percentage op je echte werkbelastingen, niet op benchmarks. Laat M3 en je huidige model op dezelfde 20 echte taken draaien en vergelijk. Dit is het enige getal dat ertoe doet.
- Langetermijn-stabiliteit. Bij multi-stap agents, kijk hoeveel stappen M3 volhoudt voordat het de draad kwijtraakt of zich begint te herhalen. De kerneldemo suggereert dat dit een sterk punt is — verifieer het op jouw taken.
- Hallucinatie-percentage op jouw domein. Native multimodaliteit en lange context repareren niet automatisch fabricatie. Controleer outputs steekproefsgewijs tegen de grondwaarheid.
- Kosten per voltooide taak (niet per token). Een goedkoper model dat drie pogingen nodig heeft, is niet goedkoper.
Snelle resultaten die je de eerste middag kunt verwachten: front-end en SVG-generatie die dichter bij productierijpheid komt dan de meeste open modellen, en dramatisch lagere kosten bij hoogvolume agentlussen met korte context. De langetermijnopbrengst — zelfhosting voor compliance, finetuning op je domein — komt wanneer de gewichten verschijnen en je de infrastructuur hebt opgezet.
Verwacht niet: een gratis lunch bij 1M-context werkbelastingen, of onafhankelijk geverifieerde frontier-superioriteit. Verwacht een oprecht sterk, oprecht open model dat goed genoeg is om de standaard te zijn voor het merendeel van je agentwerk, met een gesloten frontier-model als terugvaloptie voor de moeilijkste taken.
De conclusie over MiniMax M3
Ga terug naar dat openingsbeeld: een model alleen in het donker gedurende 24 uur, inzending na inzending, een dood kernel-skelet van 7,6% naar 71,3% benutting duwend terwijl niemand toekeek. Wat dat verhaal belangrijk maakt, is niet de versnelling. Het is dat het model dat het deed er een is dat je binnenkort kunt downloaden, inspecteren, finetunen en op je eigen machines kunt draaien — voor een prijs die de economie van de propriëtaire frontier plotseling fragiel doet lijken.
MiniMax M3 is niet het beste model ter wereld. Opus leidt nog steeds in coding, de kop-benchmarkoverwinningen zijn statistische gelijkspelen, en elk getal hier verdient de scepsis die ik bij elke lancering zou hanteren. Maar "beste ter wereld" was nooit het punt. Het punt is dat frontier-nabije capaciteit, native multimodaliteit, een miljoen-token context en open gewichten nu in één enkele release verschijnen tegen een fractie van de kosten — en die combinatie bestond een week geleden niet.
Als je agents bouwt, dit is je komende 24 uur: trek M3 op op OpenRouter, pak exact dezelfde vijf taken die je vorige week op je huidige model hebt uitgevoerd, en draai ze naast elkaar. Vertrouw niet op mijn inschatting, vertrouw niet op MiniMax' presentaties. Draai je eigen vuurproef. Kom me dan vertellen of de open frontier zojuist is gearriveerd — want vanwaar ik zit, lijkt het erop.
Veelgestelde vragen
Is MiniMax M3 echt open-weight en gratis te gebruiken?
MiniMax M3 is open-weight, en de gewichten worden naar verwachting binnen ongeveer tien dagen na de lancering van 1 juni 2026 publiek vrijgegeven op Hugging Face en GitHub. De API is niet gratis — het kost $0,30/M input en $1,20/M output tijdens de lanceringsactie — maar een codeplatform biedt gratis M3-toegang, en zelfhosting wordt mogelijk zodra de gewichten verschijnen.
Verslaat MiniMax M3 GPT-5.5 en Opus?
MiniMax M3 zou GPT-5.5 nipt overtreffen op SWE-bench Pro (59,0% vs. ~58,6%), maar dat is een statistisch gelijkspel, geen duidelijke overwinning. Het verslaat Opus niet in coding — Opus leidt met ruwweg 69,2% op dezelfde benchmark. De correcte framing is "M3 nadert de propriëtaire frontier", niet "M3 is de nieuwe koning".
Hoe groot is het contextvenster van MiniMax M3?
MiniMax M3 ondersteunt een contextvenster van maximaal 1.048.576 tokens (1 miljoen), met een gegarandeerd bruikbaar minimum van 512.000 tokens tegen het standaardtarief. Verzoeken boven 512K tokens worden gefactureerd tegen het langcontext-tarief van ruwweg het dubbele van de standaard tokenprijs, dus de tweede helft van het venster kost meer. Zie het toegangsgedeelte hierboven voor kostenplanning.
Hoe krijg ik toegang tot MiniMax M3?
Je kunt MiniMax M3 benaderen via de MiniMax API, het MiniMax-codingplatform/CLI en OpenRouter (minimax/minimax-m3), waarbij zelfhosting beschikbaar komt zodra de open gewichten worden vrijgegeven. OpenRouter is de snelste manier om het te testen tegen modellen die je al gebruikt. Zie het toegangsgedeelte hierboven voor de volledige setup-handleiding.
Is MiniMax M3 goed voor front-end en UI-coding?
In MiniMax' lanceringssvergelijkingen produceerde M3 schoner, meer productiegericht front-end output dan Qwen's nieuwste Max-model en minder bugs dan Gemini Flash op dezelfde prompts — sterke lay-out-discipline, werkende animaties en coherente componentstructuur. Verifieer het op je eigen UI-taken voordat je het als standaard aanneemt.
Laten we samenwerken
Op zoek naar het bouwen van AI-systemen, het automatiseren van workflows of het opschalen van je tech-infrastructuur? Ik help graag.
- Fiverr (maatwerkprojecten & integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (bedrijfsoplossingen): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io