[aldoeliacim]

Summary

• claude-haiku-5-5 is adaptive-thinking-only. The Haiku guard matched the /haiku/ family name and rewrote thinking.type: "adaptive" to "enabled" for every Haiku model. Anthropic then returned HTTP 400 (thinking.type.enabled is not supported ... use thinking.type.adaptive and output_config.effort).
• Fix: add a claude-haiku-5-5 model spec (adaptiveThinkingOnly, 1M context, 128K max output, from the gateway catalog). The Haiku guard now defers to the spec, so adaptive-only models are never rejected by the family regex. Haiku 4.5 and earlier keep the manual-thinking contract.
• User-facing: claude-haiku-5-5 requests with adaptive thinking now succeed instead of returning 400.

Related Issues

• Related to fix(providers): zed-hosted claude-haiku-4-5 thinking inflates max_tokens to 163072 #13364 (closed; zed-hosted haiku-4-5 thinking)
• Related to fix(providers): Antigravity: Claude 5.5 effort-suffixed ids are stripped before dispatch → 404 (daily) / 429 RESOURCE_EXHAUSTED (prod) #15691 (closed; Claude 5.5 fix)
• Related to bug(providers): correct supportsReasoning/long-context capability for claude-haiku-4-5-20251001 #10119 / fix: downgrade adaptive thinking and gate context-1m beta on model eligibility (#10119) #10481 (the original Haiku downgrade)

Validation

• Change type: provider / routing
• Focused tests and category gates from the golden path
• npm run lint (exit 0, full repo)
• Reconciled with the current active release base (release/v3.8.52); focused checks rerun afterward
• Production-code changes include a new or updated automated test in this PR
• Changelog fragment: changelog.d/fixes/15841-haiku-5-5-adaptive-thinking.md; check:changelog-integrity OK (no base bullets lost).

Live evidence (before the fix, through the gateway)

model	thinking.type	result
claude-haiku-5-5	adaptive	400 (enabled not supported)
claude-haiku-5-5	enabled	400
claude-sonnet-5	adaptive	200
claude-sonnet-5	enabled	200

Test results

• tests/unit/claude-haiku-no-adaptive-thinking.test.ts: 17/17 pass with the fix.
• Same file on the release tip without the fix: the new claude-haiku-5-5 pass-through test fails, so it guards the bug.
• Touched-area suites (translator / thinking / effort / sonnet / opus): 1202 pass. Two failures reproduce identically on release/v3.8.52 without this change: codex-effort-model-echo-3697 (1) and claude-web-sonnet5-registry-6209 (1, missing claude-sonnet-5-5 in its expected list).
• tsc --noEmit: 6040 errors on both the release tip and this branch, 0 added (diffed after path normalization). No type errors in the three touched source files.

Tests Added Or Updated

• tests/unit/claude-haiku-no-adaptive-thinking.test.ts (updated: new claude-haiku-5-5 adaptive pass-through and effort tests; Haiku 4.5 downgrade kept).

Coverage Notes

• Changed open-sse/services/claudeHaikuConstraints.ts and src/shared/constants/modelSpecs.ts. Both are covered by the updated test file above (adaptive pass-through, effort pass-through, and the Haiku 4.5 downgrade path).
• Coverage not measured locally; CI runs the 60% coverage gate on this PR.

Reviewer Notes

• Not fixed here, pre-existing on the release tip: tests/unit/openai-to-claude-strip-temperature-thinking.test.ts (1 of 10 fails on the base). Its Haiku-5 assertion uses claude-haiku-5-20251001; left unchanged to keep this PR focused.
• Haiku 5.5 is not in the claude-web registry list (claude-web-sonnet5-registry-6209 fails for the same underlying gap). Not changed here.
• No migrations, feature flags, or manual steps required.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[vinhch]

Confirming this bug independently. I hit the same 400 on claude-haiku-5-5:

"thinking.type.enabled" is not supported for this model. Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior.

Setup: Claude Code 2.1.294 (VS Code) → OmniRoute, with Thinking Budget set to passthrough.

• Claude Code sends thinking: {type: "adaptive"}. The same request succeeds when it bypasses OmniRoute.
• Through OmniRoute it fails. This matches normalizeClaudeHaikuConstraints rewriting adaptive to {type: "enabled", budget_tokens: 10000} because the model name matches /haiku/i, and also dropping output_config.effort.

The fix here (defer to adaptiveThinkingOnly in the model spec) looks right to me. Two suggestions, either here or as a follow-up:

1. The guard still defaults to rewriting any /haiku/i model that lacks a spec, so the next Haiku release would hit the same bug. Flipping it to an opt-in flag (e.g. manualThinkingOnly: true on Haiku 3.5/4.5) and passing unknown models through unchanged would make this future-proof.
2. The spec comment says "like Sonnet 5.5", but Haiku 5.5 behaves differently. Probing it directly, it accepts thinking: {type: "disabled"} and forced tool_choice: {type: "any"}, and rejects between_tools. Worth correcting so nobody copies the Sonnet 5.5 flags over.

This currently blocks every Claude Code user routing Haiku 5.5 through OmniRoute, since Claude Code always sends adaptive thinking for it. I'd really appreciate a review, merge, and release when you have a moment. Thanks for the work on this!

[diegosouzapw]

Thanks @aldoeliacim — claude-haiku-5-5 keeps thinking.type: adaptive. Haiku 4.5 still takes the older downgrade. This is in the upcoming release.