Are you an LLM? View https://a3s-lab.github.io/Code/llms.txt for optimized Markdown documentation, or https://a3s-lab.github.io/Code/llms-full.txt for full documentation bundle. This page is also available as Markdown at https://a3s-lab.github.io/Code/en/guide/examples/planning.md
Planning mode controls what the session does before each send or stream
turn. With planning enabled, the model first writes a structured plan for the
request, and the session publishes it as events. Use it for multi-step work
(refactors, release reviews, audits) where a host UI should show the task list
before the agent starts editing.
Set it through the session planning option: PlanningMode in Rust and Go,
planningMode in Node.js, and planning_mode in Python. The accepted values
are:
Value
Behavior before each turn
"auto"
Default. Runs one pre-analysis model call; publishes no plan.
"enabled"
Runs pre-analysis, then asks the model for a plan and publishes it.
With "enabled", the session emits planning_start, then planning_end
carrying the plan, then task_updated with the plan's steps, then one
step_end per step with status pending. When goal tracking is on
(with_goal_tracking in Rust, goalTracking in Node.js, goal_tracking in
Python, GoalTracking in Go), a goal_extracted event with the goal comes
before planning_end. The events are also recorded on the run, so a host UI
can render the task list from stream events or from the run's event history.
If the planning call hits a transient model error, the session publishes a
fallback plan instead; cancellation, a non-retryable provider error, or an
exhausted budget fails the turn.
The plan is guidance for the host, not a separate execution loop: the turn still
chooses its own model and tool calls. Verification commands still provide the
completion evidence.