How do MiniMax rate limits work? Fixed 5-hour windows explained
I hit a rate limit error on MiniMax and couldn’t figure out when it would reset. I kept checking my usage dashboard, waiting for the limit to roll off like it does with OpenAI. It never happened—until exactly 10 AM, when my requests suddenly worked again.
That’s when I realized MiniMax doesn’t use rolling windows. They use fixed 5-hour time windows, and understanding this completely changed how I schedule my coding sessions.
The Problem: Confusing Rate Limit Behavior
I was working on a project using MiniMax’s M2.7 model. Around 9:30 AM, I hit my request limit:
Rate limit exceeded. Please try again later.I assumed it would reset after a few minutes, like most APIs. Nope. I waited. 9:45 AM. Still blocked. 9:58 AM. Still blocked.
Then at exactly 10:00 AM, everything worked again.
This behavior confused me until I dug into MiniMax’s documentation and found they use fixed time windows, not rolling windows. This is fundamentally different from what most developers expect.
How Fixed Time Windows Work
MiniMax divides each day into five fixed windows:
┌─────────────────────────────────────────────────────────────┐│ MINIMAX RATE LIMIT WINDOWS │├──────────────┬──────────────┬───────────────────────────────┤│ Window │ Time │ Resets At │├──────────────┼──────────────┼───────────────────────────────┤│ Window 1 │ 00:00-05:00 │ 5:00 AM (fresh allocation) ││ Window 2 │ 05:00-10:00 │ 10:00 AM (fresh allocation) ││ Window 3 │ 10:00-15:00 │ 3:00 PM (fresh allocation) ││ Window 4 │ 15:00-20:00 │ 8:00 PM (fresh allocation) ││ Window 5 │ 20:00-24:00 │ Midnight (fresh allocation) │└──────────────┴──────────────┴───────────────────────────────┘
Note: Window 5 is only 4 hours, giving you an "extra" hoursince the cycle restarts at midnight.Unlike OpenAI’s rolling windows—where a limit “rolls off” based on when you made each request—MiniMax’s windows reset at fixed times. If you hit your limit at 9:45 AM, you’re stuck until 10:00 AM when Window 3 starts.
Why This Matters for Your Workflow
Once I understood the fixed windows, I realized this is actually better for productivity than rolling windows—if you plan around it.
Predictable Reset Times
You know exactly when limits reset. No guessing, no constantly checking dashboards:
07:00 AM ──► Start coding (Window 2, ~500 requests remaining) │09:45 AM ──► Hit limit │10:00 AM ──► Window 3 starts, fresh 1,500 requests │02:45 PM ──► Hit limit again │03:00 PM ──► Window 4 starts, fresh 1,500 requests │Continue working...Strategic Reset Times for Developers
The reset times align surprisingly well with typical developer schedules:
| Reset Time | Why It’s Useful |
|---|---|
| 10:00 AM | Perfect for mid-morning productivity burst |
| 3:00 PM | Aligns with post-lunch energy dip reset |
| 8:00 PM | Supports evening coding sessions |
| Midnight | Fresh start for night owls |
If you start work at 7 AM, you get a fresh allocation right at 10 AM—perfect timing for your most productive morning hours.
The Two-Limit System: A Common Trap
Here’s where I made another mistake. I thought the 5-hour limit was the only constraint. It’s not.
MiniMax enforces both limits simultaneously:
- 5-Hour Window Limit: Max requests per window
- Weekly Limit: Max requests per calendar week
I learned this the hard way when I got blocked on a Thursday despite having requests left in my current window. I’d hit my weekly cap.
┌─────────────┬──────────────────┬─────────────────┬──────────────┐│ Plan │ 5-Hour Limit │ Weekly Limit │ Cost/Month │├─────────────┼──────────────────┼─────────────────┼──────────────┤│ Starter │ 600 requests │ ~8,400/week │ ~$29 ││ Plus │ 1,500 requests │ ~15,000/week │ ~$10 ││ Max │ 4,500 requests │ ~63,000/week │ ~$199 ││ Ultra │ 30,000 requests │ ~420,000/week │ ~$899 │└─────────────┴──────────────────┴─────────────────┴──────────────┘Important: If you max out every 5-hour window, you’ll hit the weekly limit first. Calculate your actual needs.
For the $10 Plus plan:
- Theoretical max: 1,500 requests x 5 windows x 7 days = 52,500 requests/week
- Actual weekly limit: 15,000 requests
- You can only use ~29% of each window before hitting the weekly cap
How This Compares to Other APIs
After hitting these limits, I compared MiniMax to other AI API providers:
┌─────────────────┬─────────────────────┬────────────────────────────┐│ Provider │ Window Type │ Example Limit │├─────────────────┼─────────────────────┼────────────────────────────┤│ OpenAI │ Rolling (per min) │ 500 RPM (rolls off after ││ │ │ 60 seconds per request) │├─────────────────┼─────────────────────┼────────────────────────────┤│ Anthropic │ Rolling (per min) │ 60 RPM (rolls off after ││ │ │ 60 seconds per request) │├─────────────────┼─────────────────────┼────────────────────────────┤│ Google Gemini │ Rolling (per min) │ 15 RPM (rolls off after ││ │ │ 60 seconds per request) │├─────────────────┼─────────────────────┼────────────────────────────┤│ MiniMax │ Fixed (5 hours) │ 1,500 per window, resets ││ │ + Weekly cap │ at fixed times + 15K/week │└─────────────────┴─────────────────────┴────────────────────────────┘The key difference: Rolling windows reward spacing out requests. Fixed windows reward timing requests.
What Counts as a Request
Another confusion point: MiniMax counts requests (API calls), not tokens.
┌─────────────────────────────────────────┬────────────────────┐│ API Call │ Counts As │├─────────────────────────────────────────┼────────────────────┤│ Simple request (100 tokens) │ 1 request ││ Complex request (10,000 tokens) │ 1 request ││ Multi-turn conversation (5 messages) │ 1 request ││ Streaming response (1 min long) │ 1 request │└─────────────────────────────────────────┴────────────────────┘
All of these count as exactly ONE request.This is good for complex workflows—you’re not penalized for using more tokens. But it also means you can’t optimize by reducing token usage alone.
A Real Workday Example
Let me show you how a typical day looks with the Plus plan (1,500 requests per window, 15,000 per week). I’m a developer who codes roughly 7 AM to 6 PM:
Morning session (7 AM - 12 PM):
- Window 2 (5-10 AM): I start with ~1,000 requests from the window
- By 9:30 AM, I’ve used my allocation
- 10:00 AM: Window 3 resets, I get fresh 1,500 requests
- Continue until lunch
Afternoon session (12 PM - 6 PM):
- Window 3 continues until 3 PM
- 3:00 PM: Window 4 resets, fresh 1,500 requests
- This carries me through the rest of the day
The key insight: I time my heaviest API usage for right after resets. If I have a complex refactoring task that needs many API calls, I start it at 10 AM or 3 PM, not 9:30 AM or 2:45 PM.
Here’s a mistake I made early on:
Day 1-3: Heavy usage, hitting limits in most windowsDay 4 (Thursday): Got blocked at 2 PM │ ▼Error: "Weekly limit exceeded" │ ▼Me: "But I have 1,500 requests left in this window!"Reality: Weekly cap (15K) hit, window limit irrelevantI had to wait until Monday for my weekly limit to reset. Now I track both limits:
Weekly usage: ████░░░░░░ 40% used (6,000/15,000)Window usage: ██░░░░░░░░ 20% used (300/1,500)Next reset: 3:00 PM (in 47 minutes)This simple dashboard view prevents surprises. I know if I’m above 80% weekly usage by Thursday, I need to slow down.
Lessons Learned
After using MiniMax for a few weeks, here’s my workflow:
-
Schedule intensive work around resets. I start big coding sessions at 10 AM or 3 PM to maximize my window.
-
Monitor weekly usage. The 5-hour limit is visible in the dashboard, but the weekly limit can sneak up on you.
-
Don’t wait for rolling resets. If you hit a limit at 9:50 AM, just take a 10-minute break until 10:00 AM. Don’t wait 5 hours.
-
Batch your requests. Since tokens don’t matter for rate limiting, I combine multiple small tasks into single requests.
The fixed-window system seemed strange at first, but now I prefer it. Predictable reset times beat the uncertainty of rolling windows—once you understand the schedule.
Final Words + More Resources
My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me
Here are also the most important links from this article along with some further resources that will help you in this scope:
Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!
Comments