fix(model_prices): MiniMax-M3 max_input_tokens 512000 -> 1048576

[ferr079]

Relevant issues

Follow-up to #29412 (review comment flagging this value before merge) and #29777 (earlier fix PR auto-closed when its staging base branch was deleted). The minimax/MiniMax-M3 entry has now landed on main with the incorrect value, so this re-targets main.

Pre-Submission checklist

• I have Added testing in the tests/test_litellm/ directory — N/A: data-only change (2 lines) to the model cost map, no code path touched
• I have added a screenshot of my new test passing locally — N/A: no new test
• My PR passes all unit tests on make test-unit — not run locally; only verification done is that both JSON files still parse (json.loads) after the edit
• My PR's scope is as isolated as possible, it only solves 1 specific problem

Type

🐛 Bug Fix

Changes

max_input_tokens for minimax/MiniMax-M3: 512000 → 1048576, in both model_prices_and_context_window.json and litellm/model_prices_and_context_window_backup.json.

Why 512000 is wrong: MiniMax-M3 supports a 1M-token context window. The 512k figure is MiniMax's long-context billing threshold (their pricing has two input tiers: ≤512k and >512k), not the model's input limit. With 512000 in the map, LiteLLM rejects/truncates valid requests between 512k and 1M tokens.

Sources:

• MiniMax official API pricing — input tiers ≤512k / >512k imply inputs beyond 512k are supported
• OpenRouter minimax/minimax-m3 — context listed as 1,048,576
• Consistency: sibling minimax/MiniMax-M2.x entries in this map are all 1M-class

Costs ($0.60/$2.40 per 1M) and capability flags are untouched.

[greptile-apps]

Greptile Summary

Corrects the max_input_tokens value for minimax/MiniMax-M3 from 512000 to 1048576 in both the primary model-prices JSON and its backup, fixing a case where LiteLLM would reject or truncate valid requests between 512k and 1M tokens.

• The previous value (512k) was MiniMax's billing-tier boundary, not the model's actual context limit; 1,048,576 matches the documented 1M-token window and aligns with OpenRouter's listing.
• Both model_prices_and_context_window.json and litellm/model_prices_and_context_window_backup.json are updated identically; no code, cost fields, or capability flags are touched.

Confidence Score: 5/5

This is a data-only, two-line correction with no code changes; it unblocks requests between 512k and 1M tokens for MiniMax-M3 and cannot regress any other model or code path.

Both JSON files are updated identically, the new value (1,048,576) is a power-of-two 1M constant consistent with MiniMax's published documentation and sibling model entries, and no capability flags, costs, or code are touched.

No files require special attention.

Important Files Changed

Filename	Overview
model_prices_and_context_window.json	Corrects max_input_tokens for minimax/MiniMax-M3 from 512000 to 1048576 (1M); both files updated identically and the entry is otherwise unchanged.
litellm/model_prices_and_context_window_backup.json	Mirror backup file updated with the same max_input_tokens correction as the primary JSON; change is consistent and complete.

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

[codspeed-hq]

Merging this PR will not alter performance

✅ 16 untouched benchmarks

---

_{Comparing ferr079:fix/minimax-m3-context-window-main (ebc7bf7) with main (9608dd5)}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[ferr079]

Retargeted main → litellm_oss_branch per the Verify PR source branch check (fork PRs to main are rejected; external contributions go through litellm_oss_branch).

Since litellm_oss_branch predates the MiniMax-M3 entry (it landed on main via #29412 → internal staging), the rebased commit adds the entry with the corrected max_input_tokens: 1048576 (same placement as on main, right after minimax/MiniMax-M2). When this branch syncs with internal staging, the conflicting 512000 value should resolve to 1048576.

Rationale unchanged (see PR description): 512k is MiniMax's long-context billing tier boundary, not the context window — M3 is a 1M model like the sibling M2.x entries.

[Sameerlite]

@ferr079 Can you resolve the conflicts? Thanks!

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
2 out of 3 committers have signed the CLA.

✅ yuneng-berri
✅ ferr079
❌ shin-berri
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[ferr079]

@Sameerlite Done — merged litellm_oss_staging_080626 and resolved the conflict, keeping max_input_tokens: 1048576 in both files (M3 is a 1M-context model; 512000 is MiniMax's long-context billing tier boundary, not the window). Ready for merge — thanks!