MiniMax (minimax) provider: model alias suffixed with [1M] is rejected by API

Bug

When the active provider is minimax, oh --dry-run reports the resolved model as MiniMax-M3[1M]. But invoking oh -p "..." with the configured profile fails with:

API error: Error code: 400 - {'type': 'error', 'error': {'type': 'bad_request_error', 'message': "invalid params, unknown model 'minimax-m3[1m]' (2013)", 'http_code': '400'}, 'request_id': '...'}

Reproduction

1. Install openharness-ai 0.1.9 in a clean venv (Python 3.10+)
2. Set provider profile to minimax with valid MiniMax-M3 API key
3. Run oh --dry-run --output-format json → settings.model shows "MiniMax-M3[1M]"
4. Run oh -p "Reply ready" (no --model flag) → rc=0 but stdout empty; stderr has the 400 above

Workaround

Pass --model MiniMax-M3 explicitly (without [1M]). The [1M] suffix appears to be added by OpenHarness when displaying the resolved config but is not stripped before sending to the API.

oh -p "Reply ready" --model MiniMax-M3      # works
oh -p "Reply ready"                          # fails (uses settings.model = "MiniMax-M3[1M]")

Environment

• openharness-ai 0.1.9
• profile: minimax (active)
• settings.json excerpt:
  json复制

  {
    "provider": "minimax",
    "model": "MiniMax-M3",
    "active_profile": "minimax"
  }

Suggestion

When the configured model has an alias-with-context-window suffix (like [1M]), the resolver should either:

• (a) strip the suffix before sending to the API, or
• (b) detect the matching upstream model id from the alias map and substitute

Let me know if you want a PR for this — happy to dig into the resolver code.

Related

• Built a 0-dep Python client (ljg-openharness) that hits this. Working around with default model="MiniMax-M3" in our prompt() wrapper.
• All 29 of our community skills auto-load from ~/.claude/skills/ — really nice compat layer, thanks!