MiniMax M2-her: A Dialogue Model for Roleplay, Not Coding

The name suggests a variant of MiniMax M2, the coding and agent model. It is not one. M2-her is a separate model built for a different job: character-driven conversation, roleplay and long multi-turn chat. If you point it at a repository and a tool list, you are using the wrong model.

That makes it one of the few models in this catalogue where the usual questions, SWE-bench scores and tool-call reliability, simply do not apply. The useful questions are about persona consistency, reply length and how you shape its voice.

A different job from the rest of the M2 line

OpenRouter lists M2-her with a release date of 23 January 2026 and describes it as a dialogue-first model for immersive roleplay, character-driven chat and expressive multi-turn conversation. MiniMax's own text-chat guide describes it as a model built for dialogue, with role-setting and conversation-history features for role-play and multi-turn chat.

The specifications from MiniMax's documentation are modest by design:

• Context window — 64K tokens
• Maximum reply — 2,048 tokens, set with max_completion_tokens
• Input — text only
• Defaults — temperature 1.0, top_p 0.95

The OpenRouter listing shows no tool calling, structured output or reasoning mode, and MiniMax's guide does not mention any of them. At the time of writing OpenRouter priced it at $0.30 per million input tokens and $1.20 per million output.

One availability note: the dedicated text-chat guide documents M2-her, but MiniMax's main model overview page does not list it. Before building on it, confirm in the MiniMax console or with your provider that it is offered on your account. The MiniMax family explained covers how the rest of the line fits together.

The role types are the real interface

Most chat APIs give you three roles: system, user and assistant. MiniMax's documentation for M2-her lists four more, and they are where the model's character work happens.

• system — defines the model's role and behaviour
• user_system — defines the user's own role and persona
• group — names the conversation
• sample_message_user and sample_message_ai — example exchanges showing the style you want

The split between system and user_system is the useful one. In a normal chat model you describe both characters in a single system prompt and hope the model keeps track of who is who. Here the model's persona and the user's persona are separate inputs.

The sample messages work like few-shot examples, and MiniMax recommends one to three concise pairs. They count toward input tokens on every request, so a long example block is a cost you pay on every turn. Few-shot example management covers why two well-chosen examples usually beat ten mediocre ones.

A practical caveat: these are MiniMax-specific roles on MiniMax's own endpoint. If you reach M2-her through a router that normalises requests to the standard OpenAI schema, check whether the extra roles survive the trip. If they are dropped or rejected, fold the persona into the system prompt and the examples into early turns instead.

Short replies by design

A 2,048-token cap on replies is low next to modern coding models, and for this job it is mostly a feature. Character chat works in turns. A reply that runs to several thousand tokens usually means the model has taken over the scene, which is what users of roleplay products complain about most.

The 64K window is the constraint that will bite first. Long-running conversations accumulate history quickly, and the docs say to send the full history with each request. Somewhere past a few hundred exchanges you will need a strategy: keep the persona definitions and the most recent turns verbatim, and summarise the middle. System prompts explained is useful background on what to keep fixed and what to let drift.

How to evaluate a roleplay model

There is no standard benchmark that predicts how a character model will feel to your users, so build a small test yourself. The checks that matter:

1. Persona drift. Run a fifty-turn conversation and check whether the character's voice, facts and constraints at turn fifty match turn one.
2. Role confusion. Does the model ever speak for the user's character? That is the failure the separate user_system role exists to prevent.
3. Style transfer. Swap your sample messages for a different tone and see how far the replies follow.
4. Length discipline. Measure reply lengths across a session. Steady and appropriate beats occasionally brilliant and often bloated.
5. Boundaries. Test how it handles requests your product must refuse. Do this before launch, not after a complaint.

Score with blind side-by-side comparisons against whatever you use now. Human preference is the only signal that transfers for this kind of work.

When to pick something else

Choose a general model instead when the conversation needs to do things: look up data, call tools, return JSON or reason through a problem. M2-her has none of those listed. For coding or agent work within the same family, the MiniMax M2 guide covers the model that actually shares the name. For long documents, 64K will not be enough.

Pick M2-her when the product is the conversation itself: companions, interactive fiction, character-driven support personas or game dialogue. In that narrow lane, a model tuned for the job and given clean persona inputs is a better starting point than a general model with a long system prompt.