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
- Import required classes.
- Register a configurable field on a runnable (e.g.,
model_name). - Compose the runnable with a prompt.
- 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 examplegpt-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):
Override the configurable field at runtime
Usewith_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"):
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.
Links and references
- OpenAI Models Overview: https://platform.openai.com/docs/models/overview
- LangChain (core concepts and runnables): https://langchain.readthedocs.io/ (or the relevant repo/docs for your distribution)