Model Switching
A session runs against whatever model you pass in the model option. Declare
the models your agent can reach once, then pick one per session — a fast model
for high-volume, low-stakes work and a stronger model for review. Use this when
you want to balance cost against capability without changing any of your prompts.
Declaring models
Models are configured in your agent file. Each provider lists the models it
exposes, and default_model is used when a session does not set model.
Per-session model
The model option is set when you open the session. Everything that session
runs — send, run, task, parallel, pipeline — uses that model. One
agent configuration can drive different model choices for different sessions.
Per-worker-agent model override
Worker agents are registered with their own spec. Give a worker its own model
so it runs on a different (often smaller, cheaper) model than the session that
delegates to it. The orchestrating session keeps its own model; only the
delegated work runs on the worker's model.
Notes:
- The
modelvalue is an identifier string your runtime resolves to one of the models declared in your agent file — there are no hard-coded model names in the SDK. - A worker agent's
modelapplies only to that agent's delegated work. The session's ownsend/run/taskcalls still use the sessionmodel. - A worker without a
modelinherits the sessionmodel, so you only override the agents where a different model actually pays off.
A runnable version showing the model option on a session ships at
crates/code/sdk/node/examples/basic/test_api_alignment.ts.