The number everyone is repeating is 2.7 trillion. The number that will actually decide whether MiniMax M3 Pro matters to your team is not that one — it's a clause in a LICENSE file that nobody has read yet, because nobody has published it yet.
I went looking for a technical breakdown of M3 Pro last week and found about twenty articles. All of them were reprints of the same scoop. None of them answered the only question a working developer has: so what do I do on Monday? This piece is my attempt at that answer.
One thing before we start, because it matters more than usual here. I'm going to mark three different kinds of statement throughout: what has been reported (thin sourcing, treat with care), what I think (my read, argue with me), and what is speculation (I'll say so out loud). Almost everything published about M3 Pro so far blends all three into one confident voice. That's how a rumor becomes a roadmap.
What Is MiniMax M3 Pro? (What's Actually Confirmed)
MiniMax M3 Pro is a large language model that does not exist yet — at least not publicly.
Here is the reported version. MiniMax, the Shanghai lab behind the M-series, is working on a model with roughly 2.7 trillion parameters. Employees involved with the project refer to it internally as M3 Pro, though the final name may change before launch. The company plans to release it as open source, possibly as early as Q3 2026. If it lands as described, it would be the largest open model any Chinese lab has published.
Now the sourcing, which is the part the reprints tend to skip. All of the above traces back to a single exclusive from The Information, dated July 8, 2026, attributed to two people with knowledge of the plan. Every subsequent story — and there are many — is downstream of that one report. MiniMax itself has said nothing. I checked the company's site, its research blog, its API documentation, and its Hugging Face organization on the day of writing. There is no mention of M3 Pro anywhere on any of them.
| |
Status |
| 2.7T total parameters |
Reported (single source) |
| Named "M3 Pro" |
Reported — internal codename, may change |
| Open-source release |
Reported as the plan |
| Q3 2026 timing |
Reported as "as early as" — not a commitment |
| Active parameter count |
Unknown |
| License terms |
Unknown |
| Context window |
Unknown |
| Benchmark results |
None exist |
| Available on any API |
No |
That table is the honest state of knowledge. Everything else you read about M3 Pro right now, including everything below this line, is inference built on top of it.
MiniMax M3 Pro vs MiniMax M3: What the 6× Jump Actually Buys You
To understand why a 2.7T model is even interesting, you need to know what MiniMax already shipped.
MiniMax M3 came out on June 1, 2026. It's a Mixture-of-Experts model with approximately 428 billion total parameters and about 23 billion activated per token. Its defining piece of engineering is MSA — MiniMax Sparse Attention — which selects the key-value blocks that matter instead of attending across every token in the window. That's the reason its million-token context is a working feature rather than a spec-sheet trophy: at 1M context, MSA cuts per-token compute to roughly one twentieth of the previous generation, with prefill about 9× faster and decode about 15× faster. The technical report is on arXiv (2606.13392) and the weights are on Hugging Face.
So M3 Pro, at a reported 2.7T, would be about 6.3× larger than M3 on total parameters. That sounds decisive. It isn't, and here's why.
| |
MiniMax M3 (shipped) |
M3 Pro (reported) |
| Total parameters |
~428B |
~2.7T |
| Active parameters per token |
~23B |
Unknown |
| Architecture |
MoE + MSA sparse attention |
Unknown |
| Context window |
1M (512K guaranteed minimum) |
Unknown |
| Release |
June 1, 2026 |
Targeted Q3 2026 |
| Weights |
Published |
Planned |
In a Mixture-of-Experts model, the total parameter count tells you how much memory you need to own. The active parameter count tells you how much you pay per token. M3 activates 23B out of 428B — about 5%. If M3 Pro holds a similar ratio, you're looking at roughly 135B active, which would be a genuinely different cost class. If it activates far fewer, it could be cheap to serve and expensive to store. If it activates far more, the reverse.
Nobody has reported that number. Which means the single most important figure for anyone budgeting around this model is the one figure that hasn't leaked.
Put plainly: total parameters tell you how much hardware you'd need to buy. Active parameters tell you what the bill looks like. Only the first one has been reported, and it's the less useful of the two.
The Word "Open-Source" Is Doing a Lot of Work Here
This is where I want to slow down, because I think it's the part the coverage has gotten meaningfully wrong.
Every headline says "open source." That phrase carries an implication — that you can download the thing, build a product on it, and ship. For MiniMax's recent releases, that implication has not been true.
Look at what actually happened with M3. Its weights are on Hugging Face under a license tagged minimax-community. Not Apache 2.0. Not MIT. A custom license with conditions. How binding are those conditions in practice? Consider that NVIDIA published its own NVFP4-quantized build of M3, and the model card on that build states in plain language that the checkpoint is ready for non-commercial use, with governing terms pointing back to the MiniMax Community License and a requirement to display "Built with MiniMax M3."
That's NVIDIA — a company with a large legal department — reading the license and choosing that wording.
And M3's license was the improved one. The previous release, M2.7, shipped under terms that prohibited any commercial use whatsoever without prior written authorization from MiniMax. The Hugging Face discussion threads from that release are worth reading if you enjoy watching a community and a legal team negotiate in public. MiniMax loosened the terms for M3 in response. They did not make them permissive.
I'm not going to quote specific revenue thresholds from M3's license, because the secondary sources I found contradict each other and this is the kind of detail where being approximately right is worse than being silent. Read the LICENSE file yourself before you build anything commercial on it. That is not a disclaimer; it is the actual advice.
Here is my judgment, flagged as such. If M3 Pro ships under the same family of license, "largest open-source model ever released" is a headline for researchers and a footnote for anyone shipping a product. The weights being downloadable buys you auditability and the right to self-host. It does not automatically buy you the right to build a business on top. Those are different things, and the gap between them is where a lot of teams are going to get hurt in the next six months.
Even If They Ship It, You Probably Can't Run It
Say the license turns out fine. Say it's Apache 2.0 and everybody cheers. There's still a wall.
M3 — the 428B model — is not something you serve from a workstation. Documented full-precision deployments run on eight-GPU NVIDIA B200 class systems. That's the current model, the one people are already calling "the big one."
M3 Pro would be over six times larger.
Downloadable and runnable are different words. I think for the overwhelming majority of teams — including well-funded ones — M3 Pro's open weights will be something you read about rather than something you host. Quantization will help. It will not close a 6× gap for anyone without a data center.
Which leads somewhere slightly awkward but I think correct: for most developers, whether M3 Pro is open-source or closed changes almost nothing about the decision. Either way, you reach it through an API. The open weights matter enormously for researchers, for national AI strategy, for the labs benchmarking against it. For the person shipping a coding agent next quarter, it's a headline, not a plan.
If you're going to be calling models over HTTP regardless, the useful question becomes which ones you can reach through one key and one balance — which is the shape of the full model catalog problem, not the open-weights problem.
The Q3 Timeline Has a Risk Nobody Is Pricing In
Now the part I haven't seen anyone connect, and I want to be careful about how strongly I put it.
On July 7, 2026, Reuters reported that China's Ministry of Commerce had been meeting with major domestic AI players — Alibaba, ByteDance, Z.ai among them — to discuss restricting overseas access to the country's most advanced AI models. The discussions reportedly covered both closed and open-source models, a tiered licensing regime, and stiffer criminal penalties around model distillation.
The Information published the M3 Pro story on July 8, 2026. The day after.
This is speculation, and I'm labeling it as such: I'd treat "Q3, open source" as a plan filed before the weather changed, rather than a commitment you can build a roadmap on. A 2.7-trillion-parameter frontier open model is precisely the category of artifact those Ministry discussions appear to be about. I have no reporting that anyone has told MiniMax to slow down. I'm noting that the two stories landed within twenty-four hours of each other and that not one of the twenty articles I read mentioned both.
The cost of this observation, to be fair to it: none of this means Chinese models are a bad bet. M3 is live right now, benchmarked by independent third parties, and serving production traffic. The narrower point is that betting your architecture on an unreleased model carries a policy risk on top of the ordinary schedule risk. That's true of any lab. It's just more legible here.
What You Can Actually Build Today: MiniMax M3 via API
So: waiting for M3 Pro is a bad plan. Partly because of everything above, and partly because M3 is already very good.
On Artificial Analysis's Intelligence Index (v4.1) — an independent composite covering GDPval-AA, Terminal-Bench, SciCode, Humanity's Last Exam, GPQA Diamond and others — M3's reasoning variant scores 55. That puts it at the top of the open-weight field, level with GPT-5.5 and behind Claude Opus 4.8. Its component scores include 37% on Humanity's Last Exam and 93% on GPQA Diamond. Note the variant distinction: Artificial Analysis lists a lower figure for the non-reasoning configuration, so make sure you know which one a comparison is quoting before you cite it.
MiniMax's own numbers — 59.0% on SWE-Bench Pro, 66.0% on Terminal-Bench 2.1, 83.5 on BrowseComp — are vendor-reported and run on the lab's own infrastructure. Treat them as directionally useful and independently unverified.
To call M3 on GPT Proto, the endpoint follows the OpenAI chat format. One gotcha that will cost you twenty minutes if you miss it: the API key goes into the Authorization header directly, with no Bearer prefix. Most SDKs add that prefix automatically.
First call, cURL:
curl --location 'https://gptproto.com/v1/chat/completions' \
--header 'Authorization: YOUR_GPTPROTO_API_KEY' \
--header 'Content-Type: application/json' \
--data '{
"model": "MiniMax-M3",
"messages": [
{"role": "user", "content": "Summarize what MSA changes about attention at 1M context, in three sentences."}
],
"stream": false
}'
Python, using requests so the auth header is unambiguous:
import os
import requests
API_KEY = os.environ["GPTPROTO_API_KEY"]
response = requests.post(
"https://gptproto.com/v1/chat/completions",
headers={
"Authorization": API_KEY, # no "Bearer " prefix
"Content-Type": "application/json",
},
json={
"model": "MiniMax-M3",
"messages": [
{"role": "user", "content": "Refactor this function for readability:\n\n" + open("main.py").read()}
],
"stream": False,
},
timeout=600, # long-context prefill is slow; don't use the default
)
response.raise_for_status()
print(response.json()["choices"][0]["message"]["content"])
If you prefer the OpenAI SDK, point base_url at https://gptproto.com/v1 and override the header rather than passing the key through api_key, or the client will prepend Bearer for you.
On cost, the MiniMax M3 model page lists $0.48 per 1M input tokens and $0.96 per 1M output tokens. Those are the numbers; I'm deliberately not turning them into a savings percentage, because the honest comparison depends on your input/output ratio and there are configurations where the arithmetic goes either way.
The cost detail that will actually surprise you is not the per-token rate. It's the context cliff. M3's window is 1M tokens, but the guaranteed minimum is 512K — and on MiniMax's first-party pricing, crossing 512K of input reprices the entire request at double the standard rate. Not the overflow. The whole call. A 600K-token request doesn't cost slightly more than a 500K one; it costs roughly twice as much per token across the board.
That matters most in agent loops, where context accumulates turn over turn and nothing gets pruned. By turn fifteen you can be paying the long-context rate not because any single step needed a million tokens, but because you never trimmed. Prune your context. It's a bigger lever on your bill than the model you pick. (If you're evaluating M3 specifically for coding workloads, we went deeper on the benchmark and pricing math in a separate piece.)
If M3 Pro Ships, What Changes for You?
Less than you'd think, if you set things up correctly now.
At the aggregation layer, switching models is a string change:
MODEL = os.environ.get("LLM_MODEL", "MiniMax-M3") # not hardcoded
That's the whole migration, assuming the request shape stays OpenAI-compatible — which, across every M-series release so far, it has.
So here's the cost of the advice, stated honestly: do not re-architect anything for a model that has no announced specs, no license, no benchmarks, and no confirmed ship date. The correct amount of preparation for M3 Pro is one line — pull your model ID out into config and stop hardcoding it. Anything beyond that is planning around a rumor.
In one sentence: M3 Pro is a reported plan worth watching and a terrible thing to wait for; M3 is a shipped model at the top of the open-weight leaderboard that you can call today.