{"version":"2.1.170","anchor":"model-refusal-fallback-sdk-protocol-event","canonical_anchor":"model-refusal-fallback-sdk-protocol-event","heading":"Model Refusal Fallback SDK Protocol Event","tier":null,"area":null,"scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.170\/e\/model-refusal-fallback-sdk-protocol-event","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.170","markdown":"### Model Refusal Fallback SDK Protocol Event\n\n**What**\n\nA new `model_refusal_fallback` system event is now emitted over the SDK protocol whenever the primary model returns a safety refusal and the session automatically retries on a fallback model.\n\n**Details**\n\n- Event fields: `trigger: \"refusal\"`, `direction: \"retry\" | \"revert\" | \"sticky\"`, `original_model`, `fallback_model`, `request_id`, `api_refusal_category` (e.g. `\"cyber\"`, `\"bio\"`), `api_refusal_explanation`, `retracted_message_uuids`\n- `retracted_message_uuids` lists the wire UUIDs of messages that were rolled back by the fallback \u2014 SDK consumers should evict these from transcript state on receipt\n- The `supersedes` field on incoming messages was also updated: it can now include tombstoned `tool_result` frames from the refused leg, not only assistant frames\n- `refusalFallbackLaneEnabled` and `refusalFallbackSettingToggleVisible` are now communicated from the daemon to the main process at startup rather than read directly from a feature flag, making these states available to SDK consumers via init\n\n**Evidence**\n\nNew schema definition (search for `\"model_refusal_fallback\"` and `\"retracted_message_uuids\"`)"}