MiniMax M3 Tested Inside Claude Code: What It Can

Benchmark scores are fine. They're a shorthand—a way to compare models without having to actually use them. But the question developers bring to any new model isn't "what's your SWE-bench number?" It's: will this thing actually help me ship?

That's the premise Eric Tech works from in a recent video demonstrating MiniMax M3 inside Claude Code. It's a sponsored video—MiniMax is the sponsor—so the framing is worth holding in mind as you read. That said, the approach he takes is genuinely more informative than a chart: he points Claude Code at the MiniMax API, swaps M3 in as the underlying model, and runs it through a series of real coding tasks. The question he's asking isn't "how does M3 score?" It's "what does it actually feel like to work with?"

That's a useful distinction, and it's worth tracing through what he found.

The Setup: M3 Behind Claude Code

The configuration is straightforward in concept, if a little novel in practice. Claude Code is Anthropic's agentic coding environment—it can read files, run terminal commands, call tools, and operate across a codebase with some degree of autonomy. What Eric does is wire it to the MiniMax API and use M3 as the reasoning engine underneath. Claude Code handles the interface and tool orchestration; M3 handles the thinking.

This matters because it separates two things that often get conflated: the environment (what tools the agent has access to) and the model (what does the reasoning). Testing M3 through Claude Code's tool infrastructure is a reasonable way to stress-test the model's actual capabilities, since the scaffolding is doing the same work it would in production.

It also means you're not evaluating M3 in a vacuum. You're evaluating it in a workflow—which is, as Eric argues, the more honest test.

Context at Scale: The Million-Token Question

One of M3's headline features is its context window. The MiniMax API supports up to 1 million tokens, with a guaranteed minimum of 512,000. For reference, a token is roughly three-quarters of a word—so 512,000 tokens is something in the range of a small novel, or a very large codebase.

The practical value here is about what gets lost when context is limited. In a real codebase, a failing test might trace back through a shared utility, a config file, a database schema, and a component in a completely different directory. Smaller context windows force the model to drop older material as new content comes in—which can break the chain of reasoning mid-task.

Eric's demo involves feeding M3 a repository structure, source files, test output, and issue description simultaneously, then asking it to trace the problem before making any changes. The thing to watch, as he puts it: "Watch whether it keeps the relationships between the files intact. Can it explain where the data enters the system? Can it identify the function that transforms it? Can it connect that function to the failing test?"

That's a good diagnostic. A model that just produces plausible-looking code is different from one that actually understands the system it's modifying.

The architecture behind this is what MiniMax calls "Minimax Sparse Attention" (MSA)—a design that focuses attention on the contextually relevant parts of a large input rather than treating every token as equally important. The practical implication, if it works as described, is that "1 million tokens" isn't just a marketing number; it's potentially usable infrastructure for long-horizon tasks.

Multimodal Debugging: Sending Screenshots Directly

The second workflow Eric demonstrates is one that resonates for anyone who's done front-end debugging: the app runs, but something is visually broken. A layout has shifted. A chart is clipped. A form is displaying the wrong state.

The normal workaround with a text-only model is to describe what you're seeing—which is both tedious and imprecise. With M3's native multimodality, you can send the screenshot alongside the relevant code and ask the model to reason about both at once.

The demo sends an image of a broken interface plus the component code to M3 through the MiniMax API. The model identifies the visual problem, connects it to the implementation, and proposes a fix. Eric's framing here is deliberate: "The model can look at the rendered result and the source code together. It can reason about the difference between what the browser is displaying and what the component is supposed to do."

Native multimodality—meaning the model handles image and text in a unified way, rather than routing to a separate vision system—matters more than it might seem. Switching between models mid-workflow introduces latency, coordination complexity, and potential information loss. A single model that handles both simplifies the architecture considerably.

The Long-Horizon Test: Academic Paper Reproduction

The most ambitious example in the video is also the one where the sponsorship framing is most worth keeping in view. MiniMax describes an internal test where M3 autonomously worked through reproducing experiments from a research paper over an extended session, producing multiple commits and experimental figures while keeping paper content, code, logs, and results in a unified context.

Eric presents this not as a production guarantee but as evidence of the type of task M3 is designed for. His smaller demo version follows the same pattern: send the paper and repository to M3, ask it to summarize the experiment plan, create a checklist, implement missing pieces, run the first experiment, and inspect the output. When things fail—and they will fail—the agent reads the error, updates the code, and tries again.

The broader point is about continuity. As he puts it: "The practical advantage is continuity. The model can keep the original requirements, intermediate findings, code changes, and experiment results available while the task develops."

That's a legitimate capability claim, and it applies well beyond academic research. Service migrations, data pipeline audits, proof-of-concept builds from technical specs—any task with multiple interacting steps benefits from a model that doesn't forget what it was doing three steps ago.

The Benchmark Reality Check

At the end of the video, Eric does surface M3's benchmark numbers. On established coding and agent benchmarks, M3 puts up scores that place it in competitive territory—strong on autonomous information retrieval, solid on coding and terminal execution tasks. On BrowseComp, Eric cites M3 outperforming a Claude result he references, though benchmark comparisons in this space shift quickly and vary by evaluation methodology. Worth treating those numbers as directional rather than definitive.

What's more useful is how he contextualizes them: "Those numbers tell us that M3 is competitive on coding, terminal execution, tool use, and autonomous information retrieval. But the workflow tells us what those capabilities feel like when we apply them to real work."

That's the honest framing. Benchmarks are sampled, controlled, and sometimes optimized for. Workflows are messy, contextual, and closer to what actually matters.

Access and the Open Weights Option

M3 is available through the MiniMax API, with tiered pricing for regular users. It's also released as open weights on Hugging Face, which opens a different set of possibilities. Teams with strong data privacy requirements, specific infrastructure constraints, or workloads that make per-token pricing impractical can self-host. The API is the faster path to evaluation; self-hosting is the path to control.

That dual availability—commercial API plus open weights—is increasingly how frontier-adjacent models are being distributed, and it's worth noting. It lowers the floor for experimentation while giving teams with more specific needs an actual alternative.

One reasonable question this video raises without quite answering: how does M3 hold up when the task goes genuinely wrong? The demos are structured to succeed—they're designed to illustrate capabilities, not probe failure modes. What happens when the context contains contradictory information? When the agent's plan is plausible but wrong? When tool calls return unexpected results?

Those aren't gotcha questions. They're the questions that determine whether a tool earns a place in production. The workflow approach Eric demonstrates is more honest than a benchmark chart—but it's still a demonstration. The only way to answer those questions is to run the model against your actual work.

Which, to be fair, is exactly what he recommends.

Yuki Okonkwo is Buzzrag's AI & Machine Learning correspondent.