We ran a MiniMax M3 long-context benchmark across 62 live Responses API calls, ranging from roughly 32,000 to 900,000 input tokens. The replicated 60-request core test achieved 57/60 strict end-to-end passes (95.0%); both one-shot upper-context pilots also passed. The experiment measured exact retrieval, negative-control behavior, end-to-end latency, returned token usage, prompt-cache activity, and estimated API cost.
Last verified: July 28, 2026. This URL originally contained a proposed test protocol. We have now replaced that protocol with the live results, methodology, failure log, charts, and downloadable evidence produced by the completed experiment.
Bottom line: MiniMax M3 retrieved the requested value in 42 of 45 replicated positive core attempts, rejected all 15 negative controls, and passed one middle-position retrieval at both 768K and 900K tokens. Those two upper pilots are demonstrations, not reliability estimates. The most important operational finding was economic: our average usage-derived cost per completed call more than doubled when the prompt moved from the 500K test cell to the 520K cell and crossed MiniMax’s 512K pricing boundary.
MiniMax-AI.chat Editorial Team
MiniMax M3 long-context benchmark at a glance
| Live generation attempts | 62 |
|---|---|
| Replicated core | 60 attempts from 32K to 520K tokens |
| Upper-context pilots | One attempt at 768K and one at 900K |
| Strict passes, all attempts | 59/62 (95.16%) |
| Strict passes, core | 57/60 (95.0%) |
| Positive core retrieval | 42/45 end to end; 42/44 among completed responses |
| Negative controls | 15/15 passed; zero false positives |
| API completion | 61/62 (98.39%) |
| Tested API and tier | Responses API, Standard tier |
| Client-observed run interval | July 28, 2026, 15:43:13–16:01:10 UTC |
Of the three non-passing attempts, two were completed responses that incorrectly returned NOT_FOUND for a present value. The third was an HTTP 500 server error. We did not retry failed calls, so the published scores reflect the original attempt rather than a best-of-two result.
Results by context length
The core benchmark used five nominal context cells: 32K, 128K, 256K, 500K, and 520K. Each cell contained nine positive retrieval attempts—three marker positions repeated three times—and three negative controls, for 12 attempts per length. The table reports actual median input tokens rather than relying only on nominal labels.
| Nominal length | Median actual input | Strict passes | API completed | Latency p50 | Latency p95 | Usage-derived cost |
|---|---|---|---|---|---|---|
| 32K | 31,976 | 12/12 | 12/12 | 2.070s | 3.228s | $0.115023 |
| 128K | 127,924 | 12/12 | 12/12 | 6.505s | 10.010s | $0.460557 |
| 256K | 255,922 | 11/12 | 12/12 | 12.247s | 14.164s | $0.921078 |
| 500K | 499,928 | 11/12 | 11/12 | 26.432s | 62.195s | $1.649395 |
| 520K | 519,874 | 11/12 | 12/12 | 26.442s | 29.728s | $3.743748 |
All 12 attempts passed at 32K and 128K. The 256K and 520K cells each contained one completed false negative. The 500K cell’s only failure was the API error; all eight completed positive retrievals and all three negative controls in that cell passed.
Accuracy, completion, and confidence intervals
- Core strict accuracy: 57/60, or 95.0% (95% Wilson interval: 86.3%–98.29%).
- Positive end-to-end accuracy: 42/45, or 93.33% (95% Wilson interval: 82.14%–97.71%). This treats the HTTP 500 as a failed attempt.
- Positive accuracy conditional on a completed response: 42/44, or 95.45%.
- Negative-control accuracy: 15/15, or 100%, with a 95% Wilson lower bound of 79.61%.
- False-positive rate: 0/15 observed negative controls.
The intervals matter. A perfect 15/15 negative-control result is encouraging, but it does not establish a true 100% rejection rate. The sample is too small for that claim. Likewise, the two upper-context successes cannot establish a dependable success rate at 768K or 900K.
Did marker position affect retrieval?
For positive core cases, we placed the unique target near 5%, 50%, or 95% of the generated record sequence. Each position had 15 end-to-end attempts across the five context lengths. The strict result was identical at every position: 14/15.
| Target position | Strict passes | Completed responses | Conditional retrieval | Latency p50 | Latency p95 |
|---|---|---|---|---|---|
| Near 5% | 14/15 | 15/15 | 14/15 | 12.745s | 28.542s |
| Near 50% | 14/15 | 15/15 | 14/15 | 13.495s | 40.405s |
| Near 95% | 14/15 | 14/15 | 14/14 | 9.679s | 24.571s |
We therefore found no observable end-to-end position penalty in this sample. That is narrower than saying MiniMax M3 has no “lost in the middle” behavior. With only 15 attempts per position, the test can miss smaller or task-dependent effects, and it measures exact synthetic retrieval rather than long-form reasoning across many dispersed facts.
768K and 900K pilots: successful, but n=1
After the replicated core, we ran two deliberately labeled pilots with the target near the middle. Both returned the exact expected value.
| Pilot | Actual input tokens | Strict result | Latency | Cached input | Usage-derived cost |
|---|---|---|---|---|---|
| 768K | 767,768 | Pass | 37.019s | 0 | $0.460692 |
| 900K | 899,807 | Pass | 43.206s | 114 | $0.539858 |
MiniMax’s current M3 product page advertises a 1M-token context window while stating a guaranteed minimum of up to 512K, depending on the scenario. Our 900K pilot is consistent with an API accepting and answering one prompt at that size, but it is not a validation of every 900K prompt, nor a million-token reliability claim. See the official MiniMax M3 model page for the provider’s current specification.
Latency increased with length—and the metric is not TTFT
Across the 61 completed responses, end-to-end latency had a median of 12.251 seconds and a p95 of 37.019 seconds. The fastest completed request took 1.580 seconds; the slowest took 70.115 seconds. Core-only latency was 12.243 seconds at p50 and 29.696 seconds at p95.
The median rose from 2.070 seconds at 32K to 26.442 seconds at 520K—a 12.78× increase. The 500K p95 is unusually high because that cell included completed requests around 54 and 70 seconds; its median is much closer to the 520K median. Medians are therefore more representative for comparing these two cells.
These timings cover the client’s complete non-streaming request, including network transit and generation. They are not server-side compute time and not time to first token. Readers choosing between service tiers should also consult our separate MiniMax M3 Standard vs Priority latency test.
The 512K pricing boundary changed the cost
MiniMax’s Standard-tier pay-as-you-go rates verified for this run were $0.30 per million input tokens, $1.20 per million output tokens, and $0.06 per million cached input tokens for prompts at or below 512K. Above 512K, the listed rates were $0.60, $2.40, and $0.12 respectively. Always check the official MiniMax pay-as-you-go pricing page before budgeting, because rates can change.
The 500K cell remained below the boundary, with a median of 499,928 actual input tokens. Its 11 completed calls produced $1.649395 in usage-derived cost, or about $0.149945 per completed call. The 520K cell crossed the boundary, with a median of 519,874 tokens. Its 12 completed calls produced $3.743748 in usage-derived cost, or about $0.311979 per completed call.
That is a 2.0806× increase, or 108.1%, in average observed cost per completed call for roughly 4% more input tokens. The rate-band change is the dominant explanation, although minor differences in exact token counts, output length, and cached tokens also affect individual calls. For planning tools, see our independent MiniMax pricing guide.
Usage-derived estimate versus account balance
The 61 responses that returned usage objects reported a combined 18,396,131 input tokens, 689 output tokens, and zero reasoning tokens. Applying the official rates to those returned fields produced an estimated cost of $7.89035082. The HTTP 500 attempt returned no usage object and is excluded from that figure.
During the run window, the account’s effective balance fell by $8.30, a difference of $0.40964918 from the usage-derived calculation. The console’s daily billing records had not refreshed when we completed the audit, so we could not reconcile that gap to an invoice line. The provider’s finalized console records or invoice—not our formula—are authoritative for billed cost. We publish both observations to avoid presenting an estimate as a settled charge.
Prompt caching had a negligible effect
The benchmark placed a unique nonce near the beginning of each synthetic prompt, so it was intentionally unfavorable to large prefix-cache reuse. Of the 62 attempts, 13 completed calls were fully cold, 48 showed a small cached-input count, and the HTTP 500 had unknown cache status because no usage was returned.
- Total cached input reported: 6,102 tokens.
- Largest cached count on one response: 128 tokens.
- Cached share of returned input usage: 0.0332%.
- Calculated cost without any cache discount: $7.89205770.
- Calculated saving from reported cached tokens: $0.00170688.
This experiment should not be used to judge the maximum benefit of prompt caching; it was a retrieval benchmark with deliberately distinct prompts. For a cache-friendly application design, read MiniMax’s official prompt-caching documentation and our prompt-caching guide.
The three failed attempts
Publishing only an aggregate percentage can conceal very different failure modes. We classified every non-pass:
| Case | Actual input | Target position | Observed result | Classification | Latency |
|---|---|---|---|---|---|
core-256000-r3-p05 | 255,823 | Near 5% | HTTP 200; returned NOT_FOUND | Positive false negative | 12.085s |
core-500000-r2-p95 | Approximately 500K | Near 95% | HTTP 500; server_error, “unknown error, 512 (1000)” | API error | 30.385s to error |
core-520000-r2-p50 | 520,357 | Near 50% | HTTP 200; returned NOT_FOUND | Positive false negative | 27.593s |
The two retrieval failures were not caused by a verbose answer violating the exact-match rule: both returned the permitted negative label despite the target being present. Conversely, every negative control returned the expected absence result. The 500K failure is an availability event, not evidence of a retrieval miss.
How we ran the experiment
Synthetic corpus and target task
We generated deterministic English records so that every case had a known answer. A positive prompt contained one unique value associated with a unique lookup key. The instruction required the model to return that value and nothing else. A negative control omitted the requested key and required the literal response NOT_FOUND.
For each of the five core lengths, we ran three independent positive cases at each of three positions—near 5%, 50%, and 95%—plus three negative controls. That produced 45 positives and 15 negatives. We then added one middle-position positive pilot at 768K and another at 900K.
Request configuration
- Endpoint:
/v1/responses. - Returned model:
MiniMax-M3on every completed response. - Service tier:
standard. - Reasoning effort: none; returned reasoning-token total: 0.
- Non-streaming;
store=false; truncation disabled. - Maximum output: 64 tokens; temperature: 0.1; top-p: 0.95.
- Concurrency: one sequential request at a time.
- Retries: zero for generation attempts.
We used the official Responses input-token estimator to construct the target lengths before generation. The final estimator-versus-returned-usage difference was no more than seven tokens in absolute terms, and calibration stayed within ±0.25%. The 500K prompts therefore remained below 512K while the 520K prompts were genuinely above it. The request fields follow MiniMax’s official Responses API reference; readers can also use our independent Responses API guide.
Scoring rules
Scoring was automated and case-sensitive. A response passed only if its full text equaled the expected unique value, or NOT_FOUND for a negative control. Leading or trailing whitespace, added explanation, the wrong value, an incorrect absence response, or an API error all counted as end-to-end failures. We also report conditional retrieval separately so readers can distinguish model-answer errors from transport or server failure.
Download the reproducibility evidence
The evidence package contains the benchmark harness, case-level CSV and JSONL data, sanitized response records, calibration files, the run manifest, machine-readable and human-readable summaries, and a SHA-256 checksum manifest. It excludes API secrets, full generated prompts, and unsanitized raw response objects.
Package maintenance — verified July 30, 2026: This ZIP was rebuilt with portable POSIX paths and a verified internal checksum manifest. The published long-context result is unchanged. ZIP SHA-256: 167ce48b1c343b7cdcd83a6d4359ac3bcd4a248b375bc8bdb1f2c9c1cfc836d7.
Start with summary.md for a readable overview, then inspect requests.csv for request-level outcomes and SHA256SUMS.txt to verify file integrity. The public package is designed to support audit and reruns without exposing credentials or unnecessarily republishing the entire synthetic prompt corpus.
What this benchmark proves—and what it does not
Supported conclusions
- MiniMax M3 completed 61 of 62 live Responses API attempts in this run.
- It achieved 42/45 strict end-to-end positive retrievals across the replicated core, with all three tested positions finishing at 14/15.
- It produced no false positive in 15 negative controls.
- It accepted and correctly answered the specific 768K and 900K pilot prompts.
- Client-observed median latency increased substantially as prompts grew.
- Crossing the 512K rate band materially changed usage-derived cost in this experiment.
Claims this test cannot support
- It does not prove perfect recall at any length.
- It does not estimate reliable 768K, 900K, or 1M performance; the upper cells had one attempt each.
- It does not establish that marker position never matters for other data, prompts, languages, or reasoning tasks.
- It does not measure time to first token, streaming responsiveness, multi-user throughput, or Priority-tier latency.
- It does not replicate production retrieval-augmented generation, where chunking, ranking, citations, noisy documents, and conflicting evidence introduce additional failure modes.
- It does not make our usage-derived calculation an invoice.
For a practical architecture discussion beyond synthetic retrieval, see our guide to building long-context RAG assistants with MiniMax.
Practical recommendations
- Count tokens before every very large call. A small increase around 512K can move the entire request into a higher rate band.
- Separate API completion from answer accuracy. Report end-to-end and conditional metrics so an HTTP failure is not mislabeled as a reasoning or retrieval error.
- Include negative controls. Long-context systems must know when the answer is absent, not merely recover planted values.
- Replicate business-critical lengths. Treat a one-shot success as a feasibility check, then run enough cases for useful confidence intervals before deployment.
- Test your actual workload. Repeat the protocol with real document structure, query types, output schemas, and concurrency limits.
- Preserve an evidence trail. Keep request IDs, exact settings, returned usage, scoring rules, and sanitized outputs so regressions can be distinguished from prompt changes.
Frequently asked questions
Does MiniMax M3 support a one-million-token context window?
MiniMax’s current M3 product page advertises a 1M-token context window and states a guaranteed minimum of up to 512K depending on the scenario. This independent test reached 899,807 actual input tokens successfully once, but we did not run a 1M case and cannot infer a reliable million-token success rate from that pilot.
Was MiniMax M3 reliable at 900K tokens?
The single 900K pilot passed, which demonstrates that one specific request worked. Reliability requires repeated, varied cases. With n=1, the 95% Wilson lower bound is only about 20.65%, illustrating why the result should not be reported as “100% accurate at 900K.”
Did MiniMax M3 lose information in the middle?
Not detectably in this sample. Targets near 5%, 50%, and 95% each produced 14/15 strict end-to-end passes. This result does not rule out smaller position effects or failures on more complex tasks.
Why did cost jump between the 500K and 520K cells?
The actual 500K prompts remained under MiniMax’s 512K Standard-tier pricing boundary, while the 520K prompts crossed it. The listed input, output, and cached-input rates were twice as high above that boundary on the test date. Our observed average usage-derived cost per completed call rose from about $0.149945 to $0.311979.
How accurate was MiniMax M3 in the replicated test?
The 60-request core produced 57 strict end-to-end passes (95.0%). Positive retrieval was 42/45 end to end and 42/44 when restricted to completed responses. Negative controls were 15/15, with no observed false positives.
Were the long prompts served from cache?
Only trivially. Returned usage contained 6,102 cached tokens across more than 18.39 million input tokens, a cached share of 0.0332%. The calculated saving was about $0.0017, so caching did not materially drive these results.
Is the reported $7.89 the final billed amount?
No. It is an estimate calculated from the usage fields returned by 61 completed responses and the official rate card. The account’s effective balance fell by $8.30 during the run, while detailed daily billing records had not yet refreshed. MiniMax’s finalized console records or invoice are authoritative.
Does this replace testing on my own documents?
No. Synthetic exact retrieval isolates one useful capability, but production workloads add formatting, ambiguity, multi-hop reasoning, retrieval quality, citations, and domain-specific language. Use these results as a baseline and rerun the method with your own representative inputs.
Is the latency result time to first token?
No. Requests were non-streaming, so the reported value is client-observed end-to-end request time. It includes network transit and the full response, and should not be compared directly with a streaming TTFT measurement.
Related independent MiniMax M3 tests
- MiniMax M3 tool-calling benchmark
- MiniMax M3 Standard vs Priority latency test
- MiniMax M3 API endpoint parity test
- MiniMax M3 model overview
Official sources
- MiniMax M3 model page
- Responses API: create a response
- Responses API: count input tokens
- MiniMax prompt-caching documentation
- MiniMax pay-as-you-go pricing
Testing and independence disclosure: MiniMax-AI.chat is an independent editorial site and is not owned by or affiliated with MiniMax. We funded and executed this benchmark using a dedicated API key. MiniMax did not select the prompts, review the results, or sponsor this article. Product specifications and prices can change; official MiniMax documentation remains authoritative.