MiniMax prices M3.1 Flash for agents; the workflow bill still needs measuring

The cheapest line on the invoice is not necessarily the job

A model invoice can be precise while the cost of a useful result remains uncertain. That distinction is the most practical way to read MiniMax’s October 19 announcement of M3.1 Flash. For a startup building an agent that operates business software, the release is a new purchasing option, not a complete estimate of the cost of finishing a workflow.

In its M3.1 Flash release note, MiniMax lists prices of $0.15 per million input tokens, $0.60 per million output tokens and $0.015 per million cached input tokens. It says the model is available through its API, M Plan and MiniMax Code. The same announcement says model weights will be released later. We have not verified a separate weight-release date; this is not a report that self-hosted deployment is available today.

Those distinctions matter for an ordinary procurement conversation. An API can be evaluated without owning the model’s serving infrastructure. Downloadable weights would raise different questions about hardware, operational responsibility and customization. A team considering the hosted product should make that decision on the terms actually available, rather than assume a future distribution option already solves its deployment constraints.

MiniMax also reports gains in speed, benchmark performance and overall usage cost. Those are company claims, not Foundra measurements. The published note does not establish what a particular customer would spend to complete its own sales, finance or support process. That is a separate calculation, with a separate unit: one correctly finished task.

Three different prices, three different questions

Token price asks what the model service charges for the text it processes and generates. Task cost asks how much model work is required before an acceptable result emerges. Workflow cost adds the surrounding system: software access, orchestration, observation, human review and recovery when something goes wrong. These are analytical categories, not additional MiniMax fees.

Consider a hypothetical agent checking whether an invoice matches a purchase order. One attempt might finish with a short answer. Another might retrieve several documents, make repeated tool calls and ask a person to reconcile a mismatch. Even at the same published token rates, those two runs would not cost the same. More importantly, their token bills would not reveal whether either agent updated the correct record.

A sensible comparison would hold the business task constant and record all attempts, including failures. The evaluator would count accepted outcomes, not just successful demonstration runs, and distinguish automatic completions from cases rescued by a human. If a model generates fewer tokens but produces more ambiguous results, the apparent saving could disappear in review. That is a possibility to test, not a finding about M3.1 Flash.

The published pricing also separates cached input from ordinary input. That creates another measurement question. A workload repeatedly using eligible context might have a different input bill from one that changes documents on every run. Buyers should verify cache behavior and actual billing in their own integration rather than apply the cached rate to every input token.

The point is not to dismiss a lower rate. It is to locate the saving. A reduction in the model-service portion of a workflow can be valuable even if nothing else changes. But an honest product forecast should show that portion separately, so investors and customers can see which assumption produces the proposed margin improvement.

A benchmark is a lead for evaluation, not permission to act

MiniMax frames the release around agentic tasks, coding, computer use and cybersecurity. Its benchmark discussion can help a developer decide what to investigate, but it cannot replace a representative evaluation. A finance assistant and a coding assistant encounter different tools, permissions, documents and consequences. A general capability claim does not establish success in both environments.

An evaluation should therefore include the cases a product is least comfortable handling: missing records, inconsistent instructions, interrupted sessions and actions requiring approval. For the hypothetical invoice agent, a correct refusal to change an unresolved invoice may be more valuable than an impressive-looking completion. Scoring that refusal as a failure would reward the wrong behavior.

Operating limits should stay outside the model’s discretion. A test environment can make consequential writes reversible or require approval before they happen. A record of the inputs, tool actions and final result then lets a reviewer inspect how the outcome was reached. These are proposed safeguards for an agent product; this article does not claim MiniMax supplies or enforces them automatically.

For a small SaaS company, the useful next step is a bounded trial against existing work, not a platform-wide migration justified by a headline percentage. Keep the task definition and acceptance criteria fixed, compare the total effort required, and decide whether the new model improves that specific product. M3.1 Flash’s announced availability makes such an evaluation possible through the named hosted channels. The result remains something the buyer must establish.