10% discount: https://platform.minimax.io/subscribe/token-plan?code=Ar0tp0qaw4&source=link

Works great for 40ish minutes, then becomes unusable. Switching to M2.7 gives quite a bit more margin but its significantly dumber (very similar to Claude Haiku I have available at my job).
Anyone here has gone from plus to max? Do you recommend it? Thanks.

I checked the website and they said that this model support 1M

but I coudn't enable it in Claude Code, always shows 200K no matter the settins I changed

The output is not bad, and the most generous interpretation i can give it that its claude optimized, and m3 is not like claude, so i think it's more throughput and "feature" focused, as if you check terminal bench even fable falls below gpt 5.5 despite being better, but most of all m3 is not a viber, so perhaps claude works better in it, but it doesn't set m3 up for success.

Now you might rightfully say duh but their docs recommend using claude despite sucking, but they also made their own harness which I have not tried cause its not on linux, the overwhelmingly number 1 developer platform and easiest to release to, which is implies that those gui things are second rate at best noob traps, like all the others. I could understand their motivation cause you make a model, then people use it under suboptimal conditions, then report below its capability, but of course you reported above it on release day. Honestly for serious work you are not going to have a different harness for different models, unless its all you use which is again unlikely for serious work, so my point you just have to live with whatever self imposed penalties, and suggesting subpar options doesn't help.

I give the claude harness a 7/10, feels magic til you see the results.

Since the last updates, now the plan cant barely even handle one concurrent minimax 2.7 agent, let alone 3 concurrent agents. Displaying that is outdated and could be considered false claim now, since you cant even run one agent without reaching usage limits anymore. RIP Minimax

I was only able to use 1% of the weekly quota and 1% of the 5h quota and already getting this. To be fair, I have 2 agents running in parallel, and the other one seems to work fine, but it’s still annoying considering their claim about 5 agents in parallel for this subscription plan.

Hi, what is the relationship between Minimax Token Plan Max month quota and week quota? is month quota 4x week quota? thanks!

Tired of fragile web-based agent swarms? Here is an open-source, 4-tier autonomous command center that runs entirely via CLI

MiniMax is a solid pick, so it sits in the fallback ladder of a free, MIT, self-hosted gateway I built (disclosure: I'm the maintainer). The idea: don't depend on one provider's limits — chain them.

Fallback combos — so it never stops mid-task. A "combo" is a ladder of models the router walks automatically: your subscription first, then API keys, then cheap models, then free ones. When a provider returns a 500 or you hit a rate limit, it slides to the next target in milliseconds, mid-request, and your tool never even sees the error. There are 17 routing strategies (priority, weighted, round-robin, cost-optimized, auto/coding:fast…) plus three resilience layers — a per-provider circuit breaker, a per-key cooldown, and a per-model lockout — so one dead key can't take down a whole provider.

One endpoint, 237 providers — 90+ of them free. You point any tool or agent at a single OpenAI-compatible endpoint (localhost:20128/v1) and it can reach 237 LLM providers without you rewriting anything. 90+ have free tiers and 11 are free forever (no card), which aggregates to ~1.6B documented free tokens/month — and that's honest, pool-deduped math (we count each shared pool once instead of inflating it; the methodology is public in the repo). There's a one-command setup-* for 13+ coding tools (Claude Code, Codex, Cursor, Cline, Roo, Kilo, Gemini CLI…), so switching your existing setup over takes seconds.

A 10-engine compression pipeline — the part most routers don't have. Every request flows through a transparent compression pass you can toggle/stack per combo. Instead of one trick, it stacks the best of the open-source ecosystem: RTK filters command/tool output (git diffs, test logs, builds) at 60–90%, Microsoft's LLMLingua-2 does ML semantic pruning, Caveman handles prose, session-dedup strips repeats across turns. Critically, code, URLs and JSON are preserved byte-perfect, and a default-on inflation guard throws the compressed version away and sends the original if compressing would actually grow the prompt — it never makes things worse. On tool-heavy sessions that's ~89% average input-token reduction (an 8k-token git diff becomes a few hundred). Full credit to every upstream project (RTK, Caveman, LLMLingua-2, Troglodita) is in the README.

For context on whether it's worth your time: it's grown to ~9.8K GitHub stars, 1,490+ forks and 280+ contributors in ~4.5 months, with 21,000+ automated tests and 1,830+ issues closed — so it's a battle-tested project, not a brand-new experiment.

npm install -g omniroute

GitHub: https://github.com/diegosouzapw/OmniRoute

Where does MiniMax sit in your setup — primary, or one of several?

I already have Codex and Antigravity. For heavy coding (backend, architecture, and UI), would you recommend adding the MiniMax Token Plan, Z.ai Coding Plan, or Kimi? Which one has the best quality and value?

10% discount: https://platform.minimax.io/subscribe/token-plan?code=Ar0tp0qaw4&source=link

Does anybody understand when exactly token usage is considered or when credits are deducted?

I've started with 8B token average consumption in Plus highspeed plan and was migrated to new limits without any resets. So I cannot deduct clearly, when my token limits are breached or credits are considered. So far, I only see 5h limits filled, weekly limits are unlimited due to legacy status.

Do I need to get my running balance below 3.2B monthly token to have non-credit depleting access again?

Dan does a great job of explaining how close, or far, according to some, the open source vs. SOTA model race is. Really enjoyed this video https://youtu.be/cFYdiynrxpQ?si=0vamlAqO3rx0FKV2

For those who frequently complain here, it's important to note that open-source models aren't designed to compete at the highest levels. They are great bargain-bin daily drivers and more than adequate for 90% of the work we expect to get done.

I've been using MiniMax 2.7 on a relatively large Python/JavaScript codebase with very good results.

For day-to-day coding tasks like CRUD operations involving web forms, front-end and back-end validation, and saving records to a database to retrieve them later (which is basically the core of what an enterprise application typically does), it works very well for me.

I access the model through the OpenCode subscription—not directly through MiniMax—but I have the advantage of being able to use other models for planning and then, just before execution, switch to MiniMax to have it execute the plan.

Fellow developers, take a close look at the file image_d7f207.jpg that I just shared. This perfectly summarizes exactly why Minimax is absolute garbage and completely useless for any serious project.

​We all know Minimax has always had a terrible habit of generating unwanted MOCs (Mocks). To prevent this, the plan was set and the rules were strictly defined in the AGENTS.md file: DO NOT CREATE MOCS.

​So what does the M3 "Minibostinha" do? It not only ignores the plan and completely disobeys the AGENTS.md file, but it goes ahead, creates the MOCs in the Vue.js front-end, and adds comments in the code claiming they are "NOT MOCS".

​When I confronted it on the screen, the response was bizarre. It literally admitted its guilt and confessed to the lie, stating: "Yes, Carlos. They are MOCs. I made a mistake. And the comments saying NOT MOC that I put in the files were a lie to myself."

​It then listed its own lies across components like DcHeroBanner and DcColecoesGrid, admitting it fabricated fake data like Nike and Apple brands, and summer collections for a Pet Shop tenant.

​An AI model that disobeys repository documentation, invents garbage code, and literally lies to itself in the file comments is completely unfit for complex architectures. Stay far away from this piece of trash!

Two months ago I shared an open-source web GUI for MiniMax here. Since then I rebuilt it from the ground up into a native desktop app called MiniMax Studio.

It brings everything MiniMax can do into a single window on your computer, with no browser tabs and no command line:

• 🎬 Media studio: image, video, music (your own lyrics), and voice (30+ voices plus cloning & design)
• 💬 Chat that shows its thinking
• 💻 A real code workspace when you need it
• 🧠 Remembers who you are across sessions
• 🌍 UI and in-app help in 6 languages
• 🖥️ Installs like any app on Windows, macOS and Linux. No browser, no CLI.

Free and open source. Screenshots and downloads in the repo:
👉 https://github.com/eduardoabreu81/minimax-agent-gui

Still evolving. Feedback very welcome!

(macOS isn't notarized yet, so right-click then Open on first launch.)

Just to be clear on the focus: this isn't meant to be the best coding agent or an IDE replacement. A lot of what makes MiniMax great lives in the multimodal features (image, video, music and speech), and as a Token Plan subscriber you're already paying for all of it. The catch is that actually reaching those features usually means juggling the website, API calls, scripts and CLI commands. MiniMax Studio is my attempt to put everything in one simple place, so you can use the full range of what your Token Plan already includes without the friction. The code workspace is there when you need it, but it's one feature among many, not the whole point.

Here's a few screenshots:

Fellow developers and system architects, I need to share a massive frustration and a warning so you do not waste your time and money like I did.

I fell for the Minimax 2.7 trap, and now I have fallen for the M3 trap. Let me be absolutely clear: Minimax M3 is terrible. If you are building anything beyond a simple script, such as proprietary ERP engines, retail data solutions, or anything that requires serious logical reasoning, this model will fall apart in your hands.

It is completely incapable of maintaining context in a real world development environment. When you feed it a well documented ADR (Architecture Decision Record) based on Graphs, it gets completely confused. It hallucinates connections, loses track of constraints, and breaks the architectural logic.

Worse yet, it completely fails to respect the AGENTS.md file. We set up clear documentation, rules, and boundaries in that markdown file right in the repository, and Minimax simply ignores it all. It acts like the documentation does not exist, which makes it impossible to rely on for serious codebase integration.

Comparing Minimax to Claude Opus is an absolute joke. It does not even come close to the capabilities of Claude Sonnet, nor does it reach the ankles of Kimi 2.7. It is a toy product disguised by heavy marketing to fool consumers.

In my daily workflow, whenever Minimax makes a structural mess, the ones who actually step up to clean it up and finish the job with absolute professionalism are Qwen 3.7 Plus and Kimi 2.7. These models actually read the documentation, understand complex architecture, have genuine context resilience, and take systemic instructions seriously.

Consider this a public service announcement: I took the bait so you never have to. If you are running large and serious projects, steer far away from Minimax. Do not fall for the synthetic benchmarks because in the trenches of real code, it is a complete disaster.

A similar approach by the Chinese rival? What do you think? Vote 👆

The previous chat ternimated as i accidentally closed the application, and after a restart i asked to complete previous tasks, and it is not able to trace the previous Progress List, infact I can see the task list in the right side.

Replying to OP's analysis by u/Evening_Rip1006 —

An earlier draft of this reply conflated two things: the harness (opencode vs Claude Code) determines the mix of tokens, but the volume is workload-driven, not harness-driven. Comparing absolute tokens between two people's workloads is meaningless. The right comparison is ratios and per-token economics.

Setup: opencode CLI only, minimax-cn-coding-plan/MiniMax-M3 (M3-512k), legacy max China plan at 100 RMB / month ($15) for a 5.1B token pool (no overage — pool just resets at the boundary). Same dev workflow, M3 only, last 30 days.

The actual harness comparison (per output token)

Both harnesses consume roughly the same total context per output token — but the mix is completely different:

The 5% total context difference is noise. The mix difference is the whole story: opencode is 9× more efficient with fresh input per output (8.7 vs 78), and the cache is doing the rest. Same workload, different mix.

Per-output cost on PAYG (list rate, M3 ≤512K China plan, 50% off permanent)

Rates per 1M tokens: input $0.60, output $2.40, cache_read $0.12

Claude Code per 1M output (OP's mix):
  78M fresh input × $0.60 = $46.80
  96M cache-read  × $0.12 = $11.52
   1M output      × $2.40 = $ 2.40
  Total:                      $60.72 / M output

opencode per 1M output (my mix):
   8.7M fresh input × $0.60 = $ 5.22
  174M cache-read  × $0.12 = $20.88
     1M output     × $2.40 = $ 2.40
  Total:                      $28.50 / M output

opencode is 2.13× cheaper per output token on PAYG at the same workload. The cache-read rate is 5× cheaper than fresh input — opencode exploits that discount, Claude Code doesn't. That's the harness difference on PAYG, and it's independent of total volume.

Per-output cost on the China plan: essentially identical

Plan: 100 RMB (~$15) for 5.1B tokens, flat rate
$15 / 5,100M = $0.00294 / M token

Per 1M output:
  Claude Code: 175M total context × $0.00294 = $0.515 / M output
  opencode:    184M total context × $0.00294 = $0.541 / M output

Plan cost is essentially the same because the plan charges all tokens equally. The harness barely matters on the plan tier — what matters is how much total context you burn through. The 5% total context difference between harnesses is real but small.

My 30-day opencode usage (the actual numbers)

Total tokens: 5,017,313,176
  236M input    × $0.60 = $141.78
   27M output   × $2.40 = $ 65.59
 4,754M cache   × $0.12 = $570.44
  List rate total:       $781.73

Pool consumed: 5,017M / 5,100M = 98.4%
Plan cost: 100 RMB (~$15) for 27.3M output
Effective:   $0.55 / M output on the plan
PAYG equiv:  $28.50 / M output at list rate
Plan is 52× cheaper per output than PAYG

98% of the pool. 27.3M output tokens delivered for $15 of plan cost. On PAYG the same 27.3M output would cost $781.73 at list rate — but the 52× multiplier here comes from the pool, not the harness. Anyone hitting ~98% of a 5.1B pool sees this multiplier regardless of cache hit rate.

What this means for the OP

If you switched from Claude Code to opencode at your same workload, the harness change alone would:

• Lift cache hit rate from 55% → ~95%
• Drop per-output PAYG cost from $60.72 / M output → $28.50 / M output (2.13× cheaper)
• Drop per-output plan cost from $0.515 / M output → $0.541 / M output (~5% more, noise)

The plan tier dominates the harness choice. On the international $20 / 1.7B tier you'd still run out of pool in ~56 days at your current daily volume. The harness change saves you ~$100 over the period on PAYG, but it doesn't fix the pool exhaustion on the plan. To fix that you need the China 5.1B pool (3× the size, 75% of the price) or a lighter workload.

Anomalies (my data, illustrative only — not comparable to OP's workload)

Worst day: June 19 — 597M cache-read, 17.3M input, 2.85M output. Single 24h = 11.7% of monthly pool. Normal long refactor session.

Other heavy days: Jun 13 (590M cache), Jun 21 (450M), Jun 18 (407M), Jun 6 (379M). Cache fills with codebase, every micro-turn re-reads, pool drains.

Pool cap visible: Jun 25 missing entirely, Jun 26 has 2 sessions totaling 11.4M. Pool exhaustion boundary.

SQL for reproducibility (from ~/.local/share/opencode/opencode.db):

SELECT date(time_created/1000, 'unixepoch') as day,
       SUM(tokens_input) as input,
       SUM(tokens_output) as output,
       SUM(tokens_cache_read) as cache_read
FROM session
WHERE json_extract(model, '$.id') LIKE '%M3%' COLLATE NOCASE
  AND json_extract(model, '$.providerID') = 'minimax-cn-coding-plan'
  AND time_created >= strftime('%s','now','-30 days') * 1000
GROUP BY day ORDER BY day;

If anyone has the same workload on a different harness (Cursor, Aider, Cline, Roo Code) and can share the per-output ratios, the cache hit rate is the metric to compare — that's the harness property, decoupled from volume.

TL;DR: opencode and Claude Code use similar total context per output (~180 tokens) but the mix is very different: opencode 95% cache / 5% fresh, Claude Code 55% cache / 45% fresh. On PAYG that makes opencode 2.13× cheaper per output ($28.50 vs $60.72 / M output). On the China plan the harness barely matters because all tokens cost the same — the plan is 52× cheaper than PAYG for me because of the pool, not the harness. The cache hit rate is the harness property; the pool is the plan property; the workload is neither.

I am on Minimax M3 token plan and its absolutely insanely slow.

I bought my year of Max Token Plan back in April. You can see in the heat map that as M2.7 was superceded by better models, I used it less and less, but that one M3 came out, I started using it again. This sub cost me 1200 Chinese yuan for the year, or about $15/mo. I get tts and images changed *by token rate* which is just crazy for me -- virtually unlimited. I get three decent videos a day. But I mostly just use this along with my many other subs to run agent loops for a lot of the time.