MiniMax M2.5 and cheap long-running agent work
MiniMax M2.5 is interesting because it pushes the cost side of agentic coding and productivity work very aggressively.
Running a frontier model continuously for an hour costs $1 at MiniMax’s pricing. Four instances running for an entire year cost $10,000. When agent loops need thousands of tool calls, retries, and tests, cost stops being a line item and becomes the constraint that decides what products exist.
Source
MiniMax M2.5: Built for Real-World Productivity
By: MiniMax
Published: Feb 12 2026
Type: Release announcement
This matters because MiniMax is making a different argument from most model launches. Instead of focusing on benchmark position, M2.5 is positioned around cost per hour of continuous agent work. That’s the constraint long-running coding agents and office automation actually hit.
Why cost per hour matters more than cost per call for agents
M2.5 ships two versions: M2.5-Lightning at 100 tokens per second (twice the speed of other frontier models) and M2.5 at 50 tokens per second. Lightning costs $0.3 per million input tokens and $2.4 per million output tokens. The standard version costs half that. Based on output price, M2.5 is one-tenth to one-twentieth the cost of Opus, Gemini 3 Pro, and GPT-5.
The practical framing: running M2.5-Lightning continuously for an hour at 100 tokens per second costs $1. At 50 tokens per second, the cost drops to $0.30. Four instances running for an entire year cost $10,000. For agent systems that run continuously — security scanners, code review pipelines, research agents — this pricing changes what’s economically viable.
The benchmarks support the claim on capability. SWE-Bench Verified: 80.2%. Multi-SWE-Bench: 51.3%. BrowseComp (with context management): 76.3%. But the interesting numbers are about efficiency, not just accuracy. M2.5 completes SWE-Bench Verified 37% faster than M2.1 — average end-to-end runtime dropped from 31.3 minutes to 22.8 minutes, matching Opus 4.6’s 22.9 minutes, at 10% of the cost per task. Average token consumption per task decreased too: 3.52 million tokens vs. M2.1’s 3.72 million. The model uses approximately 20% fewer search rounds across BrowseComp, Wide Search, and RISE compared to M2.1, which means it’s solving problems in more efficient paths, not just getting the right answer.
The efficiency comes from three sources. First, the reinforcement learning setup incentivises efficient reasoning and optimal task decomposition — an in-house framework called Forge decouples the training engine from the agent scaffold, supporting optimisation across different tools and harnesses. Second, the model exhibits what MiniMax calls a “spec-writing tendency” that emerged during training: before writing code, M2.5 decomposes and plans features, structure, and UI design from an architect’s perspective. Third, it was trained on over 200,000 real-world environments across 10+ programming languages, covering the full development lifecycle — not just bug-fixing, but system design, environment setup, feature iteration, code review, and testing across web, mobile, and server platforms.
MiniMax uses M2.5 internally: 30% of company tasks are autonomously completed by the model across R&D, product, sales, HR, and finance. In coding specifically, M2.5-generated code accounts for 80% of newly committed code.
The office work angle is genuinely different from most model launches. M2.5 was trained in collaboration with professionals in finance, law, and social sciences who designed requirements and contributed domain-specific data. Users have built over 10,000 “Experts” (reusable agents combining office skills with domain expertise) on MiniMax Agent — for example, an agent that follows an established research framework to automatically fetch data, organise analytical logic, and output formatted reports.
These are launch claims. The SWE-Bench and BrowseComp numbers are strong, but the harness-specific scores (79.7% on Droid, 76.1% on OpenCode) show that performance varies by scaffold. Real-world reliability across diverse repositories and edge cases needs independent testing.
My take
The cost argument is the one that sticks. Most model comparisons focus on a single task’s accuracy. But agent systems run hundreds or thousands of tasks per day, and every task involves multiple model calls. The difference between $1/hour and $10/hour for continuous operation is the difference between “always-on agent” and “run it when you really need it.” MiniMax is betting that at some capability threshold, cost becomes the primary adoption driver — and the pricing suggests they’re serious about testing that bet. The risk is that cost leadership without ecosystem gravity is fragile. If a similarly priced model with better harness support appears, the switching cost is near zero.
Where this is useful
- When building agents that run continuously (CI/CD reviewers, security scanners, research pipelines) — the cost curve at M2.5’s pricing makes always-on operation practical instead of a luxury.
- When comparing models for agentic work — total task cost (tokens × price × number of rounds) matters more than per-token pricing, and M2.5’s efficiency improvements compound across the three dimensions.
- When office automation requires domain expertise — the Expert/Skills model with domain professionals in the training loop is a pattern worth watching, though it needs independent validation.
Apply this: If your agent runs for more than a few minutes per task, calculate cost per completed task (not per token) across two or three models. The cheapest per-token model isn’t always the cheapest per-task model.
What I want to remember
Remember: The model that wins a one-shot benchmark may not be the best for a long-running agent. Cost per hour of continuous work, token efficiency per task, and stable tool use across scaffolds matter more than peak accuracy on a single evaluation.