Route the model at each step
Choose among models of one model provider using a System One decision.
Declare a route
Section titled “Declare a route”Attach defineHarnessModelRouting() to the built-in harness when each step should choose its own conversational model. The route names must exactly match the selected choice question; all candidates use the harness’s existing ModelProvider. CLI harness presets keep their configured model.
Set FAST_MODEL and DEEP_MODEL to names supported by your conversational model service. The candidate’s reasoning and maxOutputTokens apply only when it is selected; settings from the previous model do not carry over.
Compose the agent
Section titled “Compose the agent”The harness validates every candidate during composition, before allocating a sandbox. The agent’s declared model supplies the initial model, including any compaction before the first selection.
Pass this agent to your dispatch with the configured sandbox provider. These API keys remain on the host; tools use the dispatch sandbox. A subagent can declare its own routed harness, using its separate history and cumulative ancestor budgets.
Supply useful state
Section titled “Supply useful state”The route is evaluated once per step, after compaction and before before-model. The default state includes session instructions, visible messages, available tools, step number and active model. Opaque reasoning blocks are excluded. Tool results and structured-response repair messages therefore affect the next decision.
Session instructions are resolved once. Compaction uses the active model before the next route is chosen. Hooks and tools receive the newly selected model. Selection preserves the sandbox, history and tool calls; incompatible replayable reasoning is filtered by the existing model-provider rules.
Your callback can be asynchronous and receives the cancellation signal. Outpost never silently truncates the resulting state. Choose any explicit reduction according to your application’s needs.
Choose a fallback policy
Section titled “Choose a fallback policy”The default confidence threshold is 0.85; a smaller confidence selects fallback. With the default onError: "fallback", timeouts and explicitly classified service unavailability also select it. onError: "fail" propagates those failures.
Quota, cancellation, configuration faults, invalid responses and truncation always propagate. A successful decision without usage, or an unavailable request without a usage receipt, marks consumption incomplete; a strict token budget can stop the turn rather than continue with unknown consumption.
Observe and resume
Section titled “Observe and resume”decision observations summarize router requests; model-route agent events identify each selection and its reason. Detailed request state and responses require verbose observation. Usage is accounted once independently of sinks, adding routing to harness, ancestor and workflow budgets.
Routed transcripts use version 2 while retaining the harness storage format. Version 1 remains readable. Capture, resume and fork preserve messages; the next step makes a fresh decision without replaying completed calls. Journal replay restores recorded selections and decision observations without contacting the router; detailed payloads still require a verbose hub. See observability and conversations.
API: defineHarnessModelRouting · HarnessModelRoutingOptions.