MiniMax M3.1 Flash puts Space Bunny back under test

MiniMax M3.1 Flash puts Space Bunny back under test

3 min read

MiniMax says M3.1 Flash brings 1M context, multimodal inputs, low API pricing, and weights on Oct. 23. The interesting part is not the leaderboard drama. It is whether a large sparse model can be cheap enough to serve and small enough to run locally.

TL;DR: MiniMax M3.1 Flash is worth testing because it combines cheap API pricing, 1M-token context, multimodal input, and promised open weights, but the benchmark and parameter claims need verification once the model card and weights land.

What did MiniMax actually announce?

MiniMax announced MiniMax-M3.1-Flash, and its own Text Generation docs list the practical hooks builders care about: 1M-token context, configurable thinking effort, text generation support, and pricing reported in the LocalLLaMA discussion as $0.15 per 1M input tokens, $0.60 per 1M output tokens, and $0.015 per 1M cache reads.

MiniMax also said weights are coming on Oct. 23. That is the line that changes this from “another cheap API model” into something local-model people will actually plan around.

The other headline is identity. MiniMax says Space Bunny, the stealth model that showed up on OpenRouter in late September, was an earlier version of M3.1 Flash. LocalLLaMA users reported that Space Bunny sat at number one on OpenRouter for about 10 days, then disappeared on Oct. 5. That makes the launch feel less like a cold debut and more like a model graduating from a public blind test.

Still, a few details are muddy. One LocalLLaMA post says the launch post gives 428B total parameters and 23B active parameters. Another says parameter count has not been given. That is exactly the kind of mismatch I would not build around yet. Wait for MiniMax’s model card, repo, and weight files.

large sparse model split between cloud api path and local hardware path, with the same model core feeding both

Are the benchmark claims useful yet?

Useful, yes. Settled, no.

MiniMax’s reported numbers put M3.1 Flash at 62% on Automation-Bench, 30% on ALE, 74% on DeepSWE, and 91% on BabyVision. Another LocalLLaMA post says MiniMax claims it beats Opus 5 on Automation-Bench, roughly ties DeepSeek V4.1 Flash on DeepSWE, and loses clearly to Opus 5 on Terminal Bench, 38.1 versus 51.8.

That pattern is believable in the boring sense: strong on some automation and software tasks, not dominant everywhere. It also matters that these are MiniMax’s own numbers. Treat them as a test plan, not a verdict.

The DeepSWE discrepancy is a good warning light. One post says MiniMax had DeepSeek at 77.0 in text and 74.2 in a table. Maybe that is a typo. Maybe it is benchmark-version confusion. Either way, if your workflow depends on code editing, repo navigation, shell use, or long-horizon agent behavior, do not stop at a leaderboard screenshot. Run your own tasks.

Why local builders are paying attention

The interesting bet is sparse scale. If the 428B total and 23B active numbers hold, M3.1 Flash would sit in the category local users obsess over: huge total capacity, smaller active compute per token. That can make a model feel much larger than its runtime cost, at least when routing and kernels behave.

LocalLLaMA users are already doing napkin math. One estimate puts a Q4 quant somewhere around 230 to 250 GB, which is why 256 GB Mac Studio owners perked up. That is not a MiniMax spec. It is community math, and it depends on the actual weights, quantization approach, MoE layout, and runtime support. Unsloth quants, llama.cpp support, MLX support, and vLLM behavior will matter as much as the launch tweet.

My first test would be simple: take three jobs where long context and low cost both matter. A messy repo audit. A long document extraction task with citations. A browser or desktop automation trace where the model has to follow state over many steps. Run M3.1 Flash through the API now, save the prompts and outputs, then rerun the same set against the open weights after Oct. 23 if MiniMax ships them. The catch most readers miss: cheap tokens and local weights are only useful if the model stays reliable under your actual task shape, not the benchmark shape.