MiniMax API Pricing: M3, Priority and Long-Context Costs

MiniMax M3 standard and priority USD rates, the 512K input threshold, M2.7 caching and worked workload budgets. Official sources checked October 2, 2026.

Fan Chuanyu's profile

Written by Fan Chuanyu

•5 min read

MiniMax budgets need more than a headline token rate. A long input or priority request can move a workload into a different billing configuration, while cache categories add another source of error.

A budget that treats every request alike misses these distinctions. This revision focuses on the official international pay-as-you-go API, with USD prices checked on October 2, 2026. Older OpenRouter prices and June latency samples are not presented as current official rates or fresh performance evidence.

MiniMax-M3: standard versus priority

The official pay-as-you-go table labels the effective M3 rates as a permanent 50% discount. The table below shows the effective price, rather than the crossed-out reference price. A provider can still change a future rate card; the wording is not a contract fixing the price forever.

All token rates are USD per one million tokens.

M3 request configurationInputOutputCached input read
Standard, input ≤512K tokens$0.30$1.20$0.06
Standard, input >512K tokens$0.60$2.40$0.12
Priority, input ≤512K tokens$0.45$1.80$0.09
Priority, input >512K tokens$0.90$3.60$0.18

Priority is selected with service_tier: "priority" and is priced at 1.5 times standard. MiniMax describes it as priority admission for faster responses and improved reliability. That is the provider's service description, not a measured speedup established by this directory.

The 512K boundary applies to input tokens in a request, not total monthly tokens or visible output length. The rate card lists the long-input band as a separate configuration. Do not treat its higher price as a charge only on the tokens beyond 512K. Confirm long-context availability for your account and the returned billing usage before relying on it in production.

See the MiniMax-M3 model page for the directory's model and hosting record. A single summary hosting rate cannot represent every input band and service tier.

Worked budgets: where the extra spend comes from

For requests within the lower input band, a workload totaling 1M uncached input tokens and 1M output tokens costs:

ConfigurationEstimated token cost
M3 standard, ≤512K input per request$1.50
M3 priority, ≤512K input per request$2.25
M3 standard, >512K input per request$3.00
M3 priority, >512K input per request$4.50

The long-input examples assume the workload's requests qualify for that band. If only some requests cross the boundary, split usage by configuration before calculating. Combining all tokens under the cheaper band understates the bill; combining them all under the expensive band overstates it.

Consider a 600K-input, 20K-output request, all input uncached:

Standard long-input: 0.6 × $0.60 + 0.02 × $2.40 = $0.408
Priority long-input: 0.6 × $0.90 + 0.02 × $3.60 = $0.612

Pricing it as a lower-band standard request would produce $0.204, half of the documented long-input estimate. Splitting a document into several requests can change the rate band, but can also repeat context and damage task quality. Compare total tokens and acceptable results before treating chunking as a saving.

These are calculated examples, not invoices. They exclude retries, tools, media charges, taxes and currency conversion. For reasoning tasks, budget from the API's billed output usage instead of estimating cost from the final visible answer alone.

M2.7 caching needs its own budget

The same official rate card lists MiniMax-M2.7 at $0.30 input/$1.20 output, with $0.06 cache reads and $0.375 cache writes per million tokens. The highspeed route doubles input/output rates; cache rates stay the same.

Do not assume another version's cache categories apply to your integration. Reconcile returned usage with the exact model's billing documentation. Keep cache writes separate from reads, and do not invent a missing M3 write rate from the M2.7 entry.

M3.1 Preview access and pay-as-you-go are different products

MiniMax's official documentation distinguishes standard Open Platform API Keys, which consume account balance by usage, from Credits accessed through a Subscription Key. The products do not become interchangeable merely because they can cover some of the same resources.

The official model catalog currently restricts MiniMax-M3.1-Flash-Preview to M Plan and MiniMax Code. No pay-as-you-go rate for that exact preview is verified here. See its access and reasoning notes before switching an M3 integration.

A monthly plan price is not a per-token API price. Likewise, a provider catalog price from OpenRouter is not evidence of MiniMax's native billing or account eligibility. Check which key type, account and route your application actually uses before applying any table.

This revision removes the older blanket claim that a US developer must use an intermediary. Verify account eligibility, payment and service availability directly for your situation. Neither a reachable documentation page nor an entry in this directory proves that every account can use every model from every location.

Keep media costs outside the text-token subtotal

A text-model budget does not price an image, audio or video pipeline. Add each resource using its documented unit and configuration, then include failed jobs and retries. Duration, resolution, input materials and character counts can make two jobs with the same text prompt cost different amounts.

Before choosing a media route, calculate a few representative complete jobs instead of multiplying a headline output rate. Label partial estimates clearly so a team does not mistake output-only cost for the total workflow bill.

A practical comparison before choosing a tier

Use the same task set and acceptance criteria for M3 standard, M3 priority and any older model you are considering. Record the exact model, service tier, input band, billable token categories, number of attempts and total spend. Keep task quality and response time beside the price.

If priority does not improve a constraint your users actually experience, its higher price may have little value for your application. If the standard route repeatedly misses a deadline or fails under load, a lower advertised price may hide an operational cost. These are decisions to test, not conclusions established by this rate-card review.

For a cross-provider baseline, the updated DeepSeek pricing guide explains peak/off-peak billing and cache usage. Avoid comparing one provider's discounted cached input with another provider's uncached input, or mixing subscription quota with pay-as-you-go prices.

Questions that affect the bill

Does priority guarantee a specific latency?

The documentation describes priority admission, but the rate table does not establish a universal latency guarantee. Test the response-time target that matters to your application.

Are the calculations new benchmark results?

No. They apply the current published rates to stated token or duration assumptions. No new API call, invoice reconciliation or comparative quality test was performed for this revision.

Should I split a large input to lower the bill?

Evaluate the complete job. Smaller requests can repeat instructions or lose evidence that the task needs across sections. Compare total usage, accepted results and repair attempts for the split and unsplit versions before choosing a cheaper-looking configuration.

Share: