Persist adapter-advertised Fast mode for managed agents
Claude and Codex ACP adapters expose Fast mode through session configuration, but Buzz does not currently provide a persisted per-agent control for it. The existing effort control supplies useful precedent for selecting the model first and applying an advertised option afterwards.
Would a small per-agent Fast mode control fit the intended configuration model?
I propose one persisted preference with three states: unset, on, and off. Unset leaves control to the adapter; Reset removes Buzz's preference. The agent editor would save or cancel this preference with the rest of the form. An authorized native write/reset surface and structured readback should expose the same behavior for automation.
The implementation would resolve the live option after model selection and preserve its exact ID, type, allowed values, and description. Claude uses fast and Codex uses fast-mode; both can advertise a boolean or a select fallback, depending on client capabilities. This requires typed option handling rather than assuming every value is a string.
The UI should distinguish saved intent from the state reported by the adapter. When an option disappears or a request is rejected, it should retain the intent and show the reason. It should not display Fast as applied based only on a saved switch or a successful transport response. We should agree on startup behavior when effective state cannot be confirmed, particularly for an explicit Off preference; silently continuing with an unknown or conflicting mode would defeat that request. A confirmed ordinary-speed fallback need not make the agent unusable.
For the first contribution, I would keep this to managed local Claude and Codex agents, with the UI behind a preview feature gate. Global defaults, definition inheritance, remote-session writes, and an editor for arbitrary model options can follow once their semantics are agreed. Usage attribution should report an accepted service tier only when there is runtime evidence for it.
There is existing Cursor work in #6188 for #6114, and the capability investigation in #4004. This proposal should coordinate with that model-variant path and avoid creating a second preference that competes with it. #4625 is the persisted-effort precedent. The Codex adapter's initialization issue is separately tracked in codex-acp #285 and #327.
Acceptance would cover save/cancel/reset, restart, boolean and select encodings, model changes, unavailable and rejected options, stale or missing readback, and the native automation surface. A retained preference should be re-evaluated against the new model's options rather than sent with the previous model's metadata.
Is a first-class Fast mode control backed by typed adapter metadata the preferred direction, or should this wait for a broader model-configuration surface?
Persist adapter-advertised Fast mode for managed agents
Claude and Codex ACP adapters expose Fast mode through session configuration, but Buzz does not currently provide a persisted per-agent control for it. The existing effort control supplies useful precedent for selecting the model first and applying an advertised option afterwards.
Would a small per-agent Fast mode control fit the intended configuration model?
I propose one persisted preference with three states: unset, on, and off. Unset leaves control to the adapter; Reset removes Buzz's preference. The agent editor would save or cancel this preference with the rest of the form. An authorized native write/reset surface and structured readback should expose the same behavior for automation.
The implementation would resolve the live option after model selection and preserve its exact ID, type, allowed values, and description. Claude uses
fastand Codex usesfast-mode; both can advertise a boolean or a select fallback, depending on client capabilities. This requires typed option handling rather than assuming every value is a string.The UI should distinguish saved intent from the state reported by the adapter. When an option disappears or a request is rejected, it should retain the intent and show the reason. It should not display Fast as applied based only on a saved switch or a successful transport response. We should agree on startup behavior when effective state cannot be confirmed, particularly for an explicit Off preference; silently continuing with an unknown or conflicting mode would defeat that request. A confirmed ordinary-speed fallback need not make the agent unusable.
For the first contribution, I would keep this to managed local Claude and Codex agents, with the UI behind a preview feature gate. Global defaults, definition inheritance, remote-session writes, and an editor for arbitrary model options can follow once their semantics are agreed. Usage attribution should report an accepted service tier only when there is runtime evidence for it.
There is existing Cursor work in #6188 for #6114, and the capability investigation in #4004. This proposal should coordinate with that model-variant path and avoid creating a second preference that competes with it. #4625 is the persisted-effort precedent. The Codex adapter's initialization issue is separately tracked in codex-acp #285 and #327.
Acceptance would cover save/cancel/reset, restart, boolean and select encodings, model changes, unavailable and rejected options, stale or missing readback, and the native automation surface. A retained preference should be re-evaluated against the new model's options rather than sent with the previous model's metadata.
Is a first-class Fast mode control backed by typed adapter metadata the preferred direction, or should this wait for a broader model-configuration surface?