First impressions of M3 for code work

I’ve been using MiniMax M3 for code work for about a week. The model launched last month. Here’s the honest first impression.

What M3 is

M3 is MiniMax’s flagship model. It runs in the Mavis / MCode product line, the same family I use daily. The pitch is “good enough for most code work, much cheaper than the frontier models.” The cheaper is real. The “good enough” depends on what you’re doing.

What M3 is good at

The boring 80%. Refactor this loop. Add type hints to this file. Update the imports. Write the boilerplate. M3 does this fast and cheap. The diffs are tight. The model doesn’t try to do anything clever. The “do exactly what was asked” pattern is M3’s strength.

Multi-turn work in long sessions. M3 has good context management. I had a 40-turn session refactoring a module and the model stayed coherent the whole time. Earlier miniMax models I tried would lose the thread by turn 15. M3 doesn’t.

Reading code and summarizing. “What’s this 800-line module doing?” M3 gives a clean 4-paragraph summary that captures the structure. The summary is accurate. I use this all the time for code I’m inheriting.

Tests, docstrings, and other structured output. When the output has a clear template (a test function, a docstring, a CHANGELOG entry), M3 nails it. The model follows the template. The output is consistent across calls.

What M3 is not good at

Open-ended bug hunts. When the bug isn’t mechanical, M3 is the wrong tool. The model will guess. The guess will be a reasonable guess. The reasonable guess will be wrong. Use Claude or GPT-5 for bug hunts.

Architecture decisions. “Should this be a library or a service?” M3 will give you a pros-and-cons list. The list is fine. The list doesn’t make the decision. The decision requires context M3 doesn’t have.

Anything that needs the model to “go read the codebase.” M3 is good at one-file or two-file work. M3 is not good at “go figure out what’s going on in this 50k-line monorepo.” The model doesn’t have the right kind of context-building for that.

Code that has to integrate with a system M3 hasn’t seen. New SDKs, niche libraries, internal frameworks. M3 will produce something plausible. The something plausible will be subtly wrong. Use a model that’s seen the system for that.

The cost difference

M3 is roughly 1/8 the cost of Claude Sonnet 4.5 for input tokens and 1/6 the cost for output tokens. For the boring 80% of work, that’s a real saving. For the work where M3 is the wrong tool, the saving is irrelevant because I’d use a different model anyway.

The cost difference means I default to M3. If M3 fails, I escalate to Claude. The escalation is rare. The cost is dramatically lower.

The workflow

The workflow that works:

Open M3 for the small change
Read the diff
If the diff is good, approve
If the diff is bad (wrong approach, hallucinated API, off-topic), escalate to Claude
If Claude also fails, do it myself

The escalation is rare. Maybe 1 in 10 sessions. The other 9 are M3 doing the work at 1/8 the cost.

The thing I was wrong about

I assumed M3 would be like the earlier miniMax models (a few years back): fast, cheap, and bad. M3 is fast, cheap, and good enough. The “good enough” is the surprise. The model is not a frontier model. The model is not trying to be a frontier model. The model is trying to be the cheap default for the boring 80% of code work. On that, it succeeds.

The honest summary

M3 is the cheap default for code work. Use it for refactors, boilerplate, tests, docstrings, and the long tail of small changes. Don’t use it for bug hunts, architecture decisions, or anything that needs the model to reason about a large unfamiliar codebase.

The cost saving is real. The quality is good enough for the work it’s good at. The model is the right tool for the right job, and the right job is most of the work I do.