Skip to main content
This lesson explains configurable fields — a mechanism for passing runtime parameters to runnables (for example, switching the LLM model used for a specific invocation). Configurable fields let you avoid hard-coding options when initializing a runnable and instead override them per invocation. This is useful for cost control (default to a cheaper model) and flexibility (upgrade to a stronger model when needed).

Why use configurable fields?

  • Avoid reinitializing runnables to change runtime behavior.
  • Control costs by selecting cheaper defaults and overriding on demand.
  • Compose overrides with dynamic prompts and memory for flexible workflows.

Quick overview

  1. Import required classes.
  2. Register a configurable field on a runnable (e.g., model_name).
  3. Compose the runnable with a prompt.
  4. Invoke normally (uses default) or override with with_config(configurable={...}).

Imports and setup

Register a configurable field on a runnable

Initialize the ChatOpenAI runnable with a default model (for example gpt-3.5-turbo) and expose model_name as a configurable field that can be overridden at invocation time:

Create a prompt template

Wrap the template text in backticks in prose to avoid MDX parsing issues:

Compose the chain and invoke (default)

Compose the prompt and the runnable, then invoke normally. This uses the runnable’s default model (gpt-3.5-turbo):
Example output (using the default model):

Override the configurable field at runtime

Use with_config(configurable={...}) to pass overrides for registered configurable fields. Keys in the dictionary must match the configurable field ids you registered (in this example, "model_name"):
Example output (overridden to use GPT-4):
The configurable field id you register must match the parameter name the runnable expects at runtime (for example, model_name above). Use with_config(configurable={...}) to override values per invocation.

Practical considerations

When to use configurable fields

  • You want per-invocation control over LLM models or other runtime settings.
  • Your application serves varied tasks that require different capability levels.
  • You want to avoid reinitializing runnables or changing deployment configuration mid-run.
Try different OpenAI model names from the models list to see how outputs and token usage change. This pattern provides runtime flexibility without changing deployed code.

Watch Video