{"version":"2.1.275","anchor":"new-retry-path-drop-message-threads-header-on-unrecognised","canonical_anchor":"new-retry-path-drop-message-threads-header-on-unrecognised","heading":"New retry path drops the message-threads header on unrecognised HTTP 400 errors","tier":"notice","area":"Elsewhere","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.275\/e\/new-retry-path-drop-message-threads-header-on-unrecognised","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.275","markdown":"### New retry path drops the message-threads header on unrecognised HTTP 400 errors\n\nAn unrecognised HTTP 400 on a message-threads request now triggers a stateless retry without that header, tracked by a new telemetry event\n\n**What** When a request carrying the message-threads header gets back an HTTP 400 error that is not one of the known thread-related error codes, Claude Code now resends the turn statelessly, without the message-threads header, and marks that thread type as dropped for the rest of the session. This path is tracked by a new telemetry event, `tengu_tether_unrecognised_400`, added alongside the existing `tengu_tether_decision`, `tengu_tether_live_outcome`, and `tengu_tether_echo_audit` events.\n\n**Why** This lets a conversation keep going after an unexpected 400 error tied to the message-threads feature, instead of failing outright, while still recording that the fallback happened.\n\n- Area: Elsewhere\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5"}