{"version":"2.1.280","anchor":"tether-decision-telemetry-gains-dropheldstateless-field","canonical_anchor":"tether-decision-telemetry-gains-dropheldstateless-field","heading":"Server-side conversation threads gain a 'drop and recreate' path","tier":"internal","area":"Telemetry","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280\/e\/tether-decision-telemetry-gains-dropheldstateless-field","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280","markdown":"### Server-side conversation threads gain a 'drop and recreate' path\n\nClaude Code can now drop a stateless server-side conversation thread and recreate it, with new telemetry tracking when this happens\n\n**What**\n\n- The internal planner that decides whether to continue an existing server-side conversation thread or start a new one gained a new input, `dropHeldStateless`, and a new reason code, `thread_minted_drop`, for when a thread is dropped and a new one is created in its place.\n\n- New outcome telemetry fields (`dropArmed`, `dropHeldStateless`, `continuesSinceDropCreate`, `dropReportUnmatched`) were added to the `tengu_tether_live_outcome` event, and a new `tether_drop_recreate` counter fires whenever this drop-triggered recreation happens.\n\n- The `tengu_tether_decision` analytics event also now reports the `dropHeldStateless` field alongside the existing `modelHeldStateless`\/`relayHeldStateless`\/`classifierHeldStateless` fields.\n\n**Why**\n\nThis gives Claude Code (and Anthropic's internal monitoring) a documented way to recover when a stateless server-side thread needs to be dropped and replaced, with telemetry to track how often and how it happens.\n\n- Area: Telemetry\n- Tier: Under the hood\n- Useful: 3\/5\n- Signal: 3\/5"}