Sign up
View stargazersSign up

[Bug]: Composer shows Max effort while Claude Code caps it to xhigh via maxEffortLevel#17110

openedOct 8, 2026byNNeonsy

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

  1. In Claude Code's settings.json, set "maxEffortLevel": "xhigh"
  2. In T3 Code, pick Claude Haiku 5.5 and set Reasoning to Max
  3. Send any message

Expected behavior

The composer shows the effort that actually runs. Max is hidden, disabled, or marked as capped to Extra High, because Claude Code will not send anything above xhigh

Actual behavior

The composer offers and keeps showing Max, but Claude Code lowers it to xhigh before sending. Nothing tells the user

T3 starts the session with "effort":"max" and Claude Code receives --effort max. Claude Code's own maxEffortLevel setting then caps it. T3's model catalog does not read that setting, so the picker never knows about the cap

Impact

Minor bug or occasional failure

Version or commit

0.0.46-nightly.20261008.2801

Environment

Windows 11, T3 Code desktop (Nightly), Claude Code 2.1.293, Claude Haiku 5.5

Logs or stack traces

shell
1# Request bodies Claude Code sent, captured with a local fake API (ANTHROPIC_BASE_URL)
2# Setting: "maxEffortLevel": "xhigh"
3--effort max -> "output_config": {"effort": "xhigh"}
4--effort xhigh -> "output_config": {"effort": "xhigh"}
5--effort high -> "output_config": {"effort": "high"}

Screenshots, recordings, or supporting files

No response

Workaround

None needed for correctness, since the cap works. Just don't trust the label when maxEffortLevel is set

JJulius Marminge21d ago

Reproduced on main a12d6ed942, Linux web dev app, Claude Code 2.1.303, with isolated Claude settings containing "maxEffortLevel":"xhigh".

Selected Claude Haiku 5.5 → Max → sent “Reply with just OK. Do not use tools.” The turn returned OK and the composer retained Max. The provider transcript recorded query.open with "effort":"max".

A follow-up through the same real app, directed to a local API recorder, received:

json
1{"path":"/v1/messages?beta=true","model":"claude-haiku-5-5","output_config":{"effort":"xhigh"}}

The recorder deliberately returned HTTP 400 after capturing the request; the composer still displayed Max. A separate Claude CLI --effort max probe produced the same xhigh request. Windows desktop was not verified. No matching duplicate found among 950 open issues.

Successful real turn, Max retained: Haiku successful turn retains Max

Follow-up API capture, Max retained: Haiku API capture retains Max

Leaving open for maintainer scope review: the shared catalog also advertises MCP orchestration options and validates delegated-task selections. Making that catalog cap-aware changes the MCP tool surface, which is outside this automated triage flow's fix authorization. No implementation or PR created.

JJulius Marminge20d ago

Fresh reproduction on main a50cd989ae, Linux web dev app, Claude Code 2.1.303, isolated Claude settings with maxEffortLevel: "xhigh": selected Haiku 5.5 → Max and sent “Reply with just OK. Do not use tools.” The turn returned OK; the composer retained Max. A second real-app turn pointed at a local API recorder sent output_config.effort: "xhigh" while the composer still displayed Max. The recorder deliberately returned HTTP 400 after capture. No matching duplicate among 926 open issues. Windows desktop remains unverified.