{"version":"2.1.284","anchor":"ultracode-becomes-an-onoff-row-in-the-effort-picker-instea","canonical_anchor":"ultracode-becomes-an-onoff-row-in-the-effort-picker-instea","heading":"Ultracode becomes an on\/off toggle that works at any effort level","tier":"use","area":"Effort","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.284\/e\/ultracode-becomes-an-onoff-row-in-the-effort-picker-instea","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.284","markdown":"### Ultracode becomes an on\/off toggle that works at any effort level\n\nUltracode is no longer an effort level: it is a session toggle in \/effort, with new SDK fields and a narrower subagent-cap exemption\n\n**Unclear.** It is not settled whether the ultracode row is hidden on plans where workflows are off by default.\n\n**What**\n\nUltracode, which runs dynamic workflows (Claude orchestrating extra work) on every task, used to be one of the effort levels, shown as \"xhigh + workflows\". It is now a separate on\/off switch for the session that you combine with any effort level.\n\n- The `\/effort` picker has a separate row reading `Ultracode: on` or `off` with \"select to turn it\" on or off and \"dynamic workflows on every task\". Selecting it sends `ultracode on` or `ultracode off`.\n\n- The row only appears when workflows are available and the model supports xhigh effort. Workflow availability comes from the `tengu_workflows_enabled` gate unless `CLAUDE_CODE_WORKFLOWS` or the `disableWorkflows` \/ `enableWorkflows` settings override it.\n\n- `\/effort` usage now reads `auto|ultracode [on|off]`, with a section headed \"Ultracode (any effort level, this session only):\".\n\n- Cycling effort levels left and right no longer includes ultracode, and a current ultracode value is no longer mapped to max or high.\n\n- A new session-only `ultracode` setting is described as \"standing dynamic-workflow orchestration at any effort level\".\n\n- The status label shows the real effort level and adds \" \u00b7 ultracode\" when it is on.\n\n- The per-model `supportsUltra` field was dropped.\n\n- SDK session state and `get_settings` report `ultracodeRequested` and `ultracodeAvailable` next to `ultracode` (`applied.ultracode`). `ultracodeAvailable` is true when dynamic workflows are enabled and the model supports it; hosts should only offer an Ultracode control while it is true. The `ultracode` description no longer says it implies xhigh effort.\n\n- The check that the live model's effort still matches the recorded level no longer passes the ultracode setting.\n\n- Skipping the limit on concurrent subagents (helper agents Claude starts) now only happens when ultracode is on and the model supports it, rather than depending on the effort level. The separate `tengu_amber_kestrel` bypass is unchanged. The limit itself is still set with `CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS`.\n\n**Why**\n\nIf you used ultracode before, it now behaves differently: you pick your effort level and turn ultracode on or off on top of it. Sessions at a high effort level without ultracode may now hit the subagent limit where they did not before, and SDK hosts can tell \"requested but unavailable\" apart from \"on\".\n\n- Flag `tengu_workflows_enabled`: On for this account, and not off by default (read for one account on one subscription tier against v2.1.284; this account: on, anonymous baseline: on, compiled default: on) These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.\n- Flag `tengu_amber_kestrel`: Not enough to say (read for one account on one subscription tier against v2.1.284; this account: no value returned, anonymous baseline: no value returned, compiled default: off) These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.\n- Area: Effort\n- Tier: Use it now\n- Useful: 4\/5\n- Signal: 2\/5"}