Umans GLM-5.2 lost the `max` reasoning tier (picker shows only off/inherit/high/auto)

[oldschoola]

Summary

After updating omp and restarting, umans-glm-5.2 (Umans AI Coding Plan, direct integration) only exposes four reasoning selectors in the thinking-level picker: off, inherit, high, auto. The top max tier that GLM-5.2 actually supports is missing, and the lower tiers (minimal/low/medium) have disappeared too. Before the update the full ladder was selectable.

This is an omp-side catalog/discovery gap: the Umans level table at packages/catalog/src/provider-models/openai-compat.ts does not map the max level that Umans now reports, and the Umans anthropic-messages/budget path carries no effortMap to route Effort.XHigh onto the upstream "max" wire value.

Observed behavior

Thinking-level picker for umans-glm-5.2:

• Before update: full reasoning ladder (minimal, low, medium, high, xhigh/max) selectable.
• After update + restart: only off, inherit, high, auto.

The four values shown correspond exactly to what getSupportedEfforts() returns for this model plus the always-present selectors:

• inherit and off — always present (THINKING_LEVEL_METADATA in packages/coding-agent/src/thinking.ts).
• auto — the AUTO_THINKING selector layered on top.
• high — the only surviving model-supported effort.

So the model's supported effort list has collapsed to a single entry: ["high"].

Root cause

Umans is dynamicModelsAuthoritative: true (packages/catalog/src/provider-models/descriptors.ts ~L319–L324), so at runtime the reasoning levels come from the live https://api.code.umans.ai/v1/models/info response, filtered through mapUmansReasoningEfforts in packages/catalog/src/provider-models/openai-compat.ts (~L597) — not the bundled umans-glm-5.2 catalog entry.

The live response for umans-glm-5.2 (fetched unauthenticated, 2026-06-21):

"umans-glm-5.2": {
  "capabilities": {
    "max_completion_tokens": 131072,
    "recommended_max_tokens": 131071,
    "context_window": 405504,
    "supports_vision": "via-handoff",
    "supports_tools": true,
    "reasoning": {
      "supported": true,
      "can_disable": true,
      "levels": ["none", "high", "max"],
      "default_level": "high"
    }
  }
}

Per the z.ai docs (GLM-5.2 thinking modes), GLM-5.2 has 3 thinking modes: non-thinking, and thinking in two modes — High and Max ("Use Max Thinking for complicated tasks"). Umans surfaces this native none/high/max scale.

But the Umans level table at packages/catalog/src/provider-models/openai-compat.ts:563 only knows the pi internal effort scale — it has no max key:

const UMANS_REASONING_EFFORT_BY_LEVEL: Record<string, Effort> = {
	minimal: Effort.Minimal,
	low: Effort.Low,
	medium: Effort.Medium,
	high: Effort.High,
	xhigh: Effort.XHigh,
};

mapUmansReasoningEfforts (~L597) iterates levels and looks each one up in that table:

for (const level of value.levels) {
	if (typeof level !== "string") continue;
	const effort = UMANS_REASONING_EFFORT_BY_LEVEL[level];
	if (effort !== undefined && !efforts.includes(effort)) {
		efforts.push(effort);
	}
}

For levels: ["none", "high", "max"]:

• "none" → undefined → skipped
• "high" → Effort.High → included
• "max" → undefined → silently dropped

Result: efforts = ["high"] only. That single effort is what getSupportedEfforts() returns (packages/catalog/src/model-thinking.ts:620) and what the thinking-level picker renders — matching the off/inherit/high/auto regression exactly.

A second, related gap: even once max is mapped to Effort.XHigh, the Umans anthropic-messages/budget path has no effortMap baked onto the model to route Effort.XHigh back to the upstream "max" wire value. mapEffortToAnthropicAdaptiveEffort (packages/catalog/src/model-thinking.ts:696) falls back to the identity (xhigh) when no effortMap entry exists, and Umans would reject xhigh — the same problem the z.ai path already solved with ZAI_GLM_52_REASONING_EFFORT_MAP (model-thinking.ts:83, applied at model-thinking.ts:374).

Expected fix

Two coordinated changes in the Umans discovery path (packages/catalog/src/provider-models/openai-compat.ts) plus a regression test against the resolver:

1. Map the upstream max level to Effort.XHigh in UMANS_REASONING_EFFORT_BY_LEVEL (and decide how "none" should surface — likely dropped, since off/inherit already cover "no reasoning"). After this, levels: ["none","high","max"] resolves to ["high", "xhigh"] and the picker shows high + max again.
2. Bake an effortMap onto the Umans umans-glm-5.2 spec ({ [Effort.XHigh]: "max" }, mirroring GLM_52_XHIGH_MAX_EFFORT_MAP / ZAI_GLM_52_REASONING_EFFORT_MAP) so the request body sends "max" rather than the unsupported "xhigh". mapUmansModelInfo (~L630) currently builds the thinking config without an effortMap; that's where it should be attached when the upstream reports a max level.

The bundled umans-glm-5.2 catalog entry (packages/catalog/src/models.json:69312) is now stale relative to the live API — it lists efforts: ["minimal","low","medium","high","xhigh"] with no effortMap. Because Umans is dynamicModelsAuthoritative, the live response overrides it at runtime, but the bundled fallback should be regenerated to match (none/high/max scale, plus the xhigh→max effort map) so the offline/degraded-discovery path is consistent.

Context

• Context window: bundled and live both report context_window: 405504 (~406k) for the Umans SKU — this is the Umans-side cap, distinct from z.ai's native GLM-5.2 max of 1,048,576. Not a bug, just noting the source of the number.
• Related (closed): Normalize GLM-5.2 max reasoning effort and review Z.AI params #2833 normalized the z.ai GLM-5.2 max effort mapping. The Umans path was not covered by that fix — UMANS_REASONING_EFFORT_BY_LEVEL still predates GLM-5.2's max tier.
• Repo state: packages/catalog/src/provider-models/openai-compat.ts lines 563–628 (Umans mapping), packages/catalog/src/model-thinking.ts lines 83–92 and 373–378 (z.ai parallel to mirror).

Reproduction

Live API (unauthenticated, since Umans discovery is allowUnauthenticated: true):

curl -sS https://api.code.umans.ai/v1/models/info \
  | python3 -c "import sys,json;print(json.dumps(json.load(sys.stdin)['umans-glm-5.2']['capabilities']['reasoning'],indent=2))"

→ {"supported": true, "can_disable": true, "levels": ["none","high","max"], "default_level": "high"}

Then in omp with umans-glm-5.2 selected, open the thinking-level picker → only off/inherit/high/auto appear.

Environment

• omp: built from main at fc84601ea (2026-06-21).
• Provider: Umans AI Coding Plan (direct integration, api: anthropic-messages, baseUrl: https://api.code.umans.ai).
• Model: umans-glm-5.2.

[roboomp]

Looking into this; I’ll report back with a concrete repro before fixing the Umans reasoning mapping.

[roboomp]

Reproduced in packages/catalog: feeding Umans discovery levels: ["none","high","max"] through umansModelManagerOptions() currently yields {"mode":"budget","efforts":["high"],"defaultLevel":"high"}, so max is dropped before the picker sees the model.

[roboomp]

Fix is up in #3193: #3193