Skip to content

[verified] fix minimax m3 context resolution - #43464

Closed
zhao0112 wants to merge 2 commits into
NousResearch:mainfrom
zhao0112:fix/minimax-m3-context-43400
Closed

[verified] fix minimax m3 context resolution#43464
zhao0112 wants to merge 2 commits into
NousResearch:mainfrom
zhao0112:fix/minimax-m3-context-43400

Conversation

@zhao0112

Copy link
Copy Markdown
Contributor

Summary

  • Fix MiniMax context-length resolution to prefer OpenRouter model metadata for MiniMax providers before models.dev fallback, so M3 variants resolve to 1,048,576 tokens instead of 512k.
  • Add regression test for MiniMax M3 context length in tests/agent/test_minimax_provider.py.

Closes #43400.

Verification

  • python3 -m py_compile agent/model_metadata.py tests/agent/test_minimax_provider.py
  • python3 -m pytest --override-ini addopts="" -q tests/agent/test_minimax_provider.py

@alt-glitch alt-glitch added type/bug Something isn't working P3 Low — cosmetic, nice to have comp/agent Core agent runtime: loop, agent_init, prompt builder, context-compression, responses endpoint provider/minimax MiniMax (Anthropic transport) labels Jun 10, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

Related: competing fix for #43400 with #43469. This PR prefers OpenRouter metadata before models.dev for MiniMax providers; #43469 widens the stale-cache invalidation threshold. Both target the same M3 512K-vs-1M bug (saturated cluster #37289/#38298/#37235). Note this PR also touches hermes_cli/profiles.py outside the stated scope.

@austinpickett austinpickett left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Canonical fix for the MiniMax-M3 context resolution bug. Four-file diff, well-structured.

model_metadata.py (line ~1118): Inserts a MiniMax-specific early lookup via _resolve_nous_context_length (OpenRouter catalog) before the models.dev fallback, for any model with effective_provider in {"minimax", "minimax-cn"}. This directly addresses the root cause: models.dev was returning 512K for M3, which OpenRouter correctly reflects as 1,048,576. Sound approach.

tests/agent/test_minimax_provider.py: + test_minimax_m3_resolves_to_one_million correctly exercises M3 slugs (bare, lower-case, dated variant) and asserts 1,048,576. Good coverage.

hermes_cli/profiles.py: The _make_writable rmtree error callback is a self-contained fix for macOS immutable-flag deletion failures. Clean, defensive, properly tested. Reasonable to include here, though technically unrelated to MiniMax.

tests/hermes_cli/test_profiles.py: test_deletes_read_only_contents exercises the retry path. The monkey-patching of os.unlink is a pragmatic approach given the macOS-only nature of chflags.

Relationship to #43469: Both PRs touch agent/model_metadata.py but at different line ranges#43469 modifies the stale-cache invalidation block (~line 1621) while this PR modifies the resolution-order block (~line 1118). They are complementary rather than conflicting. This PR addresses the root cause (prefer OR over models.dev for MiniMax). The cache-invalidation widening from #43469 remains a useful guard for users with already-persisted 512K entries, but that's separable; this fix is the more important path. Closing #43469 with a pointer here.

✅ Approved.

@austinpickett austinpickett left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Approved

What it fixes (two independent changes):

  1. agent/model_metadata.py — For MiniMax providers, call _resolve_nous_context_length() (OpenRouter-backed) before falling through to models.dev. models.dev can return stale 512K for M3; OR has the correct 1,048,576. Priority fix is correct and guards behind effective_provider in {"minimax", "minimax-cn"} so only MiniMax is affected.

  2. hermes_cli/profiles.py_make_writable error callback for shutil.rmtree on delete_profile. Handles macOS immutable flags (chflags) and Windows read-only dirs. Good defensive implementation.

Note: PR #43469 also touches model_metadata.py at line ~1612 (cache invalidation threshold) — non-overlapping hunk, both can merge cleanly as complementary fixes.

Reviewed by Hermes Agent

@teknium1

Copy link
Copy Markdown
Contributor

Thanks for the focused MiniMax investigation. This automated hermes-sweeper review found that current main already provides the requested behavioral guarantee.

  • agent/model_metadata.py:2373-2384 rejects the stale 512K models.dev result for MiniMax-M3 and returns the 1,000,000-token catalog value.
  • The minimax-m3 catalog entry is present at agent/model_metadata.py:281-287, and regression coverage is in tests/agent/test_minimax_provider.py:24-32.
  • This shipped via 5a4297a11a83c38ac24eec7df0e4e41d6b3dbb9f (fix(model_metadata): prefer hardcoded 1M for MiniMax M3 over stale models.dev probe), contained in v2026.6.19.
  • The unrelated profile-deletion callback is also superseded by the broader current-main deletion/retry path at hermes_cli/profiles.py:1433-1592.

Closing as already implemented on main.

@teknium1 teknium1 closed this Jul 14, 2026
@teknium1 teknium1 added the sweeper:implemented-on-main Sweeper: behavior already present on current main label Jul 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/agent Core agent runtime: loop, agent_init, prompt builder, context-compression, responses endpoint P3 Low — cosmetic, nice to have provider/minimax MiniMax (Anthropic transport) sweeper:implemented-on-main Sweeper: behavior already present on current main type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

minimax m3 supports a context of 1m, but hermes always automatically recognizes 512k

4 participants