MiniMax M2.5: Pricing Breakdown

Last week I got the same question from three different engineering managers in one day: "Is MiniMax M2.5 actually as cheap as they're claiming, or is there fine print I'm missing?"

Fair question. When a model that benchmarks at 80.2% on SWE-Bench Verified announces it costs a fraction of Claude Opus 4.6, the natural response is skepticism. So I dug into the actual MiniMax M2.5 pricing structure — the official announcement, the platform docs, the Coding Plan tiers, and what our team actually saw on our bill after two weeks of real agent usage. Here's everything you actually need to know, including the three billing spikes we hit that nobody warned us about.

How M2.5 Pricing Works — The One-Paragraph Version

MiniMax M2.5 is priced on a simple per-token model with two speed variants that trade throughput for output cost. There's no base subscription required for API access, automatic caching is included with no manual configuration, and the Coding Plan is a separate optional subscription layered on top for developers who want predictable prompt quotas.

Here's the core price sheet directly from the MiniMax M2.5 official announcement:

A few things worth noting right away. First, both variants have identical benchmark performance — this is purely a speed vs. cost trade-off, not a capability trade-off. Second, caching is automatic: MiniMax's API documentation explicitly states "Full automatic Cache support, no configuration needed" — a meaningful advantage over platforms where you have to manually implement caching headers. Third, the output/input cost ratio here is 8:1 (Standard), which is typical for a reasoning-capable model and means output-heavy agentic workflows drive the majority of your bill.

Standard Pricing: $0.15 Input / $1.20 Output

The Standard tier at 50 TPS is the right default for most agentic workflows — overnight batch jobs, code review pipelines, non-interactive refactors. At 50 tokens per second, a 30-minute agent session generating sustained output uses approximately 90,000 output tokens, costing about $0.11. A full hour at sustained output costs $0.30.

Lightning Mode: Same Output Quality, Higher Throughput

The Lightning tier costs twice as much on output ($2.40/M vs $1.20/M) but delivers ~100 TPS — nearly twice the actual measured speed of other frontier models. For interactive coding sessions, live pair-programming flows, or production agents with latency SLAs, Lightning is the right call. The $1/hour at 100 TPS figure MiniMax cites is their Lightning tier doing the math: 100 tokens/sec × 3,600 seconds × $2.40/M = $0.86/hour on output alone, plus a small input overhead.

Automatic Caching

This is quietly one of the most impactful pricing features. In agentic workflows, your system prompt, tool schemas, and repository context often repeat verbatim across dozens of calls. On platforms that require manual cache configuration, teams frequently skip it and overpay. MiniMax's automatic cache means repeated context is discounted without any implementation work. For a multi-agent session that resends a 50K-token repo summary on each call, this alone can reduce input costs by 60–70%.

Simple Translation: ~100 TPS ≈ ~$1/Hour Continuous Generation

MiniMax's own framing is useful here: you can run four M2.5 instances continuously for an entire year for roughly $10,000. That's the Lightning tier, sustained at 100 TPS, 24/7. For comparison, the same compute budget on Claude Opus 4.6 output ($25/M) would exhaust in under a week. As a cost floor for planning, budget $0.30–$1.00 per hour per agent instance depending on your TPS tier and input/output ratio.

M2.5 vs Claude Opus 4.6 vs Gemini 3 Pro — Cost at a Glance

All prices below are verified from official sources as of February 2026. Claude Opus 4.6 pricing from Anthropic's official model page; M2.5 pricing from the MiniMax official announcement; Gemini 3 Pro from Google's official API pricing page.

Cost per 1,000 coding tasks estimated using MiniMax's reported average of 3.52M tokens per SWE-Bench task (input + output combined, 30/70 split). Actual costs vary by task type and caching rate.

The table tells a clear story, and one practical paragraph on what it means in production: M2.5 Standard costs roughly 1/20th of Opus 4.6 on output tokens, which is where agentic workflows generate the bulk of their spend. On a 1,000-task coding batch — a reasonable monthly volume for a mid-size engineering team running automated code review — that's approximately $4.50 vs. $93. The 0.6% SWE-Bench gap between M2.5 and Opus 4.6 does not come close to justifying a 20x cost premium for most task types. Where it starts to justify itself is in tasks requiring deep reasoning, autonomous terminal operations, or complex business logic — areas where Opus 4.6's Terminal-Bench 2.0 lead (65.4% vs 52%) and reasoning depth are genuinely reflected in output quality. For everything else, the cost math strongly favors M2.5.

Coding Plan vs Pay-as-You-Go — The Actual Decision

MiniMax offers two fundamentally different ways to access M2.5. They're not alternatives to each other in the way you might expect — they serve different use cases and can actually coexist.

Coding Plan — Ideal Team Profile, Inclusions, and Break-Even Point

The Coding Plan is a subscription package that currently runs on MiniMax M2.1 (not M2.5), structured as prompt quotas per 5-hour window:

Important caveat: As of February 2026, the Coding Plan is powered by M2.1, not M2.5. If your priority is M2.5's latest performance numbers — and specifically its SWE-Bench 80.2% score — the Coding Plan does not give you that model. Direct API access with pay-as-you-go billing is the only current path to M2.5.

That said, the Coding Plan makes sense for a specific profile: a developer who works in 5-hour focused coding sessions, whose session count is predictable, and who values capped spending over token-level optimization. The break-even analysis is straightforward:

• Starter at $10/month: worthwhile if you run more than roughly 8–10 API sessions per month that would otherwise cost $1+ each.
• Plus at $20/month: worthwhile for professional developers running complex multi-file tasks daily.
• Max at $50/month: designed for power developers where the volume math makes the flat rate cheaper than per-token billing on M2.1.

For teams evaluating M2.5 specifically, the decision tree is short: if you need M2.5, use pay-as-you-go. Return to the Coding Plan if M2.1 meets your performance requirements at lower cost.

Pay-as-You-Go — Best for Experimentation, Spiky Workloads, and Early Evaluation

Direct API billing at M2.5's token rates is the right choice for three categories of users:

Experimenters: You're evaluating whether M2.5 belongs in your stack. Pay-as-you-go lets you run a real-world test suite without committing to a monthly subscription. At M2.5 Standard rates, 100 meaningful test tasks will cost roughly $0.45 — under a dollar to know whether the model fits your use case.

Spiky workloads: If your AI usage clusters around sprint cycles, code freeze periods, or quarterly releases rather than steady daily volume, pay-as-you-go avoids paying for capacity you're not using between peaks. A team that runs 5,000 tasks in two weeks and then goes quiet for two weeks doesn't benefit from a flat monthly plan.

Multi-model routing: If you're already routing tasks between M2.5 and Opus 4.6 (based on task complexity), pay-as-you-go on both models gives you clean cost attribution per task type. A subscription complicates that accounting.

The one friction point worth flagging: pay-as-you-go requires maintaining a credit balance, and low-balance situations can silently fail API calls if you don't have balance alerts configured. Set a minimum balance alert in your platform dashboard before building anything that needs M2.5 to be reliably available.

Real Monthly Bill — One Worked Example (Mid-Size Team)

Let me make this concrete with actual numbers. Here's a realistic scenario: a team of 6 engineers running an M2.5-powered code review and refactor agent, 5 days a week.

Assumptions:

• 200 coding agent tasks per day (automated code review + targeted refactors)
• Average task: 5,000 input tokens + 3,500 output tokens = 8,500 tokens total
• Caching reduces effective input by 40% (system prompt + repo context re-used)
• 22 working days/month
• Using M2.5 Standard ($0.15 input / $1.20 output)

Monthly cost formula:

Daily tasks:       200
Working days:      22
Total tasks/month: 4,400

Per task (before caching):
  Input:  5,000 tokens × $0.15/M  = $0.00075
  Output: 3,500 tokens × $1.20/M  = $0.00420
  Subtotal per task:                 $0.00495

Input after 40% cache reduction:
  Input:  3,000 tokens × $0.15/M  = $0.00045
  Output: 3,500 tokens × $1.20/M  = $0.00420
  Subtotal per task (cached):        $0.00465

Monthly total:
  4,400 tasks × $0.00465 = $20.46/month

Same workload on Claude Opus 4.6 ($5.00 input / $25.00 output, with 50% Batch API discount for offline processing):

Per task (Batch API, 50% discount):
  Input:  5,000 × $5.00/M × 0.5 = $0.0125
  Output: 3,500 × $25.00/M × 0.5 = $0.04375
  Subtotal per task (batched):       $0.056

Monthly total:
  4,400 tasks × $0.056 = $246.40/month

The 12x gap in this scenario (rather than 20x) reflects Opus 4.6's Batch API discount closing the gap somewhat. Even so, for a mid-size team running this kind of steady automated workflow, the annual saving approaches $2,700 — meaningful infrastructure budget that can go elsewhere.

Use this formula for your own estimate:

Monthly cost = (tasks/day × days/month) × 
               [(input_tokens × (1 - cache_rate) × input_$/M / 1,000,000) + 
                (output_tokens × output_$/M / 1,000,000)]

Plug in your real task volume, your average token counts (check usage.input_tokens and usage.output_tokens from a sample of real calls), and your expected cache hit rate (start at 30% if unsure, adjust after your first week).

3 Billing Spikes We Hit — and the Fix for Each

These are the three cost surprises our team actually encountered in the first two weeks. None of them are unique to MiniMax — they're agentic workflow problems that show up regardless of which model you're using. But M2.5's low per-token cost creates a false sense of security that makes them easier to miss.

1. Unbounded Context in Agentic Retries → Fix: Cap Context + Retry Budget
   

What happened: We had an agent set up to retry failed tasks automatically, which is generally correct behavior. What we didn't account for: each retry appended the full previous attempt (including thinking output and tool call history) to the context. By retry 4, a task that started at 6,000 input tokens was consuming 40,000+ tokens on its retry call, and the pattern compounded across the day.

The numbers: On a day with a 12% failure-and-retry rate across 200 tasks, this added roughly 2.8M unexpected input tokens — about $0.42 at M2.5 Standard rates. Not catastrophic, but it would be $8.40 on Opus 4.6, and it reveals a structural problem that scales badly.

The fix:

MAX_CONTEXT_TOKENS = 15_000
MAX_RETRIES = 3

def run_with_budget(prompt, max_retries=MAX_RETRIES):
    for attempt in range(max_retries):
        # Trim history if context is growing unbounded
        trimmed_prompt = trim_to_token_budget(prompt, MAX_CONTEXT_TOKENS)
        response = client.messages.create(
            model="MiniMax-M2.5",
            max_tokens=4096,
            messages=trimmed_prompt
        )
        if response.stop_reason == "end_turn":
            return response
        # On retry: summarize prior attempt rather than appending in full
        prompt = summarize_and_retry(prompt, response)
    raise MaxRetriesExceeded("Task failed after 3 attempts with context budget")

Cap both the context window and the retry count. On retry, summarize the previous attempt rather than appending the full output to history.

1. Full-File Prompts Instead of Targeted Diffs → Fix: Diff-First Prompting
   

What happened: Our initial code review agent sent the entire file contents for every review task — even when the PR touched 8 lines of a 600-line file. For a Python file averaging 800 lines (~16,000 tokens), this meant paying for 12,000 tokens of irrelevant context on every call.

The math: 50 tasks/day × 12,000 wasted input tokens × $0.15/M = $0.09/day = $1.98/month. Again, small at M2.5 rates. At Opus 4.6 rates ($5/M input), the same waste is $3.60/day = $79.20/month — the kind of number that shows up in someone's quarterly review.

The fix — diff-first prompting:

import subprocess

def get_diff_context(file_path, base_branch="main"):
    """Extract only the changed lines + surrounding context."""
    diff = subprocess.run(
        ["git", "diff", base_branch, "--unified=10", file_path],
        capture_output=True, text=True
    ).stdout
    return diff  # Typically 100–500 tokens vs. 10,000+ for full file

def review_pr_changes(file_path, base_branch="main"):
    diff_context = get_diff_context(file_path, base_branch)
    prompt = f"""Review only these changes for correctness and style issues:

{diff_context}

Focus on: logic errors, edge cases, naming, and test coverage gaps."""
    
    return client.messages.create(
        model="MiniMax-M2.5",
        max_tokens=1024,
        messages=[{"role": "user", "content": prompt}]
    )

For tasks that genuinely need full-file context (whole-file refactors, architecture-level reviews), send the full file. For targeted PR reviews, send the diff. This single change cut our average input token count per code review call from 14,000 to 800 tokens — a 94% reduction on the dominant token source.

1. Missing Cache Reuse on Repeated Repo Scans → Fix: Enable and Verify Cache Reuse
   

What happened: M2.5's automatic caching is real, but "automatic" doesn't mean invisible. Our multi-agent setup was sending a 45,000-token repository summary at the start of each agent call — a summary that was identical across all agents running on the same codebase. We assumed caching would handle this. It did, but only when the exact same prompt prefix appeared in the same session. Cross-session caching behaved differently than we expected.

The fix — verify cache is actually hitting:

Check your usage response object for cache metrics. The Anthropic-compatible API returns cache_creation_input_tokens and cache_read_input_tokens alongside standard input_tokens:

response = client.messages.create(
    model="MiniMax-M2.5",
    max_tokens=2048,
    messages=[
        {"role": "user", "content": f"{REPO_SUMMARY}\n\nTask: {task}"}
    ]
)

usage = response.usage
print(f"Input tokens:          {usage.input_tokens}")
print(f"Cache write tokens:    {getattr(usage, 'cache_creation_input_tokens', 0)}")
print(f"Cache read tokens:     {getattr(usage, 'cache_read_input_tokens', 0)}")

# Cache hit rate for this call:
total_input = usage.input_tokens
cache_reads = getattr(usage, 'cache_read_input_tokens', 0)
if total_input > 0:
    hit_rate = cache_reads / total_input
    print(f"Cache hit rate:        {hit_rate:.1%}")

If cache_read_input_tokens is consistently 0 despite repeated identical prefixes, your prompt structure may be varying in ways that invalidate the cache key (e.g., a timestamp injected at the start of every prompt). Move any variable elements to the end of the prompt, after the stable system context, to maximize cache prefix matching.

Use the Formula Before You Commit to a Plan

The worked example above is a starting point, not a final answer. Your actual costs depend on three numbers that only you can measure: your real task volume, your average token counts per task, and your cache hit rate on stable context.

Here's the sequence I'd follow before committing to either pay-as-you-go or the Coding Plan:

1. Run 50 real tasks using pay-as-you-go, logging usage.input_tokens and usage.output_tokens for each.
2. Calculate your actual average tokens per task (don't estimate — measure).
3. Check cache_read_input_tokens in the usage response to find your real cache hit rate.
4. Plug those three numbers into the formula above.
5. Compare the monthly result against the Coding Plan tiers — and remember that the Coding Plan currently runs on M2.1, not M2.5.

For most teams doing automated coding agent work, pay-as-you-go on M2.5 will come out ahead of the Coding Plan on both cost and model capability until MiniMax updates the plan to include M2.5. Bookmark this page — that's a change worth watching.

Data sources: MiniMax M2.5 official announcement (Feb 12, 2026), MiniMax API docs (Feb 2026), Anthropic Claude Opus 4.6 official page (Feb 5, 2026), Anthropic API pricing documentation (Feb 2026), Artificial Analysis benchmark data (Feb 17, 2026), pricepertoken.com verified model pricing (Feb 2026).