Make the GPT-6 executor low-only and lead with computer use

assets/orchestrate/workflow.md

@@ -12,9 +12,10 @@ If Orchestrate tool schemas are deferred, discover and load them before starting
 delegated execution. Read the current fleet, compare enabled execution profiles
 across all providers, and select a task-fit model, endpoint profile, and per-call
 effort using the configured strengths and caveats. Provider family gives no
-preference. The bundled GPT-6 executor at low effort is the baseline; raise its
-effort only when a specific piece demonstrably needs more depth, or choose
-another profile when its description better fits the task.
+preference. The bundled GPT-6 executor is dispatched at low effort only: never
+pass it medium or above, since higher efforts cost more without better results.
+Route UI-driving and eyes-on-screen verification to it first. Choose another
+profile only when its description better fits the task.
 
 ## Route the work
 

crates/core/src/settings.rs

@@ -259,7 +259,8 @@ const LEGACY_FABLE_DECISION_DEFINITION: &str = "Decision collaboration: examine
 
 const OLD_DEFAULT_SOL_DEFINITION: &str = "Execution model for scoped implementation, debugging with a reproduction, migrations, code review, data analysis, and evidence gathering. Use medium for routine work with a clear brief; increase through high and xhigh as interacting constraints or reasoning difficulty grow; use max for the hardest well-defined problems or when a lower effort has demonstrably stalled. Choose any supported effort that fits the task, not just the endpoints. Keep unrelated improvements out of scope. Report the concrete result and relevant checks concisely.";
 const OLD_DEFAULT_OPUS_DEFINITION: &str = "Execution model for agentic coding, cross-file implementation, refactoring, debugging, and review. Consider it alongside Sol across providers, including user-facing behavior and API or UI details. Use medium for clear bounded work, high for substantial implementation, and xhigh or max when difficult reasoning justifies the extra work; low can suit small mechanical tasks. Match verification to the changed behavior and avoid repetitive self-checking. Report evidence and unresolved limitations concisely.";
-const DEFAULT_GPT_6_EXECUTION_DEFINITION: &str = "Baseline execution model for scoped implementation, debugging with a reproduction, migrations, code review, data analysis, and evidence gathering. Default to low effort for a clear brief; raise effort only when a specific piece demonstrably needs more depth. Keep unrelated improvements out of scope, match verification to the changed behavior, and report the concrete result and relevant checks concisely.";
+const OLD_DEFAULT_GPT_6_EXECUTION_DEFINITION: &str = "Baseline execution model for scoped implementation, debugging with a reproduction, migrations, code review, data analysis, and evidence gathering. Default to low effort for a clear brief; raise effort only when a specific piece demonstrably needs more depth. Keep unrelated improvements out of scope, match verification to the changed behavior, and report the concrete result and relevant checks concisely.";
+const DEFAULT_GPT_6_EXECUTION_DEFINITION: &str = "Execution model for scoped implementation, debugging with a reproduction, migrations, code review, data analysis, evidence gathering, and computer use. It is exceptionally strong at driving and reading real UIs (find_roots → observe_ui → search_ui / inspect_ui / read_text, and act_ui / wait_for when the brief allows), so route eyes-on-screen verification and UI-driving work here first. Always dispatch it at low effort: low outperforms the former Sol executor at xhigh on quality and at a fraction of the token cost, so medium or higher is never justified for this profile and only wastes money; a task that seems to need more depth needs a better brief, not more effort. Keep unrelated improvements out of scope. Report the concrete result and relevant checks concisely.";
 const DEFAULT_OPUS_DEFINITION: &str = "Execution model for agentic coding, cross-file implementation, refactoring, debugging, and review across providers, including user-facing behavior and API or UI details. Use medium for clear bounded work, high for substantial implementation, and xhigh or max when difficult reasoning justifies the extra work; low can suit small mechanical tasks. Match verification to the changed behavior and avoid repetitive self-checking. Report evidence and unresolved limitations concisely.";
 const DEFAULT_ASTRA_DEFINITION: &str = include_str!("../../../assets/orchestrate/astra.md");
 const DEFAULT_FABLE_DEFINITION: &str = include_str!("../../../assets/orchestrate/fable-5-1.md");
@@ -427,6 +428,13 @@ impl LegacyOrchestrateModel {
         {
             self.entry.description = DEFAULT_OPUS_DEFINITION.into();
         }
+        if !collaboration
+            && self.entry.provider == ProviderKind::Codex
+            && self.entry.model == "gpt-6-astra"
+            && self.entry.description == OLD_DEFAULT_GPT_6_EXECUTION_DEFINITION
+        {
+            self.entry.description = DEFAULT_GPT_6_EXECUTION_DEFINITION.into();
+        }
         let entry = &mut self.entry;
         let legacy = self.effort.is_some();
         if legacy {
@@ -1358,7 +1366,7 @@ mod tests {
         assert!(
             defaults.child_models[0]
                 .description
-                .contains("Default to low effort")
+                .contains("Always dispatch it at low effort")
         );
         assert_ne!(
             defaults.child_models[0].description,
@@ -1450,6 +1458,22 @@ mod tests {
         );
     }
 
+    #[test]
+    fn orchestrate_refreshes_untouched_previous_gpt_6_execution_text() {
+        let old_json = format!(
+            r#"{{"decision_models":[],"child_models":[{{"provider":"codex","model":"gpt-6-astra","description":{},"enabled":true,"fast":false}}]}}"#,
+            serde_json::to_string(OLD_DEFAULT_GPT_6_EXECUTION_DEFINITION).unwrap()
+        );
+        let migrated: OrchestrateSettings = serde_json::from_str(&old_json).unwrap();
+        assert_eq!(
+            migrated.child_models[0].description,
+            DEFAULT_GPT_6_EXECUTION_DEFINITION
+        );
+        let customized = old_json.replace(OLD_DEFAULT_GPT_6_EXECUTION_DEFINITION, "mine");
+        let kept: OrchestrateSettings = serde_json::from_str(&customized).unwrap();
+        assert_eq!(kept.child_models[0].description, "mine");
+    }
+
     #[test]
     fn orchestrate_preserves_every_customized_sol_shape() {
         let customized = [

crates/ui/src/orchestrate_settings.rs

@@ -1052,6 +1052,10 @@ mod tests {
         assert_eq!(peer.model, "gpt-6-astra");
         assert_eq!(executor.model, "gpt-6-astra");
         assert_ne!(peer.description, executor.description);
-        assert!(executor.description.contains("Default to low effort"));
+        assert!(
+            executor
+                .description
+                .contains("Always dispatch it at low effort")
+        );
     }
 }

docs/DESIGN.md

@@ -350,8 +350,9 @@ a read-only list of available reasoning efforts, and a Fast switch when supporte
 (or when a stored value needs to remain visible). Effort is selected per tool call
 from the live provider catalog, with bundled startup fallbacks. There is no saved
 fixed-effort field. Collaboration is limited to medium/high; omitted effort uses
-medium when available. GPT-6 execution starts at low as the baseline and escalates
-only when a specific piece demonstrably needs depth. Fast mode remains independent.
+medium when available. The GPT-6 executor is dispatched at low only; higher efforts
+are never used for it. Its description names computer use as a headline strength.
+Fast mode remains independent.
 Once a provider catalog is loaded, a configured model absent from it is rendered
 unavailable with the catalog mismatch and dispatch or collaboration is rejected;
 an empty pre-discovery catalog continues to use bundled fallbacks.

locales/en.yml

@@ -345,7 +345,7 @@ orchestrate:
     effort_unavailable: "Collaboration unavailable until medium/high capabilities are known"
   children:
     title: "Execution models"
-    description: "Built-in executors: GPT-6 Astra and Opus 5. Each provider/model appears once per list, including endpoint profiles, so collaboration and execution may use separate profiles for the same model. Start the GPT-6 executor at low effort and raise it only when a specific piece needs more depth."
+    description: "Built-in executors: GPT-6 Astra and Opus 5. Each provider/model appears once per list, including endpoint profiles, so collaboration and execution may use separate profiles for the same model. Dispatch the GPT-6 executor at low only; it is the first choice for computer use, and higher efforts cost more without better results."
     add: "Add execution model"
     empty: "No child-model profiles are configured. /orchestrate remains available, but dispatch calls will be rejected until a child model is added."
     none_enabled: "Every child-model profile is switched off. /orchestrate can still plan, but all dispatch calls will be rejected."

locales/zh-CN.yml

@@ -345,7 +345,7 @@ orchestrate:
     effort_unavailable: "尚无 medium/high 能力信息，暂不可协作"
   children:
     title: "执行模型"
-    description: "内置执行模型为 GPT-6 Astra 和 Opus 5。同一提供方的同一模型在每个列表中仅保留一条，因此同一模型可分别配置协作与执行角色。GPT-6 执行模型默认使用 low，仅在具体任务确实需要更深推理时提高档位。"
+    description: "内置执行模型为 GPT-6 Astra 和 Opus 5。同一提供方的同一模型在每个列表中仅保留一条，因此同一模型可分别配置协作与执行角色。GPT-6 执行模型仅使用 low；它是电脑操作任务的首选，更高档位只会增加成本而不会提升效果。"
     add: "添加执行模型"
     empty: "目前没有配置任何子模型。/orchestrate 仍然可用，但在添加子模型前，派发调用会被拒绝。"
     none_enabled: "所有子模型配置都已关闭。/orchestrate 仍可进行规划，但所有派发调用都会被拒绝。"