Claude Code v2.1.156 fixes the third-party provider breakage
Anthropic shipped v2.1.156, which fixes the HTTP 422 error that broke every non-Anthropic API provider in v2.1.154 and v2.1.155. Here is what changed and what claude-multi users need to do.
Claude Code v2.1.156 fixes the third-party provider breakage
Claude Code v2.1.156 fixes the third-party provider breakage
Yesterday I wrote about how Claude Code v2.1.154 broke every third-party API provider. The bug was in the fallback logic: Claude Code’s retry handler only caught HTTP 400, but providers return HTTP 422 for validation errors. The beta feature that sends role: "system" in the messages array would fail, the fallback would not trigger, and your conversation died.
Anthropic shipped v2.1.156 a few hours ago. It fixes this.
What changed in v2.1.156
The fallback detection now catches both HTTP 400 and 422. When a provider rejects the mid-conversation-system beta with either status code, Claude Code removes the beta header and falls back to putting system instructions in <system-reminder> blocks inside user messages. This is the same fallback that already worked for first-party API calls that happened to return 400.
Versions 2.1.154 and 2.1.155 still have the bug. Upgrade to 2.1.156 or later.
What claude-multi users need to do
If you are on claude-multi v0.6.0 or later:
claude-multi doctor fixThis reinstalls the pinned Claude binary at ~/.claude-multi/bin/ to v2.1.156 and updates any wrapper scripts that still point to the old version.
If you are on an older version of claude-multi, update first:
bun update -g claude-multiclaude-multi doctor fixAuto-updates are back on
When the breakage hit, we disabled auto-updates in claude-multi to prevent Claude Code from silently updating to a broken version. Now that v2.1.156 fixes the issue, auto-updates are re-enabled. New instances created with provider templates will not have DISABLE_AUTOUPDATER=1 or DISABLE_UPDATES=1 injected into their settings.
If you have existing instances with those env vars in their settings.json, you can remove them manually or re-apply the provider template. They are harmless to leave in place; they just prevent Claude Code from auto-updating.
The safety infrastructure stays
We are keeping the version pinning and health check code in place, labeled with [SAFE PARK] comments throughout the codebase. If a future Claude Code update breaks third-party providers again, we can reactivate it by flipping a few constants:
isThirdPartyApiBroken()insrc/version.tsgets an updated version rangeCOMPATIBLE_CLAUDE_VERSIONgets the last working version numberPROVIDER_COMMON_ENVinsrc/templates.tsgetsDISABLE_AUTOUPDATERandDISABLE_UPDATESbackautoUpdatesinsrc/config.tsflips back tofalse
The doctor fix command and the TUI health screen will pick up the changes automatically. No new code needed.
This is the second time in recent months that a Claude Code update has broken provider compatibility. Keeping the safety code parked and ready seems prudent.
TL;DR
- v2.1.156 fixes the HTTP 422 bug that broke third-party providers in v2.1.154 and v2.1.155
- Run
claude-multi doctor fixto update your pinned binary - Auto-updates are re-enabled for new instances
- The pinning safety code stays parked, ready to reactivate if it happens again