2048 tokens. That is how many MiniMax M3 spent thinking about Mumbai local trains before it ran out of budget and produced absolutely nothing. The model chewed through its entire output window on reasoning tokens — those internal <think> tags you never see — and left me staring at a blank response. Not a truncated paragraph. Nothing.
This is the defining quirk of M3. It thinks hard. Sometimes too hard. But here is the thing about a model that overthinks: when you give it enough room, what it produces is genuinely good. And when you give it code to write and tests to pass, it does something most cheap models cannot — it reads its own failures, diagnoses them, and fixes them without being told what went wrong.
85 out of 85 tests. Four real projects. Approximately one penny. Those are the numbers that matter about MiniMax M3.
The creative writing disaster that tells you everything
Before I get to the code, the Mumbai trains story deserves a proper telling. I asked M3 to write a short essay about Mumbai’s local train network — a creative task, nothing technical. The model started reasoning. And reasoning. And reasoning. It explored the history of the railway, the different lines, the cultural significance, the crowd dynamics. All inside the <think> block. By the time it was ready to actually write the essay, it had burned through 2048 tokens of thinking and had zero tokens left for the response.
Empty output. The model spent its entire budget planning and never got to execution.
This is not a bug. It is a design choice. M3 uses reasoning tokens by default on every call — 900 to 2000 tokens of internal thinking before it produces a single word you can read. For structured tasks like code generation, this is fine. The thinking produces better output. For creative work, it is a tax you need to account for. Set max_tokens to 4096 or higher for anything long-form, or you will get silence.
The lesson: M3 is built for work, not for poetry. And the work it does is remarkable.
Actual code, not benchmarks
I ran M3 through OpenCode v1.2.27 on four projects. Not playground one-shots. Not “write me a function.” Real coding agent work — the kind where you describe what you want, the model writes the code, runs the tests, reads the failures, and iterates until everything passes.
LRU cache. 13 tests. First try, zero intervention. The model wrote a least-recently-used cache with proper eviction, capacity handling, and edge cases. All 13 tests green on the first run.
Rate limiter. 11 tests. Three failures on the first attempt. The model had miscounted token consumption at 0.5-second intervals — a subtle timing bug that would have taken a developer a few minutes to track down. M3 read the tracebacks, identified the root cause in its test assertions, rewrote them, and passed all 11.
CLI todo app. 20 tests. All green on the second run. The first attempt had a capsys buffer bug — previous test outputs were leaking into later assertions. The model diagnosed the buffer contamination, added a drain call, and fixed it. 20 out of 20.
Mini web framework. 41 tests. This was the hardest project. The model’s first attempt used an integer converter that relied on catching ValueError at runtime instead of using regex pattern matching. When the tests exposed the fragility, M3 refactored the entire converter architecture — not just the broken part, but the whole system — into a typed converter approach. 41 out of 41.
Total: 85 tests across four projects. All passing.
The self-debugging pattern that matters
What impressed me was not the final scores. It was the debugging. M3 does not write code and hope. It reads tracebacks the way a developer reads them — looking for the specific line, the specific assertion, the specific mismatch between expected and actual output.
On the rate limiter, the failure was in timing-sensitive token counting. The model did not just add a tolerance band or fudge the numbers. It went back to its own logic, found that it was not properly accounting for partial-second intervals, and rewrote the counting mechanism.
On the todo app, the failure was sneaky. The capsys buffer was not draining between tests, so output from test 3 would bleed into test 4’s assertion. M3 did not just clear the buffer — it added a drain call at the right point in the fixture, the kind of fix that shows it understood the test lifecycle, not just the error message.
On the web framework, the failure was architectural. A runtime ValueError catch is a hack — it works until someone passes a string that happens to look like a number in the wrong context. M3 recognized this was not a patch situation. It rebuilt the converter with explicit type checking, the way you would if you were reviewing a pull request and told the author to do it properly.
This is the capability that separates a coding agent from a code generator. A generator writes code. An agent writes code, tests it, fails, diagnoses, and iterates. M3 is firmly in the second category.
The pricing that changes the conversation
MiniMax M3 costs $0.30 per million input tokens and $1.20 per million output tokens. That is after a permanent 50% discount for input contexts under 512,000 tokens. Cached input — the kind you get when the model has seen the same codebase before — drops to $0.06 per million.
For context, frontier models from the major labs charge many times more per token. DeepSeek V4 Flash is cheaper but trades off capability. M3 sits in a pricing tier that makes agent loops affordable in a way the big models do not.
My entire four-project test run consumed roughly 13,500 tokens. Estimated cost: $0.01. One penny. For 85 passing tests across a cache, a rate limiter, a CLI app, and a web framework.
The 1M token context window — powered by MiniMax Sparse Attention architecture — means you can feed it entire codebases without worrying about truncation. The model supports native multimodal input, configurable reasoning effort, and will be fully open-sourced on HuggingFace and GitHub for private deployment and fine-tuning.
The reasoning tax you need to know about
Every M3 call burns 900 to 2000 reasoning tokens before producing visible output. This is not optional. The model thinks first, writes second. For coding tasks, this is usually a good trade — the thinking produces cleaner code with fewer bugs. But it has real consequences.
If you set max_tokens to 2048, the reasoning might consume most of that budget. You get a model that spent all its time planning and had nothing left for execution. This is exactly what happened with the Mumbai trains essay. For factual and structured tasks, 2048 is usually enough. For creative work, long-form output, or anything that requires extended generation, you need 4096 at minimum. For real long-form work, 8192 or higher.
Throughput measured at 135 tokens per second total, but the effective output — the stuff you actually read, stripped of reasoning tokens — lands around 40 TPS. Not slow, but not blazing. The model is doing real computation in those thinking tokens, and that takes time.
This is not a deal-breaker. It is a design trade. M3 prioritizes correctness over speed, and in agent workflows where you are running automated test loops, that is exactly what you want.
Where it wins and where it does not
M3 is strong at coding, debugging, tool calling, structured output, and agent decomposition — the tasks that make coding agents useful. It reads tracebacks, refactors its own architecture, and iterates without hand-holding. On BrowseComp, it scores 83.5, surpassing Opus 4.7 at 79.3. On PostTrainBench, it ranks third behind only Opus 4.7 and GPT-5.5 at 37.1. It autonomously reproduced an ICLR 2025 Outstanding Paper in 12 hours, producing 18 commits and 23 experimental figures. It optimized a CUDA FP8 GEMM kernel from 7.6% to 71.3% hardware utilization — a 9.4x speedup — in 24 hours with zero human intervention.
The known weak spot is abstract fluid reasoning. On ARC-AGI-2, the whole family of Chinese models scores in the low single digits. If you need a model that can reason about novel, ambiguous problems with no clear structure, M3 is not your best bet. But if you need a model that can write code, test it, debug it, and ship it — at a price that makes agent loops actually affordable — the gap between “cheap model” and “capable model” has closed.
The cheap model era is not coming. It is here. M3 just proved it with 85 passing tests and a one-penny receipt.