feat(text): default to MiniMax-M3 with 8192 max-tokens

[raylanlin]

Background

MiniMax-M3 launched 2026-06-01 as MiniMax's new frontier reasoning model. mmx CLI should default to M3 going forward. M3 is a reasoning model — its thinking phase consumes tokens, so the default 4096 max_tokens is too tight (responses often come back all thinking with no text). Bump to 8192.

This PR is built on top of #168. Once #168 merges, this will land on top of its commits.

Changes

1. src/sdk/text/index.ts: default model M2.7 → M3, max_tokens 4096 → 8192
2. src/commands/text/chat.ts: same defaults, update help text
3. src/commands/text/repl.ts: same defaults, update help text
4. test/commands/text/chat.test.ts: update assertion to expect M3
5. src/commands/text/chat.ts + src/commands/text/repl.ts: reword the example commands to use the M3 default instead of pinning a specific model on the CLI. Help text and docs reference M3 only.

Why M3 is OK as default now

• Available since 2026-06-01
• Supported on both Plus and Max subscription tiers
• 8192 max_tokens gives thinking + text enough room
• Users who prefer M2.7 can still run mmx config set default_text_model MiniMax-M2.7

Refs #168

[TumCucTom]

good change. the 8192 max_tokens rationale (thinking + text headroom) is well-articulated, and unifying the SDK default with the help text removes a footgun where the two disagreed about what mmx chat actually does.

one thing to think about: M3 thinking is heavy, so a Plus user on the new default may burn through their 5h quota faster than they did on M2.7. probably fine, but a quick "tested over a 4h window on Plus" note in the PR body would pre-empt a "regression" report.

sequencing: the PR is built on top of #168's commits. if maintainers prefer squashed merges the dependency on specific commit hashes could get awkward. worth a quick note on whether you want to rebase onto main after #168 lands or keep it stacked.

approving.

[NianJiuZst]

Hi @raylanlin — thanks for putting this together. Moving the CLI default toward MiniMax-M3 makes sense now that M3 is the current frontier model, but could you please refresh this PR before we consider merging it?

A few points are now different in the current official API documentation:

1. max_tokens=8192 is not the official M3 recommendation. The current MiniMax Messages API documentation says that for MiniMax-M3 the recommended max_tokens value is 131072 (128K) and the maximum is 524288 (512K). For other supported models, the documented recommendation is 65536 (64K) and the maximum is 204800 (200K). max_tokens is an output ceiling, so 8192 can still be chosen as a conservative CLI policy, but it should be documented and justified as such rather than presented as the MiniMax default/recommendation.

2. The current thinking rationale does not match the request this PR builds. The same official documentation says that when the thinking parameter is omitted, thinking is disabled by default for M3. This PR changes the model and token ceiling, but it does not add thinking: { type: "adaptive" } (and ChatRequest currently has no thinking field). Therefore, the statement that 4096 is consumed by “thinking + text” does not apply to the current request body. Please either add an explicit M3 thinking control with a clear opt-out, or revise the rationale so the default behavior is accurately described.

3. The M3 parameter surface should be updated consistently. The current CLI help still documents temperature as (0.0, 1.0], while the M3 Messages API documents [0, 2] with default 1; it also documents top_p default 0.95. If M3 becomes the default, the help text, request types, validation, and tests should reflect the M3 contract.

4. Please rebase and remove the stacked quota changes. This branch still contains the feat(quota): align types with coding-plan API, show boost multiplier #168 quota commit, while main has since merged fix(quota): render weekly boost (150%) and unlimited (status=3) quota #177 with the newer weekly-boost and unlimited/status handling. The PR is currently conflicting, and keeping the old quota commit would mix an unrelated, superseded implementation into the M3 change.

My suggested end state would be a clean, text-only PR rebased onto the latest main that:

• switches the CLI/SDK default model to MiniMax-M3;
• uses model-aware token defaults (128K for M3 and 64K for other models if following the official recommendation), while preserving the explicit --max-tokens override;
• makes an explicit decision about whether M3 thinking is enabled or disabled by default; and
• adds focused coverage for the M3 default, non-M3 models, config overrides, and --max-tokens.

If the project intentionally prefers a lower default than the official recommendation, that is also reasonable, but it would be helpful to state the CLI-specific tradeoff and include evidence for the chosen value. Thanks again — the M3-default direction is useful; this mainly needs a current, narrowly scoped implementation.