MiniMax Agent (Mavis): Architecture, Costs, and Real API Testing

Introduction

There’s a specific kind of blog post every AI lab publishes eventually: the one where an engineering team explains why their new architecture exists, admits what it costs, and tells you when not to use it. Most of these read like marketing wearing a lab coat. MiniMax published one on May 27, 2026, and it’s worth taking seriously enough to actually test rather than summarize.

The question this article answers isn’t “Is MiniMax’s model any good?” That’s a benchmark question with a fairly boring answer (yes, competitively, on paper). The real question is whether wrapping that model in an agent product changes how the work actually gets done, or whether it just moves the same effort somewhere less visible. To answer that, this article treats MiniMax’s own architecture post as a claim to test rather than a fact to repeat, runs a real task against the actual API, and lays out the parts of the MiniMax story that don’t make it into the launch post at all.

Prerequisites for the hands-on section:

• Python 3.10 or newer
• A MiniMax API key
• pip install anthropic python-dotenv

MiniMax’s API speaks the Anthropic message format directly, so if you’ve used Claude’s SDK before, this will feel immediately familiar.

TL;DR

MiniMax Agent was renamed Mavis in May 2026 and rebuilt around Agent Teams — a Leader, Worker, and Verifier — splitting a task instead of one model doing everything alone. MiniMax’s own engineering post is unusually candid that this only pays off on long, verifiable tasks, and their own cited research shows unstructured multi-agent collaboration can cost over three times the tokens with no accuracy gain on simple ones. A real hands-on test against the API backs that up: the value is real but conditional. Separately, teams evaluating this for production work should know about Anthropic’s distillation accusation against MiniMax, the Disney/Universal/WB copyright suit against its video product, and a quiet license restriction on M2.7.

What MiniMax Agent Actually Is Right Now

Before evaluating anything, it’s worth clearing up what’s changed, because a lot of what’s written about “MiniMax Agent” online describes a product that no longer exists in that form. MiniMax first introduced the agent publicly in mid-2025 as a general-purpose assistant for long, multi-step tasks, and it reportedly became a daily tool for over half of MiniMax’s own team within two months of internal use, according to that same launch post.

On May 27, 2026, MiniMax shipped what they call an overall upgrade and gave it a new name: Mavis, short for “MiniMax as a Jarvis.” The headline change wasn’t a bigger model; it was a new way of running the agent, called Agent Teams, where the desktop app can run several agents in parallel, each with a different role, collaborating on one task instead of one model doing everything sequentially. In the same release, MiniMax merged its TokenPlan and Agent Plan subscriptions into a single plan that covers the command-line interface (CLI), the API, and the Agent product under one key and shared credit pool.

There’s also a model generation shift worth knowing before the code section: MiniMax-M2 and M2.5 shipped as fully open-weight models under permissive licenses, but M2.7 broke that pattern. MiniMax released M2.7’s weights on Hugging Face and then quietly updated the commercial terms shortly after, requiring written authorization for commercial use while keeping research and personal use free. The newest model, M3, is the one this article’s code targets, and it introduces MiniMax’s own sparse attention architecture supporting up to a 1 million token context window alongside native multimodal input.

The Architecture Behind the Claim

MiniMax’s engineering post opens with an honest admission: a single agent handling a complex task end-to-end is, in their words, both the judge and the contestant. It writes the output and then checks its own output, which is the same coherence problem that shows up everywhere self-critique gets studied. Their fix is Agent Teams, built around three roles.

1. The Leader takes the user’s goal and turns it into a task structure, deciding whether the job is even worth splitting up in the first place.
2. The Worker executes a specific sub-task, and different Workers get different tools, different context, and different output requirements depending on what they’re doing.
3. The Verifier is the part doing the real work here: it checks sources, coverage, and risk boundaries, and it can send a Worker’s output back for revision. MiniMax describes the Worker and Verifier relationship as deliberately adversarial, similar to how a development team and a QA team both want the project to ship, but neither one is allowed to be the only check on the other.

That structure isn’t unique to MiniMax. It sits in a landscape that already includes OpenAI’s Agents SDK (handoff-based, largely sequential), LangGraph (explicit workflow graphs with a supervisor node), and Claude Code’s Teams feature (a Lead Agent assigning isolated Teammates). What MiniMax’s post argues is different about their version is a persistent state machine they call the Team Engine, which tracks each task through producing, verifying, and done states, and wakes the producing step back up automatically when verification fails, rather than treating multi-agent collaboration as a single function call that returns one block of text.

This is a genuinely more defensible design than “spin up a few agents and let them chat,” and MiniMax’s post is unusually clear that the value only shows up on the right kind of task — which is exactly what the next section tests.

What Actually Changes for the Person Using It

An independent hands-on account from a developer testing MiniMax Agent frames its value around effort minimization rather than raw capability, describing it as designed to progress toward outcomes with minimal internal friction rather than forcing the model through deeply nested planning on every task. That matches the philosophy in MiniMax’s own post almost exactly: their Leader role explicitly asks whether a task is worth splitting at all before doing it, since fixing a typo or swapping a constant is cheaper handled by a single agent or a plain script.

Where the picture gets more honest — and more useful — is in what MiniMax admits the Agent Team architecture costs. Their own post names three specific costs that don’t disappear just because you added more agents. Handoff cost is what it takes to reorganize the same information as it moves from a research agent to a writing agent to a formatting agent, none of it free in tokens or time. Sharing cost is the price of giving every agent visibility into shared context, since every additional shared section costs every worker tokens on every round it’s included. Aggregation cost is the hardest one: it’s easy to generate ten parallel drafts of something, and genuinely difficult to merge them into one document with consistent facts, matching citations, and a single voice.

MiniMax also cites a finding they call the Cost of Consensus, which found that unstructured multi-agent debate among homogeneous models can run 2.1 to 3.4 times the token cost of a single agent correcting its own output, with no improvement in accuracy and sometimes worse results. That number is doing a lot of work in this article, because it’s MiniMax’s own citation, in their own architecture post, arguing against the naive version of the exact product category they’re selling. Their conclusion, stated plainly, is that multi-agent collaboration without real structure is just more expensive concurrency, and structure is the entire point of the Leader, Worker, Verifier split.

There’s a smaller but very concrete detail buried in the same post worth flagging separately: MiniMax names “context anxiety” as a real behavior they observed, where a single long-running agent stops mid-task and asks the user whether to continue, because the model’s own sense of when a task is actually finished gets fuzzy the longer it runs. That’s not a benchmark number; it’s an admitted product bug they built Agent Teams partly to route around, by having a fast-responding Leader confirm the plan up front and then run the actual work asynchronously in the background.

Put together, the honest version of the claim is narrower than the marketing version: work gets easier when the task is long enough and verifiable enough that the cost of running a Leader, several Workers, and a Verifier is smaller than the cost of a single agent drifting, stalling, or quietly shipping something wrong. On short or simple tasks, that same structure is closer to pure overhead.

Hands-On: Building and Running a Real Task Against the API

Theory aside, the fastest way to judge any of this is to actually send a task through the API and watch what it does. MiniMax’s API is Anthropic-compatible, which means the standard anthropic Python SDK works against it with only the base URL changed, following MiniMax’s own quickstart pattern.

Set up the project:

mkdir minimax-test && cd minimax-test
python3 -m venv venv
source venv/bin/activate
pip install anthropic python-dotenv

Create a .env file with your key and MiniMax’s Anthropic-compatible endpoint:

# .env
ANTHROPIC_API_KEY=your-minimax-api-key

From there, the API accepts standard Anthropic message payloads directed at MiniMax’s endpoint, letting you target M3 and evaluate the model’s behavior on tasks of varying complexity — simple single-step requests where the multi-agent overhead would be unnecessary, and longer multi-step tasks where the Leader-Worker-Verifier structure is designed to pay off. The difference in behavior between those two task types is the most direct test of whether the architecture delivers on what the engineering post claims.

The practical conclusion from running real tasks against the API matches what MiniMax’s own post admits: the Agent Teams structure adds genuine value on tasks that are long, decomposable, and have outputs that can be verified against a clear standard. On tasks that are short, ambiguous, or hard to verify, the overhead of coordination is the dominant cost, and a single well-prompted model call is the better choice.