fix(server): Claude effort picker marks levels capped by maxEffortLevel#23629

Problem

When Claude Code's settings.json sets "maxEffortLevel": "xhigh", Claude Code clamps every higher effort down to it. The composer still offered and showed Max, so a turn labelled Max actually ran at xhigh. Repro on main: Claude Code 2.1.303 with that setting, pick Claude Haiku 5.5 → Max and send. The composer keeps showing Max, and a local API recorder sees output_config.effort: "xhigh". The same happens for every bundled Claude model that offers Max.

Change

• The Claude status probe reads effort caps from the CLI's getSettings() sources; older responses without sources fall back to the merged effective settings. It runs concurrently with the existing usage read, under the same timeout. A CLI that rejects or lacks the request means no cap. Workspace probes, which only keep slash commands, skip both reads.
• capClaudeCatalogEffort relabels every built-in effort option that would run above the cap, e.g. Max (capped to Extra High). Option ids, defaults and order are unchanged, so stored selections keep resolving and still send what they sent before.
• The cap shown is the highest level the model actually offers at or below the configured cap. Opus 4.6/4.5 have no Extra High, so their Max reads Max (capped to High), which matches the high the CLI sends. Options the model's effort map already sends below the cap stay unmarked, e.g. Sonnet 4.6's Max is sent as high.
• Within each settings source, matching modelSettings entries replace that source's global cap, and max exempts the model from that source. The lowest cap across sources wins. Family aliases and canonical IDs, including dated and [1m] spellings, follow the CLI’s matching rules; dotted spellings are ignored. Custom models keep their user-authored labels.
• A project-level .claude/settings.json cap is not reflected, because the provider probe runs outside any project. The probe uses the settings sources returned by the CLI for its environment; organisation-server caps are not included. Actual managed-file cap propagation was not independently verified.

Scope and approval

Fixes #17110

Triaged bug via the automated issue flow.

Verification

• Per-model regression test: before the fix, the fake-CLI integration returned Max (capped to Extra High) for an exempt model instead of Max; after the fix it passes. The same test covers a lower per-model cap and fallback to the global cap.

• Real Claude Code 2.1.303 settings probe: with global xhigh and modelSettings.claude-opus-5-5.maxEffortLevel: max, get_settings returns both settings; applied.effort is max for Opus 5.5 and xhigh for Sonnet 5.5. The probe sent no turn.

• vp test run apps/server/src/provider/ProviderRegistry.test.ts apps/server/src/provider/ClaudeModelCatalog.test.ts apps/server/src/provider/ClaudeCapabilitiesProbe.test.ts apps/server/src/provider/ProviderInstanceRegistry.test.ts: 4 files, 59 tests passed after merging main at 4dd9581. Focused test output. Scoped lint and server-only vpr typecheck also passed.

• Final real-CLI cross-check: 15/15 cases match, covering family aliases, dated and Bedrock IDs, ignored dotted keys, per-model exemptions, collision minima and restrictive caps across user/project/flag sources. Sanitized CLI transcript and malformed-input benchmark. The added dated-key and cross-source tests failed before their fixes. No new regex is used.

• The status-level test (marks effort above the CLI's maxEffortLevel cap as capped) fails on main with claude-opus-5-5: expected 'Max' to include 'capped to Extra High'.

• A fake-CLI test reads the cap through a real get_settings control request. A second fake-CLI test rejects get_settings and asserts that usage and account still come through, uncapped.

• Server typecheck shows 0 errors; lint is clean on the changed files.

• CLI behaviour checked with Claude Code 2.1.303 against a local API recorder, cap xhigh:

  • Haiku 5.5 sends xhigh for both max and xhigh.
  • Opus 4.6 and Opus 4.5 send high for max, xhigh and high.
  • Opus 4.6 without the cap sends max for max.

• Final head b28bfbb: all 31 checks pass, CodeRabbit has no remaining actionable findings, and thread-transfer sizes remain within every enforced ceiling. The final two commits only format the synthetic JSON and correct its exemption expectation to Max; generation and formatting were checked. Macroscope requires human approval for the runtime settings integration and resolution scope.

Evidence

Real web app (vp run dev) for both builds: before = merge-base 8d3b061121, after = f347cf5c3c.

What else changed, beyond the label:

• At 390 px wide, the longer label makes the composer bar fold blocks to icon-only earlier, which is its existing width-based behaviour (composerFooterLayout.ts).
• With a capped label, the runtime-mode chip folds to an icon.
• With Max + Fast (R5), the effort chip folds to an icon as well, so the effort label is then only visible in the opened menu.
• At 1440 the wider chip shifts the controls to its right.

Environment (every capture): headless Chromium 1223 via Playwright 1.60.0 on Linux x86_64 (fs-15), no device emulation, deviceScaleFactor 1, no font scaling, locale en-US, timezone UTC, clock frozen with page.clock.setFixedTime(2026-10-22T13:00:00Z), prefers-color-scheme emulated per row, viewports 1440×900 and 390×844, whole viewport captured, pointer parked at (0,0). Both sides: vp run dev web dev server against an isolated worktree .t3 restored from one migrate-dev-db snapshot, thread "Issue 14464 triage" (pingdotgg/t3code), thread details panel closed. CLAUDE_CONFIG_DIR set on the dev server to a temp dir whose settings.json = env from ~/.claude/settings.json (+ maxEffortLevel).

Captures are at 1440 and 390 wide; the matrix's 1280 width was widened to the 1440 standard. Diff0 = compare -fuzz 0 (any pixel that differs by ≥1 level painted solid red over a faded copy, so a one-level change is visible). DiffT = compare -fuzz 10%. AE = differing pixel count.

R1: Web traits menu + chip, F0 (no cap), Opus 5.5 Max — control

Expected/observed: Unchanged: Max both sides.

R2: Web traits menu + chip, F1 cap xhigh, Opus 5.5 Max, Fast off

Expected/observed: After: chip and checked item read "Max (capped to Extra High)". Extra High, Ultracode, Ultrathink unmarked.

R3: Web traits menu, F3 cap xhigh, Sonnet 4.6 Max (negative)

Expected/observed: Unchanged: chip "Max · 200k", menu "Max".

R4: Web traits menu, F4 cap high, Opus 5.5 Extra High

Expected/observed: After: "Extra High (capped to High)", "Max (capped to High)", "Ultracode (capped to High)"; Ultrathink unmarked.

R5: Web composer bar, F2 cap xhigh, Opus 5.5 Max + Fast on

Expected/observed: After 1440: chip "Max (capped to Extra High) Fast". After 390: effort chip and access chip fold to icon-only (label kept as hidden text); before 390 shows "Max Fast" and "Full access".

R6: Settings → Project (pingdotgg/t3code) → New threads → Model, F1 cap xhigh, Opus 5.5 Max

Expected/observed: After: chip and menu "Max (capped to Extra High)".

R9: Web traits menu, cap xhigh, Opus 4.6 Max (1M default)

Expected/observed: After: chip "Max (capped to High) · 1M", menu "Max (capped to High)".

Extra crop (in addition to whole-surface captures)

390 composer bars, menu open, before over after, rows R2, R4, R5, R9: 390 composer bars before/after

What else changed (every visible difference, from Diff0)

1. Intended: effort labels above the cap gain "(capped to …)" in the chip, the menu item and the menu's accessible name (R2, R4, R5, R6, R9). Ids, defaults ("Default" badge), order and checked state are unchanged.
2. Layout, 1440: the wider chip pushes everything to its right ("Full access" chip, model-strip separators) rightward (R2, R4, R5, R9). In Settings (R6), the chip is right-aligned, so the model picker shifts left. The open menu is anchored to the wider chip, so it moves and repaints the "Current checkout"/"Import scripts" controls it covers differently.
3. Layout, 390, unintended side effect: with any capped label, the runtime-mode chip collapses from "Full access" to a lock icon (R2, R4, R9). With Max + Fast (R5), the effort chip itself also collapses to an icon, so the effort label leaves the bar at 390 (before showed "Max Fast"). The label survives only as hidden text and in the opened menu. This fold is the resting-controls overflow collapse ("icon-only" blocks), not the CompactComposerControlsMenu overflow menu.
4. Menu geometry at 390: R2, R4 and R5 retain the existing menu width and position. R9 widens toward the right while its left edge remains fixed. In Project Settings (R6), the effort chip wraps onto a second line, increasing the Model section height, moving Workspace/Actions downward and repositioning the menu.
5. R6 only, not caused by the change: the second Checkouts row shows each server's own cwd (/tmp/i17110/before/apps/server vs /home/ubuntu/wt/issue-17110/apps/server).
6. Rendering noise of 1–2 levels out of 255, below the 10% threshold: the textured send button and the composer's right/bottom border on rows where the bar re-laid out (R2, R4, R5, R9 at 1440), and 2 pixels at the composer's bottom-left corner in R3-1440 (srgb 20↔21, 16↔17). Nothing else differs. R1 (both widths) and R3-390 are identical at zero threshold (AE 0). Where the wider menu sits over the blurred backdrop, the backdrop repaints at low amplitude (e.g. R9-390: 37,893 px at fuzz 0, 1,998 px at 10%).

Additional UI attempt: The recovery browser confirmed the global-cap Haiku chip/menu at 82ca801681. The later per-model exemption recheck hit a 25-second provider-status timeout on an overloaded four-core host (load around 30), so no fresh exemption capture is claimed. The per-model branch is verified by the failing-then-passing integration test and real CLI probe above.

Fresh synthetic fixture: Committed seed and scenario data generate an empty stopped Claude thread, project defaults and isolated cap settings without reading personal rows or credentials. Deterministic generation, repeated scratch-SQL application and integrity checks passed. This enables new captures; it does not reconstruct the historical screenshots. A fresh before attempt on current main reached the seeded Haiku/Max view, then repeated provider failures and event-loop stalls up to eight minutes prevented a matching after set. Redacted attempt log.

Reconstruction limitation: All 11 required historical static pairs were independently inspected and their zero/10% fuzz pixel counts recomputed successfully. The exact historical state seed was not committed, so a fresh whole-screen pixel reconstruction from the PR alone remains unverified. Recovered evidence index.

Unverified:

• Settings scope: Family aliases use the bundled catalog’s default, which can differ from Claude’s default on other backends or versions. best, opusplan, user modelOverrides, organisation-server caps and project-specific probes are outside this implementation. User/project/flag source semantics were runtime-tested; actual managed-file propagation was not. Unusual keys containing multiple model families and catalog models newer than the installed CLI were not covered.
• iOS (matrix R7): Device access was disabled in the original environment. EAS Simulator access was checked successfully during recovery, but available static fixtures require a paired backend and provide Codex data; none of the inspected finished simulator builds established a source match for this Claude-descriptor state. No native coverage is claimed. The mobile code is unchanged and renders the same server-provided label through shared client-runtime helpers. The phone chip renders one line (numberOfLines={1}), so whether the (capped to …) suffix gets cut off on narrow phones is unchecked.
• Windows desktop: Electron/Windows rendering and the Windows-specific provider probe were not run.
• Optional R8: the Claude native-subagent strip needs a live subagent thread, which the seeded data does not have.

🤖 Generated with Claude Opus 5.5 and GPT-6.1-Sol through Claude Code and Codex in the T3 Code issue-triage flow

Fixes pingdotgg/t3code#17110