ReasoningPlanSettings interface

Settings for creating a reasoning plan session.

Two modes of operation: - Event mode: provide events. The planning LLM is told about the available events and designs the spec around them. At evaluation time, events are emitted via onLLMResponse. - Text mode: omit events, provide onResponse. The evaluation LLM returns free-form text/JSON, passed through to onResponse. - Both can be provided: tool-calling mode with onResponse capturing any text the LLM generates alongside tool calls.

Signature:

export interface ReasoningPlanSettings

Properties

Property	Type	Description
allowedTools?	"all" \| LocalAnalysisToolName[]	(Optional) Opt in to planner-designed analysis flows: grant the planner a palette of local tools and it designs the localAnalysis flow itself — tools, instance gates, cadence — validated server-side exactly as a hand-written configuration would be, with costs weighed in the design. "all" grants every tool. Any localAnalysisTools are always kept and the planner designs on top of them (it may gate on their signals). Artifacts the planner cannot supply (galleries, model files) surface as ReasoningSpec.requirements. Omit for today’s behaviour where localAnalysisTools alone define the flow.
analysisIntervalSecs?	number	(Optional) How often (in seconds) the evaluation runs. Informs the planner about the analysis cadence.
averageResponseTimeMs?	number	(Optional)
contextDocuments?	string[]	(Optional) Reference documents (markdown) providing domain context for the planning LLM. These are included in the system instruction and cached across frames.
events?	EventDeclaration[]	(Optional)
localAnalysisTools?	LocalAnalysisConfig[]	(Optional) Local analysis tools available for the planner to consider. Each tool config describes the tool, its data window, and aggregation strategy.
onError?	(error: string) ⇒ void	(Optional)
onProposedSpec?	(spec: ReasoningSpec) ⇒ void	(Optional)
onResponse?	(response: unknown) ⇒ void	(Optional)
provider	ReasoningProvider
query	string
reviewSpec?	boolean	(Optional) Review each proposed spec before it is surfaced: a second LLM request critiques the candidate against the original query, and one revision is applied when the review rejects it. Costs one or two extra plan-time requests; the plan phase is pre-live, so quality usually beats cost. Defaults to false — except when allowedTools is supplied (flow design), where it defaults to true: the review also critiques the proposed flow’s cost and its coherence with the prompt, which smaller local models get wrong often enough to be worth a request. Pass an explicit false to opt out.

Property

Type

Description

allowedTools?

"all" | LocalAnalysisToolName[]

(Optional) Opt in to planner-designed analysis flows: grant the planner a palette of local tools and it designs the localAnalysis flow itself — tools, instance gates, cadence — validated server-side exactly as a hand-written configuration would be, with costs weighed in the design. "all" grants every tool. Any localAnalysisTools are always kept and the planner designs on top of them (it may gate on their signals). Artifacts the planner cannot supply (galleries, model files) surface as ReasoningSpec.requirements. Omit for today’s behaviour where localAnalysisTools alone define the flow.

analysisIntervalSecs?

number

(Optional) How often (in seconds) the evaluation runs. Informs the planner about the analysis cadence.

averageResponseTimeMs?

number

(Optional)

contextDocuments?

string[]

(Optional) Reference documents (markdown) providing domain context for the planning LLM. These are included in the system instruction and cached across frames.

events?

EventDeclaration[]

(Optional)

localAnalysisTools?

LocalAnalysisConfig[]

(Optional) Local analysis tools available for the planner to consider. Each tool config describes the tool, its data window, and aggregation strategy.

onError?

(error: string) ⇒ void

(Optional)

onProposedSpec?

(spec: ReasoningSpec) ⇒ void

(Optional)

onResponse?

(response: unknown) ⇒ void

(Optional)

string

boolean

(Optional) Review each proposed spec before it is surfaced: a second LLM request critiques the candidate against the original query, and one revision is applied when the review rejects it. Costs one or two extra plan-time requests; the plan phase is pre-live, so quality usually beats cost. Defaults to false — except when allowedTools is supplied (flow design), where it defaults to true: the review also critiques the proposed flow’s cost and its coherence with the prompt, which smaller local models get wrong often enough to be worth a request. Pass an explicit false to opt out.