MiniMax Quietly Slips M3.1-Flash-Preview Into Its Coding Tool
MiniMax quietly rolled out M3.1-Flash-Preview inside MiniMax Code, a lighter sibling to M3 aimed at fast, cheap daily coding work with tunable reasoning effort.
- MiniMax quietly launched M3.1-Flash-Preview inside MiniMax Code, no formal announcement yet.
- New reasoning_effort field with five tiers: low, medium, high, xhigh, max.
- Leaked architecture notes point to all-sparse attention and 4-bit KV plus experts.
- DSpark replaces the EAGLE-style speculative decoding head from M3.
- Aimed at fast everyday coding, not long-horizon agent runs.
- API endpoint still gated; only accessible through MiniMax Code today.
MiniMax has quietly added M3.1-Flash-Preview to the model picker in MiniMax Code. The model appears alongside MiniMax-M3, M2.7, and M2.7-highspeed, with the reasoning level set to max by default. Its apparent target is everyday coding work that benefits from lower latency, including bug fixes, reviews, and small features.
MiniMax has not published an announcement, model card, benchmark report, price, or public API identifier. Existing MiniMax Code users can select the preview in the product, while production integrations and broader access remain unavailable.
A launch confined to the model picker
| Item | Current status |
|---|---|
| MiniMax Code | Selectable for users with access |
| Default reasoning level | max |
| Public API | No published model ID |
| Pricing | Not published |
| Benchmarks | No official or independent results |
| Weights | Associated repository appears gated |
| Broader rollout | No schedule announced |
Five reasoning levels replace one switch
MiniMax Code now exposes low, medium, high, xhigh, and max reasoning levels for M3.1-Flash-Preview. M3 previously presented a simpler thinking toggle. The expanded control should let developers trade response time and compute for additional deliberation on each request.
Lower settings are likely to suit quick edits and routine tool calls, while higher settings may help with planning, debugging, and repository-wide changes. MiniMax has not documented the compute budget, latency profile, or quality difference for each tier, so teams will need to measure those settings against their own tasks.
A leaked design favors throughput
A circulating document described as a partner architecture note outlines several changes from M3. Its provenance and accuracy remain unverified, and MiniMax has not publicly commented on the specifications. If the document reflects the deployed model, the design concentrates on reducing memory traffic and accelerating token generation.
| Reported change | Technical detail | Likely effect |
|---|---|---|
| All-sparse attention | The three full-attention anchor layers used by M3 are reportedly replaced with MiniMax Sparse Attention layers. | Each token attends to a selected subset of context, reducing work on long sequences. |
| Q8KV4 precision | Queries use FP8, while keys and values use 4-bit E2M1 blocks of 16. | The key-value cache would require roughly half the memory of M3’s reported 8-bit path. |
| W4A4 NVFP4 experts | Routed mixture-of-experts weights and activations use 4-bit precision, with separate scaling schemes for FC1 and FC2. The shared expert retains higher precision. | Lower memory use and bandwidth requirements could improve serving throughput. |
| DSpark speculative decoding | A Markov draft head reportedly replaces M3’s EAGLE-style multi-token prediction head. The draft component is listed as a separate 2.3 GB FP8 artifact. | A small draft model proposes tokens for the main model to verify, potentially increasing generation speed. |
reasoning_effort field |
The request field accepts low, medium, high, xhigh, or max, then inserts the choice into the system prompt as an effort tag. |
Applications could vary reasoning effort by step if the field reaches the public API. |
The same material points to a gated, approximately 250 GB Hugging Face repository named MiniMax-M3.1-preview-private. Public metadata and a circulating partner document can indicate development direction, but they do not establish the final production architecture or its performance.
Why MiniMax wants a Flash tier
MiniMax describes MiniMax M3 as a 428-billion-parameter mixture-of-experts model built for long-context and agentic workloads. A mixture-of-experts system routes each token through a subset of its parameters, which reduces active computation relative to the total parameter count.
According to the company, M3 uses one-twentieth of its predecessor’s per-token compute at a one-million-token context, with more than ninefold faster prompt processing and more than fifteenfold faster decoding. Its scale and long-horizon design still impose substantial serving demands for short, iterative coding tasks.
The reported M3.1 changes would address that workload through sparse attention, 4-bit expert and cache formats, and a lighter speculative decoder. Together, those techniques could lower serving costs and improve interactive latency. Published measurements are required to determine the actual gains.
Where the preview fits
| Workload | Reasoning tier to test | Rationale |
|---|---|---|
| Point fixes and small refactors | low or medium |
Fast response time usually matters more than extended planning. |
| Code review and debugging | medium or high |
Additional reasoning may help trace dependencies and failure paths. |
| Agent planning | high or max |
Multi-step plans benefit from a larger deliberation budget. |
| Tool-call glue and formatting | low |
Structured, narrow tasks rarely need the highest setting. |
| Million-token or multimodal agents | Use documented M3 capabilities | MiniMax has not specified the preview’s full context and modality support. |
Tier labels do not reveal token budgets or guarantee consistent behavior across tasks. Developers evaluating the preview should record latency, completion quality, tool-call accuracy, and failure rates at each level. The default max setting may obscure the speed benefits suggested by the Flash name.
The evidence still missing
- A public model card covering architecture, context length, modalities, safety testing, and known limitations
- An API model ID with documented request fields and rate limits
- Input, output, cache, and reasoning-token pricing
- Reproducible coding, latency, and long-context benchmarks
- A public weights repository or a clear statement that the model will remain hosted
Production adoption depends on those details. Until MiniMax publishes them, M3.1-Flash-Preview is best evaluated inside MiniMax Code, away from build pipelines and other systems that require stable identifiers, documented behavior, and support commitments.
Comments
