{"version":"2.1.287","anchor":"bridge-apply-flag-settings-skips-effortlevel-when-it-already","canonical_anchor":"effort-level-settings-ignored-when-a-helper-says-so","heading":"effortLevel updates are skipped when already satisfied","tier":"notice","area":"SDK","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.287\/e\/bridge-apply-flag-settings-skips-effortlevel-when-it-already","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.287","markdown":"### effortLevel updates are skipped when already satisfied\n\nSettings and control updates carrying effortLevel are now ignored when a check finds the model and engine state already satisfy them\n\n**Unclear.** It is not clear exactly what counts as already in effect, or what the reset does when no ultracode value is sent.\n\n**What**\n\n`effortLevel` sets how much effort the model puts into its answers. Claude Code used to apply it every time it arrived. Now:\n\n- Skipped when satisfied: a settings or control update that carries `effortLevel` is applied only if a new check on the model, the level and the engine state says it is not already satisfied. Otherwise it is ignored entirely, including the report of the change.\n\n- `apply_flag_settings`: the same skip applies when a controlling program, for example over Remote Control, changes session settings this way. Before, any `effortLevel` was always validated and applied.\n\n- `ultracode`: an effort change that arrives without an explicit `ultracode` value now calls a new reset step.\n\n**Why**\n\nThis avoids applying the same effort level twice, for example from Remote Control. It also means some effort changes may be dropped silently, so a setting that seems to have no effect may have been judged already in place.\n\n- Area: SDK\n- Names: `apply_flag_settings`, `effortLevel`\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 3\/5"}