MiniMax M3.1 is a name you need to handle carefully. There's no official MiniMax M3.1 page, model card, API ID, or release post. What does exist is the public MiniMax M3 and a separate rumor about a new model with 2.7 trillion parameters, which sources at The Information call the internal M3 Pro.
So the correct framing is this: MiniMax M3.1 isn't a confirmed release — it's a convenient market label for an expected next iteration of the M3 line. If it does ship, it might be called M3.1, M3 Pro, or something else entirely.
What already exists: MiniMax M3
MiniMax M3 officially launched on June 1, 2026. It's an open-weight model built for coding, agentic workflows, long context, and native multimodal input.
Key characteristics of M3:
- around 428B total parameters;
- around 23B active parameters;
- Mixture-of-Experts;
- 1M-token context;
- input: text, image, video;
- output: text;
- MiniMax Sparse Attention;
- thinking modes;
- API, Token Plan, MiniMax Code;
- weights on Hugging Face and GitHub.
The main technical highlight is MiniMax Sparse Attention (MSA). MiniMax claims that at 1M context, M3 cuts per-token compute to 1/20 compared to the previous generation, speeds up prefill more than 9x, and decoding more than 15x.
That matters more than it sounds: agentic coding often struggles not because the model "doesn't know" something, but because of the cost of long context and the volume of tool output. MSA targets exactly that.
What is M3.1 / M3 Pro
In July, The Information reported that MiniMax is working on a new large language model with 2.7 trillion parameters. According to sources, it's known internally as M3 Pro, could ship as early as the third quarter of 2026, and is planned for open source / open weights release.
Chinese media, including Sina/IT Home, picked up the same story: the new model is expected to be significantly larger than the current M3 and better suited for complex reasoning and multi-step tasks.
This is where "MiniMax M3.1" comes in. If the team ships a strengthened M3 branch rather than a fully new M4, the market may end up calling it M3.1. But for now it's unofficial.
Why MiniMax might go to 2.7T
Competitors are pushing from every direction. DeepSeek V4-Pro claims 1.6T total. Qwen 3.8-Max-Preview — 2.4T. Kimi K3 — 2.8T. In that environment, MiniMax M3's 428B is still useful, but looks less "frontier" in scale.
MiniMax needs to preserve three strong points:
- open-weight availability;
- long context;
- a practical coding/agentic profile.
If a 2.7T M3 Pro keeps the MSA approach and delivers better reasoning without a catastrophic cost increase, it won't just be "more parameters" — it would be an attempt to get back into the top tier of the open-weight race.
What we'd want to see in M3.1
First — more stable long-horizon coding. M3 already does a lot, but the next step shouldn't just be a benchmark score, it should be fewer breakdowns across 100+ tool calls.
Second — better verification. MiniMax Code uses an Agent Team and a Producer + Verifier loop. It would make sense for M3.1/M3 Pro to split generation and checking more sharply: one agent writes, another aggressively hunts for errors.
Third — less hallucinated tool usage. This is a classic pain point in coding agents: the model confidently calls a file that doesn't exist, misreads a log, or patches a symptom instead of the cause. A larger, better post-trained M3 could improve this.
Fourth — clear multimodality. M3 accepts images and video, but the next version needs to prove its value on practical tasks: bug screenshots, UI refactoring, analysis of screen recordings, technical diagrams.
Where the skepticism lies
2.7T is a huge size. Even with fewer active parameters, inference will be demanding. Open weights don't equal cheap local runs. Most teams will still rely on a cloud API or providers.
Another issue is naming. If the release ships as M3 Pro rather than M3.1, articles titled M3.1 will need updating. So it's worth stating upfront: "M3.1 is a working label for the rumor, not an official name."
And finally, independent testing is needed. Vendor-reported SWE-Bench and Terminal-Bench numbers are useful, but a production decision has to be made on your own codebase.
Take
MiniMax is in an interesting spot right now. M3 is already a genuinely strong release: open weights, 1M context, MSA, coding focus. But the open-weight frontier has accelerated, and M3 has quickly stopped looking like the biggest model around.
If MiniMax M3.1 turns out to be a 2.7T M3 Pro, it will be a statement: "we don't just build practical models, we can also compete in the top weight class." Success will depend not on parameter count but on whether the M3 economics survive: long context, usable agents, reasonable cost, and accessible weights.
On GPTunneL it's worth testing such a model on the tasks where M3 already excels: large repositories, refactoring, multimodal inputs, and agentic chains. If the gain shows up only in nicer-looking reasoning, it's a weak update. If it shows up in completed tasks, that's a different conversation.