fix(model_prices): correct max_input_tokens for minimax/MiniMax-M3 (512K → 1M)

[ferr079]

Title

Corrects max_input_tokens for minimax/MiniMax-M3 from 512000 to 1048576.

Relevant issues

Follow-up to #29412 (merged with the 512K value) — see my review comment there: #29412 (comment)

Type

🐛 Bug Fix

Changes

Per MiniMax's official specs, MiniMax-M3 ships a 1,048,576-token (1M) context window (MSA architecture). The 512K figure is MiniMax's long-context billing threshold — requests at or below 512K input tokens are billed at the base rate — not the model's context window.

With 512000, LiteLLM's context-window checks (and routing/fallback logic based on max_input_tokens) would reject or misroute valid requests between 512K and 1M tokens.

• model_prices_and_context_window.json: 512000 → 1048576
• litellm/model_prices_and_context_window_backup.json: same

Sources:

• MiniMax official model page / API docs (M3: 1M context)
• OpenRouter listing for MiniMax-M3 (1,048,576 context)
• Consistency with sibling minimax/MiniMax-M2.x entries in this file, which all use 1000000

Pricing fields are untouched ($0.60/M input, $2.40/M output are correct).

🤖 Generated with Claude Code

[CLAassistant]

All committers have signed the CLA.

[greptile-apps]

Greptile Summary

This PR corrects max_input_tokens for minimax/MiniMax-M3 from 512000 to 1048576, fixing a bug where LiteLLM would reject or misroute valid requests between 512K and 1M tokens. Both the main and backup JSON files are updated identically.

• max_input_tokens changed from 512000 → 1048576 in both model_prices_and_context_window.json and its backup; all other fields (pricing, capability flags) are untouched.
• The 512000 value was MiniMax's long-context billing threshold, not the actual context window; the corrected 1048576 matches OpenRouter's listing for MiniMax-M3.

Confidence Score: 5/5

Safe to merge — the change is a targeted single-field data correction in two JSON config files with no code logic touched.

Both files are updated consistently, pricing fields are untouched, and the new value matches the provider's documented 1M context window. The only open question is whether 1048576 (2^20, OpenRouter's figure) or 1000000 (used by the M2.x siblings) better reflects MiniMax's own spec, but either way the old 512000 was clearly wrong.

No files require special attention.

Important Files Changed

Filename	Overview
model_prices_and_context_window.json	Single-field correction: max_input_tokens for minimax/MiniMax-M3 changed from 512000 to 1048576 (1M, matching OpenRouter's spec).
litellm/model_prices_and_context_window_backup.json	Backup JSON kept in sync with the main file; identical single-field correction applied.

_{Reviews (1): Last reviewed commit: "fix(model_prices): correct max_input_tok..." | Re-trigger Greptile}

[greptile-apps]

Slight value inconsistency with sibling MiniMax-M2.x entries

All four sibling minimax/MiniMax-M2.x entries (M2, M2.1, M2.1-lightning, M2.5, M2.5-lightning) use 1000000 as their max_input_tokens, while M3 is now set to 1048576. Both represent "1 million tokens", but 1048576 is 2^20 (the binary interpretation used by OpenRouter) while 1000000 is the decimal round figure. If MiniMax's official API documentation states 1048576, the value here is correct — but it's worth confirming whether MiniMax's own spec uses the binary or decimal value, for consistency with the rest of the MiniMax family in this file.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[ferr079]

CLA signed ✅

Note on the failing misc / Run tests check: test_aaamodel_prices_and_context_window_json_is_valid fails with 'tool_use_system_prompt_tokens' was unexpected — that property comes from another entry already present on the base branch litellm_oss_staging_050626 (commit a419c7b, an entry with supports_xhigh_reasoning_effort), not from this PR. This diff only changes two numeric values (512000 → 1048576) and introduces no new keys, so the failure is pre-existing on the staging branch and should affect every PR based on it today.