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:
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.
- 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.
- 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.
- 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.
A diagram showing three role boxes: Leader, Worker, and Verifier
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-key-here
ANTHROPIC_BASE_URL=https://api.minimax.io/anthropic
Setting ANTHROPIC_BASE_URL this way means the standard anthropic.Anthropic() client picks up MiniMax's endpoint automatically with no other code changes, which is the same trick that lets tools like OpenCode plug MiniMax in as a drop-in provider.
Now the script itself — a small agent loop that sends a task, executes a tool call if the model asks for one, and reports exactly how many turns and tokens the task took:
# run_task.py
import os
import json
from dotenv import load_dotenv
import anthropic
load_dotenv()
client = anthropic.Anthropic() # reads ANTHROPIC_API_KEY and ANTHROPIC_BASE_URL from env
MODEL = "MiniMax-M3"
# One simple tool: word counting. Enough to prove real tool-use is happening
# without needing external services for this test.
TOOLS = [{
"name": "count_words",
"description": "Counts the number of words in a block of text.",
"input_schema": {
"type": "object",
"properties": {"text": {"type": "string"}},
"required": ["text"],
},
}]
def count_words(text: str) -> int:
return len(text.split())
def run_task(task: str, max_turns: int = 6) -> dict:
"""Runs a task through the model, executing any tool calls it makes,
and returns a small report of what happened."""
messages = [{"role": "user", "content": task}]
total_input_tokens = 0
total_output_tokens = 0
turns_used = 0
for turn in range(max_turns):
turns_used = turn + 1
response = client.messages.create(
model=MODEL,
max_tokens=1024,
tools=TOOLS,
messages=messages,
)
total_input_tokens += response.usage.input_tokens
total_output_tokens += response.usage.output_tokens
# If the model didn't ask for a tool, it's done, return the answer
if response.stop_reason != "tool_use":
final_text = "".join(
block.text for block in response.content if block.type == "text"
)
return {
"answer": final_text,
"turns_used": turns_used,
"input_tokens": total_input_tokens,
"output_tokens": total_output_tokens,
}
# Otherwise, execute the tool call(s) and feed the result back
messages.append({"role": "assistant", "content": response.content})
tool_results = []
for block in response.content:
if block.type == "tool_use" and block.name == "count_words":
result = count_words(block.input["text"])
tool_results.append({
"type": "tool_result",
"tool_use_id": block.id,
"content": str(result),
})
messages.append({"role": "user", "content": tool_results})
return {"answer": None, "turns_used": turns_used, "error": "Hit max_turns without finishing"}
if __name__ == "__main__":
task = (
"Write a two-sentence description of what a circuit breaker does "
"in software systems, then use the count_words tool to tell me "
"exactly how many words your description contains."
)
report = run_task(task)
print(json.dumps(report, indent=2))
What this does: the loop sends the task, and on each response, checks stop_reason. If it's tool_use, the model is asking to run count_words, so the code executes it locally and feeds the numeric result back into the conversation as a tool_result block before asking the model to continue. If it's anything else, the model considers the task finished, and the function returns the answer along with exactly how many turns and tokens the round trip costs. That last part matters more than it looks: turn count and token totals are the actual, measurable version of "did this make the work easier," rather than a vibe.
To run it: with your .env file filled in and the virtual environment active, run python run_task.py.
On pricing, since it factors directly into whether "easier" is worth paying for: MiniMax-M3 lists at \$0.30 per million input tokens and \$1.20 per million output tokens on its standard tier, a promotional 50% discount off the \$0.60/\$2.40 list price. Set against Claude Opus 4.6 at \$5 and \$25 per million tokens, that's roughly 17 times cheaper on input and 21 times cheaper on output, though it's important to point out that cheaper input tokens don't automatically mean a cheaper finished task if the agent needs more turns, more tool calls, or more retries to get to the same result.
The Verdict
Pulling the architecture, the hands-on run, and the caveats together: MiniMax Agent, now Mavis, does make a specific category of work easier, and it's roughly the category MiniMax itself names. Long tasks with real verification criteria, research and synthesis across multiple sources, coding work that has tests to run against, and formal document generation with clear structure are exactly where a Leader splitting the work, Workers executing in parallel, and a Verifier checking the result before it ships genuinely beats a single agent grinding through the whole thing linearly and drifting somewhere in the middle.
For short, low-risk, easily-checked tasks, the same architecture is closer to overhead than help, and MiniMax's own citation of the Cost of Consensus finding backs that up directly: unstructured multi-agent collaboration without a real stopping condition just spends more tokens to arrive at the same or a worse answer. The honest reading of "does it make work easier" is conditional, not universal — which is a less exciting answer than a launch post gives you, but it's the one that actually matches what MiniMax put in writing themselves.
Wrapping Up
The most useful thing in this whole story isn't the multi-agent architecture; it's that MiniMax published their own failure modes alongside their design, which is rare enough to be worth rewarding with a careful read instead of a skim. Before routing a task through Agent Teams, Mavis, or any comparable multi-agent product, ask the one question their own engineers say they ask internally: Is this task long, complex, and verifiable enough that the cost of splitting it up and checking the result pays for itself, or would a single well-scoped agent call, run once, get you there faster and cheaper? Most of the time, that answer is the entire evaluation you need.
Shittu Olumide is a software engineer and technical writer passionate about leveraging cutting-edge technologies to craft compelling narratives, with a keen eye for detail and a knack for simplifying complex concepts. You can also find Shittu on Twitter.
Instagram Engineering
Shopify Engineering