if not, could you send me the pr link so i can debug

but the current version is hacked using a special sdk main script

i shis related to any existig incident?

@nutritious-balloon-65098 can you help me figure out in OpenHands/deploy and OpenHands/OpenHands repo and help me understand where does this minimax-m2.7 override happens

Summary This was a pure investigation/research task — no code changes were made. Question answered: Where does the minimax-m2.7 override happen? It lives entirely in

OpenHands/OpenHands

(not in

OpenHands/deploy

) and flows through two files: 1.

enterprise/server/constants.py

— The root cause • A versioned map

PERSONAL_WORKSPACE_VERSION_TO_MODEL

bumps the default model on each release. The current max version (6) maps to

'minimax-m2.7'

. •

ORG_SETTINGS_VERSION

and

PERSONAL_WORKSPACE_VERSION

are both set to

max()

of that map, currently

6

. •

get_default_litellm_model()

reads from this map (unless the

LITELLM_DEFAULT_MODEL

env var is set, which is the escape hatch the team used to "set it back"). 2.

openhands/app_server/utils/llm.py

— A second hardcoded reference •

DEFAULT_OPENHANDS_MODEL = 'openhands/minimax-m2.7'

is hardcoded and returned as the

default_model

in the

/api/options/models

API response. This requires a code change to update (the env var does not override this one). The auto-upgrade mechanism (why it affects existing users on every release): •

enterprise/storage/org_app_settings_store.py

→

_validate_org_version()

runs on every org fetch. If the org's stored

org_version

is less than the current

ORG_SETTINGS_VERSION

, it `deep_merge`s the new default model into the org's

agent_settings

— silently resetting users to minimax on their next login after a deployment.

OpenHands/deploy

has no minimax-specific configuration — it's all in the application code.

Summary This was a pure investigation — no code changes were made. Here's what was found: Question 1: Where does the minimax-m2.7 override happen? Two places in

OpenHands/OpenHands

: 1.

enterprise/server/constants.py

— the version→model map: ◦

PERSONAL_WORKSPACE_VERSION_TO_MODEL[6] = 'minimax-m2.7'

(current version = 6) ◦

get_default_litellm_model()

reads this to return

litellm_proxy/minimax-m2.7

◦

_validate_org_version()

in

org_app_settings_store.py

uses this to auto-upgrade every existing user's model on next login whenever their stored

org_version

is behind the current one — which is why it feels like a reset on every release 1.

openhands/app_server/utils/llm.py

— hardcoded

DEFAULT_OPENHANDS_MODEL = 'openhands/minimax-m2.7'

, returned as the frontend's pre-selected default by

/api/options/models

The

OpenHands/deploy

repo has no minimax-specific overrides — it's entirely in the OpenHands codebase. The escape hatch is the

LITELLM_DEFAULT_MODEL

env var, which bypasses the version map. Question 2: Who implemented it? Vasco Schiavo (@VascoSch92), who authored and merged PR #14508 on May 21, 2026, described as a co-promotion with MiniMax for a model profiles launch.