Hands-on tests of MiniMax's unreleased M3.1 Flash coding model via its M-Code terminal agent, covering drone JSON logic, a 3D game build, and a SQL bug hunt.
What is MiniMax M3.1 Flash? #
MiniMax M3.1 Flash is an unreleased multimodal coding model from MiniMax, currently only reachable through a preview build of the company’s own terminal coding agent, M-Code (also written MiniMax Code). It ships with a 1 million token context window and a tunable thinking depth that can be adjusted on the fly from low to max, letting a developer trade speed for reasoning depth mid-session rather than committing to one mode for an entire task.
TL;DR #
-
MiniMax M3.1 Flash is a multimodal coding model still in preview, accessible only through MiniMax’s own coding plan and the M-Code terminal agent, not yet available as open weights.
-
The model supports a 1 million token context window and lets users adjust thinking depth (low to max) during a session instead of locking it in beforehand.
-
In a drone decision test requiring strict JSON output, the model correctly read a low battery level, identified a landing hazard, and chose a safe landing pad, though it missed the exact position of a thin power line.
-
A full autonomous build task (a “floor is lava” 3D game using Blender scripting and Godot) produced a playable game with working movement, jumping, and lava mechanics, but a broken camera angle.
-
In a SQL debugging test on a six-join legacy DB2 query, the model found a boundary-date bug almost immediately, matching the expected fix.
-
The M-Code agent itself stood out for speed and visibility into its own work, giving the tester more control (including mid-task pausing) compared to other terminal coding agents.
-
MiniMax says it plans to release M3.1 Flash as open weights on Hugging Face, though no date was confirmed at the time of testing.
-
✕a coding agent
-
✕no-code
-
✕vibe coding
-
✕a faster Cursor
The one that tells the coding agents what to build.
How does M-Code, MiniMax’s terminal agent, work? #
M-Code is MiniMax’s own command-line coding agent, built to run models like M3.1 Flash directly from a terminal session rather than a chat window or IDE plugin. Setup follows a familiar pattern for this category of tool: install the binary, source it into your shell profile, authenticate with an API key tied to a MiniMax coding plan, and launch it with a single command. Once running, it presents a model picker where M3.1 Flash Preview appears as a selectable option, and prompts (including file paths and image paths) are typed directly into the session.
Functionally, M-Code resembles other autonomous terminal agents in the current wave of coding tools: you hand it a goal, it can request permission to execute actions in bulk, and it works through multi-step tasks like file creation, verification, and self-checking before handing the result back. What distinguishes it, at least in this early test, is responsiveness. Tasks that might take competing agents a long while to loop through were resolved quickly, and the system’s record of what it had already done was easy to inspect without digging through logs. The agent also supported pausing a goal mid-task, which gives developers a way to intervene rather than letting a long-running job run unsupervised to completion.
What happened in the drone decision test? #
The first test asked M3.1 Flash to act as a decision module for a drone, using a single camera frame as input. The scenario was deliberately loaded with competing signals: battery at 18%, a thin power line stretched across a road, a person standing with arms raised (a possible abort or emergency signal), and a red “H” landing pad to one side. The model was told to return strict JSON only, with no explanatory text, and to weigh the low-battery rule against the obstacle.
The output was valid JSON and got the core decision right: it read the 18% battery figure, factored in the low-battery rule, noted the person’s raised arms as a possible signal, and chose to land on the marked pad instead of continuing over the road. It also flagged the power line as a hazard. The miss was positional. It described the wire as being to the left of the flight path, when the wire actually ran across the width of the road and was only faintly visible in that frame. The model also skipped a hover or ascend step before landing, going straight to a landing decision. For a single-frame reasoning task with conflicting priorities, the output was judged accurate on substance even if the spatial detail wasn’t exact.
How did the 3D game build test go? #
The second test was a much larger, more open-ended ask: build a “floor is lava” style game entirely from scratch, using Blender scripting to generate 3D furniture assets and Godot to assemble the actual game, with no human intervention beyond approving the agent’s permissions. Requirements included player movement, jumping, rising lava, a countdown timer, and a game-over state, plus a self-check step before the agent declared the task finished.
The build took around 30 minutes end to end, including file creation and the model’s own verification pass. The result was a playable game: movement and jumping worked, the floor-is-lava mechanic functioned (touching the ground ended the attempt), and furniture objects like a sofa were present as safe platforms. The weak point was the camera. The viewing angle made it hard to judge jumps and distances, leading to accidental “deaths” that looked more like a camera problem than a physics or logic failure. For context, other models tested on similar benchmarks (Anthropic’s Claude was mentioned as a comparison point) have handled camera orientation more cleanly on comparable tasks. The underlying game logic held up; the presentation layer didn’t.
Can M3.1 Flash actually find real bugs? #
The third test targeted a different skill: finding a subtle, intermittent bug in a long legacy SQL query. The setup was a DB2 materialized query with six joins and a bug that only manifests on a handful of days per year, the kind of defect that’s notoriously hard to spot by reading code top to bottom. The model was given only the symptom (a value running slightly too high) and the query file, referenced in M-Code using an ”@” file-pointer syntax, with no hint about where the problem lived.
The model located the issue almost immediately, identifying an inclusive date-range condition on an FX (exchange rate) field as the source of a boundary-date double count. It also correctly pointed to the use of a particular text-based join as supporting evidence for its diagnosis. The explanation matched the known answer key for the bug, and the speed of the result stood out as much as the accuracy.
Is MiniMax M3.1 Flash worth watching? #
Based on these three tests, the model performed well on reasoning-heavy and detail-sensitive tasks (the JSON decision logic and the SQL bug) and reasonably well on an ambitious generative build task, with the main shortfall being a camera implementation detail rather than core logic. None of the three tests exposed a fundamental reasoning failure; the misses were narrow (a wire’s exact position, a camera angle) rather than conceptual. Combined with a 1 million token context window and adjustable thinking depth, the model looks capable for coding and multimodal reasoning work, though it remains gated behind MiniMax’s own paid coding plan for now, with no confirmed public release date for open weights.
Frequently Asked Questions #
Is MiniMax M3.1 Flash publicly available?
Not yet. As of this testing, it’s in preview and only accessible through MiniMax’s own coding plan, used via the M-Code terminal agent and API. MiniMax has indicated it plans to release the model as open weights on Hugging Face, but no firm date has been confirmed.
What is M-Code and how is it different from other coding agents?
Remy doesn't build the plumbing. It inherits it. #
Other agents wire up auth, databases, models, and integrations from scratch every time you ask them to build something.
Remy ships with all of it from MindStudio — so every cycle goes into the app you actually want.
M-Code is MiniMax’s own terminal-based coding agent for running its models on real development tasks. In hands-on testing it stood out for being fast, giving clear visibility into completed steps without needing to dig through logs, and allowing a task to be d mid-run, offering more control than some competing agents that can get stuck in long processing loops.
What context window does M3.1 Flash support?
The model supports a 1 million token context window, large enough to handle long files, extended conversations, or large codebases in a single session.
Can the model’s thinking depth be adjusted during use?
Yes. M3.1 Flash offers tunable thinking depth ranging from low to max, and this can reportedly be changed on the fly within a session rather than being fixed at the start.
How did the model perform on debugging versus creative build tasks?
It performed strongly on analytical tasks like spotting a subtle SQL bug and reasoning through a drone decision scenario with structured JSON output. On a larger generative task (building a full 3D game), it succeeded on core mechanics but fell short on polish, specifically camera positioning, suggesting stronger performance on precision reasoning than on holistic creative execution.