MiniMax M3.1 Flash: Cheap Agent Model, 93% Hallucination

By Lazar Milicevic · Published October 20, 2026 · 11 min read

You're paying Claude rates for agent workloads, and a model priced at $0.15 per million input tokens just landed with strong benchmark numbers. The catch is a measured tendency to answer confidently when it should say "I don't know." Here is how to decide whether to switch, what to test first, and how to contain the failure mode if you do.

What MiniMax actually shipped

MiniMax released M3.1 Flash on October 19, 2026. According to MarkTechPost, it is a multimodal mixture-of-experts model with 428B total parameters and about 23B active per token, a 1,000,000-token context window, text/image/video input, and text output.

Pricing, per llm-stats:

Digital Applied notes the price is flat at any prompt length. That matters for long-context agent work: the predecessor M3 costs $0.30/$1.20 up to 512K input tokens and doubles above that.

Access is through the MiniMax API, the M Plan subscription, and the MiniMax Code app, per Tech Insider.

Two operational details to know before you plan around it:

• Thinking can't be turned off. Per Venice, the model always reasons. Effort is tunable (low, medium, high, xhigh, max) and the default is max. Because the model is verbose, leaving the default in place can have a direct cost consequence. Check MiniMax's documentation to see how reasoning tokens are billed.
• It is closed-weights today. MiniMax has said open weights are due October 23, per Techmeme, but that hadn't happened as of October 20, and the license hasn't been disclosed. Don't architect around self-hosting yet.

The headline claim, read carefully

The VentureBeat headline says M3.1 Flash beats DeepSeek and Opus 5 on a key business benchmark. The underlying numbers are more nuanced:

• MiniMax reports 62.2 on Automation-Bench and 76.2 on BankerToolBench, tying Claude Opus 5 on BankerToolBench, per a VentureBeat summary. Sources disagree slightly on the Automation-Bench figure (62.2 vs 62.8 at max effort), so treat it as roughly 62.
• DeepSeek's own technical paper reports 54.8% on Automation-Bench for V4.1-Flash, but MiniMax's own comparison table also lists the newer DeepSeek V4.1 Flash-1017 at 60.5, per MarkTechPost. Against that newer checkpoint the lead is much smaller (roughly 1.7 points), and the comparison with 54.8 is against an older checkpoint. All of these numbers are vendor-reported.
• On coding, the picture flips. MiniMax's official DeepSWE v1.1 score for M3.1 Flash is 73.7%, against 74.0% for Claude Opus 5, per Apiyi. DeepSeek's paper reports V4.1-Flash at 74.2%, above Opus 5.

So: a tie on one business benchmark, a narrow lead on another, and a slight loss on coding. None of these are production deployments. And Opus 5 is no longer the current Anthropic model; Opus 5.5 shipped September 22, 2026, per Layer3 Labs. The honest summary is that benchmark results suggest M3.1 Flash is competitive for agentic tool-use work, not that it replaces Claude.

Independent measurement is more sober. The Decoder reports Artificial Analysis scores M3.1 Flash at 42 on its Intelligence Index, 13 points above M3, but behind DeepSeek V4.1 Flash 1017 (45) and level with GLM-5.3-Flash. I haven't verified a direct comparison against the strongest Anthropic and OpenAI models on that index, so check the current Artificial Analysis table for the specific models you're considering.

The 93% hallucination number, and what it does and doesn't mean

This is the part that should shape your design. Per Artificial Analysis on X, on AA-Omniscience:

M3.1 Flash has the best raw knowledge accuracy of the three. But it attempts almost every question, producing a 93% hallucination rate and an overall AA-Omniscience score of 16.

Read that 93% carefully. It is not "93% of answers are wrong." The model got 56% right. The hallucination rate measures how often it answers wrongly instead of abstaining when it doesn't know. Of the questions it didn't get right, it almost never said "I'm not sure."

Why this matters for a small business: a model that is wrong 44% of the time on hard factual recall but says so clearly is easy to wrap. A model that is wrong the same amount and sounds equally confident is a liability anywhere a human isn't reviewing the output. VentureBeat's own conclusion is that businesses may need extra verification, retrieval systems, guardrails, or human review.

Where this bites hardest:

• Customer-facing answers about pricing, policy, or product specifics
• Anything that cites facts from model memory (legal, tax, medical, compliance)
• Agents that act on their own outputs (sending emails, updating a CRM, issuing refunds)

Where it bites less:

• Extraction and transformation over text you supply (invoice fields, email classification, summarization of provided documents)
• Tool-calling steps whose results are machine-checkable
• Drafting with human review before send

The pattern: grounded tasks are far safer than recall tasks. If the answer is in the context window or a database, the abstain-versus-guess problem shrinks.

Cost math: what the savings might look like

Start with list prices. All figures below come from the sources cited.

DeepSeek's rates come from BenchLM and VentureBeat. Opus pricing comes from third-party pages citing Anthropic (ayautomate, Layer3 Labs). Check each vendor's own current pricing page before you commit.

Two takeaways. First, M3.1 Flash's flat $0.15/$0.60 matches DeepSeek's off-peak price and undercuts its peak price, which is useful if your workload runs during European or US-East business hours that overlap the peak windows. Second, the gap to Opus is large on paper, but token price is not task price.

On the claimed savings: MiniMax says M3.1 Flash cuts agentic task costs by 70% versus its previous model and runs close to three times faster, per SiliconANGLE. That's a vendor claim. Artificial Analysis measured about 57% lower cost per task, on a different workload, per daily.dev. Also note that Artificial Analysis's index score and cost-per-task figures were taken at maximum reasoning effort. I haven't verified costs at lower effort levels.

Here is why your bill may not follow the list price. Because thinking can't be disabled, a "simple" call can generate a long reasoning trace, and depending on how the provider bills it, that can add to your output cost. Here's an illustrative example with round numbers (not a measurement): suppose a classification step sends 2,000 input tokens and the model emits 3,000 reasoning-plus-answer tokens.

# Illustrative only: round numbers, not measured data
input_tokens, output_tokens = 2_000, 3_000

flash_cost = input_tokens/1e6*0.15 + output_tokens/1e6*0.60
opus55_cost = input_tokens/1e6*4.00 + output_tokens/1e6*20.00

print(f"Flash:    ${flash_cost:.4f} per call")   # $0.0021
print(f"Opus 5.5: ${opus55_cost:.4f} per call")  # $0.0680

Even with a reasoning-heavy trace, the per-call gap is large at these prices. But the same arithmetic cuts the other way if a cheaper model needs retries, a second validation call, or human cleanup. You only learn the real number by running your workflow.

How to test it on your own workflows

Public benchmarks tell you where to look. They don't tell you how the model handles your invoices, your support tickets, or your CRM notes. A two-day eval is enough to decide.

Step 1: Pull a real sample. Take 100–200 actual inputs from the workflow you're considering moving, with known-good outputs (human-approved results, or past outputs you've already verified).

Step 2: Split by task type. Tag each case as grounded (answer is in the provided input) or recall (answer relies on model knowledge). The hallucination risk concentrates in the second group.

Step 3: Run both models at the same settings. Keep prompts identical. For M3.1 Flash, run at least two effort levels, because cost and quality both move with it.

import json, time
from statistics import mean

EFFORTS = ["low", "medium", "max"]

def run_eval(client, model, cases, effort=None):
    results = []
    for case in cases:
        t0 = time.time()
        resp = client.generate(
            model=model,
            prompt=case["prompt"],
            effort=effort,           # check provider docs for the exact parameter name
        )
        results.append({
            "id": case["id"],
            "task_type": case["task_type"],   # grounded | recall
            "output": resp.text,
            "latency_s": time.time() - t0,
            "in_tok": resp.usage.input_tokens,
            "out_tok": resp.usage.output_tokens,  # includes reasoning tokens
        })
    return results

def score(results, cases):
    gold = {c["id"]: c["expected"] for c in cases}
    by_type = {}
    for r in results:
        correct = grade(r["output"], gold[r["id"]])  # your own grader
        by_type.setdefault(r["task_type"], []).append(correct)
    return {k: mean(v) for k, v in by_type.items()}

(client.generate and the effort parameter are placeholders. Check each provider's API docs for the real call signature.)

Step 4: Measure what matters. Track per-task accuracy by type, total tokens (especially output/reasoning), cost per successful task, and latency. Cost per successful task, including retries and validation calls, is the number that decides this.

Step 5: Measure the confident-wrong rate directly. For recall cases, count how often the model gave a wrong answer without hedging versus abstaining. This is your own version of the AA-Omniscience metric, on your data.

Containing hallucination: validation layers that work

If the eval shows M3.1 Flash is good enough on your grounded tasks, you can wrap it. These patterns cost little relative to the savings.

1. Force grounding. Pass the source text and instruct the model to answer only from it, quoting the supporting span. Reject any answer without a quote that appears verbatim in the input.

def grounded_ok(answer: dict, source: str) -> bool:
    quote = answer.get("supporting_quote", "")
    return bool(quote) and quote in source

2. Schema validation. For extraction, require JSON and validate types, ranges, and formats. An invoice total that isn't a number, or a date in the wrong year, fails before it touches your accounting system.

from pydantic import BaseModel, field_validator

class Invoice(BaseModel):
    vendor: str
    total: float
    currency: str

    @field_validator("total")
    @classmethod
    def positive(cls, v):
        if v <= 0:
            raise ValueError("total must be positive")
        return v

3. Cross-check with arithmetic or lookups. Line items should sum to the total. A customer ID should exist in your database. A promo code should exist in your system. Deterministic checks catch confident errors for free.

4. Escalate on disagreement. Run a second, different model only on cases that fail validation or fall below a confidence heuristic. Most traffic stays on the cheap model; the expensive one handles the tail. This is the usual place where "switch from Claude" becomes "route between models."

5. Gate side effects. Anything irreversible (sending an email, issuing a refund, deleting a record) goes through a human approval step or a stricter validator until your logged error rate earns it autonomy.

6. Log everything. Store inputs, outputs, validator results, and reviewer corrections. This is what lets you tighten or loosen the gates with data instead of intuition.

A decision framework: switch, route, or stay

Don't treat this as a binary. A reasonable way to sort workflows:

Other factors to weigh:

• Vendor and data considerations. MiniMax is a Chinese provider. Check its data handling terms against your obligations before sending customer data, and consider whether the pending open weights (license undisclosed) change your options.
• Maturity. The model is days old. Pricing, rate limits, and behavior can shift, so recheck the current pricing page before committing.
• Rival options moved too. DeepSeek V4.1 Flash scores higher on the Intelligence Index (45 vs 42) and abstains more often by Artificial Analysis's measure, at the same price off-peak. M3.1 Flash's edge is flat pricing at peak hours and strong agentic benchmark numbers, not a clean win across the board. Test both.

How this looks in practice

When a cheaper model lands, I don't swap it in on the strength of a benchmark. I run it against the client's own workflow data, split tasks into grounded and recall, and compare cost per successful task, including retries and validation calls. Then I build the validation layer the model's failure profile calls for: schema checks, source-quote verification, deterministic cross-checks, and an escalation path to a stronger model for the cases that fail.

For a model like M3.1 Flash, where the measured weakness is guessing instead of abstaining, that layer is the product. If you're weighing a move off Claude for some or all of your automations, the useful first step is a cost-versus-accuracy audit on your real inputs.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.