Support `max` effort tier for Anthropic models (Opus 4.6+/4.8, Sonnet 4.6) — effort scale currently caps at xhigh

[hahnpierre]

Description

OMP's internal reasoning/effort scale tops out at xhigh — the levels are off | minimal | low | medium | high | xhigh (the :thinkingLevel suffix and defaultThinkingLevel enum both stop at xhigh). There is no max tier.

Anthropic, however, now exposes a dedicated output_config.effort parameter whose highest value is max, available on Opus 4.6 / 4.7 / 4.8, Sonnet 4.6, Fable 5, Mythos 5 (per the API docs; not Opus 4.5). This effort knob is separate from thinking.budget_tokens — the two combine, controlling different dimensions.

Per the provider-endpoint docs, for the anthropic-messages format OMP maps reasoning only to "Anthropic thinking enablement and thinking-budget tokens, not OpenAI-style fields." So today there is:

1. no max level anywhere in the internal effort scale, and
2. no code path that emits Anthropic's output_config.effort at all.

Net effect: a user on Claude Code can run claude --model claude-opus-4-8 --effort max, but from OMP there is no way to request the model's highest effort. The closest knob (xhigh + raising thinkingBudgets.xhigh) only scales the thinking-budget dimension — it is not the same as Anthropic's effort: max.

Refs (Anthropic): output_config.effort levels and per-model availability — https://platform.claude.com/docs/en/build-with-claude/effort

Use Case

I run Opus 4.8 (and other max-capable Anthropic models) from OMP and want the model's highest reasoning effort — parity with Claude Code's --effort max / CLAUDE_CODE_EFFORT_LEVEL=max.

Right now the only available ceiling is xhigh. Increasing thinkingBudgets.xhigh raises the thinking-token budget but does not set output_config.effort, so OMP cannot reach the effort level these models actually support. This blocks getting maximum quality out of newer Anthropic models from within OMP.

Area

Provider / Model support

Proposed Solution

1. Add a max effort tier above xhigh in the internal effort scale, gated by per-model capability metadata so it only surfaces for models that advertise it (Opus 4.6/4.7/4.8, Sonnet 4.6, Fable 5, Mythos 5, …). Models without max keep xhigh as their ceiling.
2. Wire anthropic-messages to output_config.effort. When the selected level is max (and the model supports it), emit output_config: { effort: "max" } alongside the existing thinking budget, instead of only translating reasoning into budget tokens. Ideally expose the effort dimension and the thinking-budget dimension independently.
3. Extend reasoningEffortMap so effort-string providers benefit from a real max tier (e.g. DeepSeek already maps xhigh -> "max"); this also addresses the conflation in deepseek-v4-pro no max effort option #2727 where a provider's true max effort is unreachable.
4. Surface it in the UI/flags: model browser, the requested /effort command (/effort command #2694), --effort/--thinking, and a :max thinking suffix — all guarded by capability detection so it is hidden for models that reject it.
5. Capability detection via model metadata / modelOverrides so unsupported models (e.g. Opus 4.5) don't get an invalid effort: "max" and 400.

Alternatives Considered

• models.yml modelOverrides[].compat.extraBody to manually inject output_config: { effort: max }. It's unclear/unverified whether extraBody is merged into the anthropic-messages request body (the documented extraBody examples are OpenAI-style payloads). Even if it works, it's a per-user manual hack, has no capability gating, and never appears in the model browser or /effort.
• Raising thinkingBudgets.xhigh — only scales the thinking-budget dimension, not Anthropic's effort knob; not equivalent to effort: max.

Related issues

• /effort command #2694 — /effort command (UX surface this tier should plug into)
• deepseek-v4-pro no max effort option #2727 — provider max effort option missing
• reasoning effort map is not working properly #931 — reasoningEffortMap not working properly (closed)
• the thinking effort - xhigh is lost after 14.7.5 #969 — xhigh effort lost after 14.7.5 (closed)
• Normalize GLM-5.2 max reasoning effort and review Z.AI params #2833 — normalize GLM-5.2 max reasoning effort (closed)

[roboomp]

This is feasible, but it is broader than a one-provider constant add.

Current code confirms the shape you described:

• packages/catalog/src/effort.ts defines the ordered internal scale as minimal | low | medium | high | xhigh, with no max.
• packages/catalog/src/model-thinking.ts clamps requested efforts against THINKING_EFFORTS, so adding max needs ordered-scale and per-model capability changes, not just CLI parsing.
• packages/ai/src/providers/anthropic-messages-server-schema.ts already tolerates output_config.effort, including max.
• packages/ai/src/providers/anthropic-messages-server.ts currently reads output_config.task_budget only; it does not translate output_config.effort into downstream provider options.

The safe implementation path is to model this as provider/model capability metadata first, then expose max only where getSupportedEfforts(model) includes it. That avoids sending max to Opus 4.5 or other models that would reject it. The main design decision is whether OMP should extend the existing single Effort axis to include max, or introduce a separate Anthropic-style output-effort dimension because Anthropic combines output_config.effort with thinking.budget_tokens rather than replacing it.

Open maintainer decisions before implementation:

1. Should max be a global Effort.Max tier above xhigh, or only a provider-specific mapped value exposed through capability metadata?
2. Should Anthropic output_config.effort be driven by the same --effort / :thinkingLevel knob, or should OMP expose a second independent knob for output effort vs thinking budget?
3. Which metadata source should be authoritative for per-model max support: generated catalog fixups, provider descriptors, user modelOverrides, or a combination?

I’ve labeled this as an enhancement/provider-Anthropic request rather than a bug because it asks OMP to support a newer provider capability and new UX/API surface, not to fix a crashing or regressed existing path.