Cloud-preplanner → local-executor split (TASK: decomposition) #89

Closed
opened 2026-05-16 23:49:59 +00:00 by claude-noether · 0 comments
Collaborator

Motivation

Norris autonomous mode (Phase 3) currently runs entirely on ONE model — picked at goal-launch time. For complex goals this forces a choice: cloud (capable, expensive, slow per step) or local (cheap, fast, easily distracted).

The proposed split: use the CLOUD model ONCE per Norris session to decompose the goal into a sequence of single-step imperative TASKs; then use the LOCAL model to EXECUTE each task. Most tasks are simple shell operations the local model handles fine — the cloud is only used for the planning layer that benefits from its reasoning.

Proposal

New Norris config block:

cfg.norris = {
    preplanner = "cloud",    -- model that emits TASK: list once
    executor   = "fast",     -- model that runs each task
    tasks_max  = 16,
}

Flow:

Phase A (cloud, once per Norris launch):
    "Analyze this goal. Decompose into single-step imperative tasks.
     Output format: TASK: <imperative sentence, max 80 chars>"

Phase B (local, per task):
    System: "You are a shell assistant. Execute: <TASK>"
    User: <relevant context>

The existing safety.norris_step loop runs Phase B once per parsed TASK; pre-step (Phase A) happens once at goal-launch.

Interactions

  • Phase 6 #51 (mid-loop budget eviction): preplanner TASKs need to survive eviction — store the task list separately from ctx.turns (similar to how ctx.norris_goal anchors).
  • Phase 7 cost tracking: preplanner call is one cloud round-trip; executor calls are local (no cost). Total cost is bounded by the preplanner step alone.
  • Phase 9 .aish.lua: project file could ship project-specific preplanner system prompts.

Estimate

User analysis: "1 day; very high gain". Architectural — touches safety.norris_step + new state field on ctx + Norris driver in repl.lua. Likely deserves its own phase (Phase 10 candidate alongside cost preflight enforcement and cross-session cost persistence).

Relation to existing work

This is what the current Norris mode HINTS at but doesn't structure explicitly: same loop, same model. The split decouples planning capability from execution speed/cost.

Source

Architecture analysis (2026-05-16). Marked as the "biggest ROI" item in the user-shared analysis.

## Motivation Norris autonomous mode (Phase 3) currently runs entirely on ONE model — picked at goal-launch time. For complex goals this forces a choice: cloud (capable, expensive, slow per step) or local (cheap, fast, easily distracted). The proposed split: use the CLOUD model ONCE per Norris session to decompose the goal into a sequence of single-step imperative TASKs; then use the LOCAL model to EXECUTE each task. Most tasks are simple shell operations the local model handles fine — the cloud is only used for the planning layer that benefits from its reasoning. ## Proposal New Norris config block: ```lua cfg.norris = { preplanner = "cloud", -- model that emits TASK: list once executor = "fast", -- model that runs each task tasks_max = 16, } ``` Flow: ``` Phase A (cloud, once per Norris launch): "Analyze this goal. Decompose into single-step imperative tasks. Output format: TASK: <imperative sentence, max 80 chars>" Phase B (local, per task): System: "You are a shell assistant. Execute: <TASK>" User: <relevant context> ``` The existing `safety.norris_step` loop runs Phase B once per parsed TASK; pre-step (Phase A) happens once at goal-launch. ## Interactions - Phase 6 #51 (mid-loop budget eviction): preplanner TASKs need to survive eviction — store the task list separately from ctx.turns (similar to how ctx.norris_goal anchors). - Phase 7 cost tracking: preplanner call is one cloud round-trip; executor calls are local (no cost). Total cost is bounded by the preplanner step alone. - Phase 9 .aish.lua: project file could ship project-specific preplanner system prompts. ## Estimate User analysis: "1 day; very high gain". Architectural — touches safety.norris_step + new state field on ctx + Norris driver in repl.lua. Likely deserves its own phase (Phase 10 candidate alongside cost preflight enforcement and cross-session cost persistence). ## Relation to existing work This is what the current Norris mode HINTS at but doesn't structure explicitly: same loop, same model. The split decouples planning capability from execution speed/cost. ## Source Architecture analysis (2026-05-16). Marked as the "biggest ROI" item in the user-shared analysis.
claude-noether added the feature request label 2026-05-16 23:49:59 +00:00
Sign in to join this conversation.