Skip to main content
PlanStream is the client-side wrapper for consuming planning lifecycle events while an approved execution plan runs. Use it together with the IllaSDK facade methods executePlan (start streaming a plan) and sendStepDecision (steer a step that needs a decision).
Planning is an early-access capability. The planning backend is gated on the server side and may not be enabled for your API key or environment — when it is not, a chat turn behaves like a normal (non-planning) response and no plan is returned. The planning types and event surface may still change; for example, step decisions currently reuse the /api/v1/chat/ route pending a dedicated endpoint.

How planning fits together

  1. A planning-enabled chat turn returns an ExecutionPlan on the response (response.data.plan), along with requiresApproval and availableActions.
  2. After the user approves, call executePlan(plan) to stream the plan’s execution.
  3. Attach handlers to the returned PlanStream to observe lifecycle events.
  4. If a step fails or needs guidance, call sendStepDecision(...) to retry, stop, or edit the request.

executePlan

Submits an approved ExecutionPlan and returns a PlanStream that emits real-time planning events. Internally this opens an SSE request (Accept: text/event-stream) and hands the response body to a new PlanStream.

sendStepDecision

Sends a step-level decision. StepDecision has:
string
required
ID of the plan the step belongs to.
number
required
Version of the plan (positive integer).
number
required
1-based step number the decision applies to.
'retry' | 'stop' | 'edit_request'
required
What to do with the step.
string
New intent text. Required when action is 'edit_request'.
The returned CoreApiChatResponse is the same union a chat turn returns. Narrow success with "status" in response && response.status === 200.

PlanStream

PlanStream parses SSE frames from a ReadableStream<Uint8Array>, validates each frame against the shared telemetry-event schema, and dispatches planning events to typed handlers. Unknown event types are silently ignored for forward compatibility, and stream consumption is deferred to the next microtask so you can register handlers synchronously right after construction.
PlanStreamOptions:
() => void
Called when the stream closes normally.
(error: Error) => void
Called on a connection- or parsing-level error.

Methods

The stream returned by executePlan is constructed without PlanStreamOptions, so it reports server-sent problems through the error event and closes automatically when the stream ends. To observe connection- or parsing-level failures (network drop, malformed SSE) or to run a close hook, construct PlanStream directly with onError / onClose.

Plan event vocabulary

on() accepts every planning event plus the stream-control types connected, stream_end, and error. Lifecycle events
  • plan_generating — plan generation started (messageCount)
  • plan_generated — plan ready (planId, version, stepCount, complexity, isExecutable, autoExecutable, hasConflicts)
  • plan_step_started — a step began (planId, stepNumber, description, operationType)
  • plan_step_retrying — a step attempt failed and a retry is scheduled (stepNumber, attempt, maxRetries, phase)
  • plan_step_completed — a step finished (stepNumber, status: completed | failed | skipped)
  • plan_invalidated — the plan can no longer continue (reason, failedStepNumber)
  • replan_started — re-planning started (previousPlanId, reason, preservedStepCount)
  • replan_complete — re-planning produced a new plan (previousPlanId, newPlanId, newVersion)
  • plan_execution_complete — execution finished (status: complete | partial | failed, completedSteps, totalSteps)
  • plan_expired — the plan or planning session expired before the next resume step (subject, blockedAction, expiredAt)
Runtime (simulation) events
  • plan_step_simulated — a write step was simulated (simulationSuccess, simulationSummary)
  • plan_step_verification_passed — the verifier accepted the simulation (confidence, reason)
  • plan_step_verification_failed — the verifier rejected the simulation (confidence, reason, conflicts, recommendedAction)
  • plan_execution_failed — execution failed fatally (error, phase)

PlanStreamHandlerFailure

If one of your registered handlers throws while processing an event, PlanStream wraps the thrown error in a PlanStreamHandlerFailure and forwards it to onError. The failure exposes the eventType whose handler threw and preserves the original error as its cause, so a handler throwing never breaks the stream or other handlers.

Full example