Conversation
The SDK exposes ultracode as its own boolean setting, separate from
effortLevel:
effortLevel?: 'low' | 'medium' | 'high' | 'xhigh';
ultracode?: boolean;
so it is not a sixth effort level — buildConfigOptions validates the
effort option against the model's supportedEffortLevels and would fall
back to "default" for it. Add a dedicated `ultracode` config option
instead, mirroring Fast mode: a native boolean toggle for clients that
advertise session.configOptions.boolean, degrading to an on/off select
otherwise, applied with applyFlagSettings({ ultracode }).
The option is only surfaced when the current model advertises the xhigh
effort level ultracode runs at, and follows the model across switches the
way Fast mode does — it disappears on a model that can't run xhigh and
reappears with the retained intent. The initial value is seeded from the
settings the session was created with, since the SDK reports no ultracode
state on init and the flag is session-scoped.
Refs agentclientprotocol#725. Covers only the toggle; the workflow lifecycle events and
approval flow in that issue are untouched.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a dedicated
ultracodesession config option so ACP clients can enableultracode (xhigh effort plus standing dynamic-workflow orchestration).
The SDK exposes it as its own boolean, separate from
effortLevel:Not added as a sixth
effortvalue (as #725 suggests) becausebuildConfigOptionsvalidates against the model'ssupportedEffortLevelsandwould fall back to
default, silently dropping it.Approach
Mirrors the existing Fast mode option: a
type: "boolean"toggle for clientsadvertising
session.configOptions.boolean, degrading to anon/offselectotherwise, applied via
applyFlagSettings({ ultracode }). The flag is pushedbefore session state is updated, so a rejected control request leaves both
untouched.
Only surfaced when the current model advertises the
xhighlevel ultracode runsat, and follows the model across switches the way Fast mode does. Seeded from the
settings the session was created with, since the SDK reports no ultracode state on
init and the flag is session-scoped.
Testing
npm run build,lint,format:checkclean;test:run698 passed with 14 newtests. Verified over real ACP stdio: the option appears, toggles, and the
session's reported ultracode state follows it.
Scope
Refs #725 — the toggle only. The workflow lifecycle events and approval flow in
that issue look like they need protocol surface rather than adapter work.