Skip to main content

LLM Configuration

Open In Colab Open on GitHub

In AutoGen, agents use LLMs as key components to understand and react. To configure an agent’s access to LLMs, you can specify an llm_config argument in its constructor. For example, the following snippet shows a configuration that uses gpt-4:

import os

llm_config = {
"config_list": [{"model": "gpt-4", "api_key": os.environ["OPENAI_API_KEY"]}],

It is important to never commit secrets into your code, therefore we read the OpenAI API key from an environment variable.

This llm_config can then be passed to an agent’s constructor to enable it to use the LLM.

import autogen

assistant = autogen.AssistantAgent(name="assistant", llm_config=llm_config)

Introduction to config_list

Different tasks may require different models, and the config_list allows specifying the different endpoints and configurations that are to be used. It is a list of dictionaries, each of which contains the following keys depending on the kind of endpoint being used:

  • model (str, required): The identifier of the model to be used, such as 'gpt-4', 'gpt-3.5-turbo'.
  • api_key (str, optional): The API key required for authenticating requests to the model's API endpoint.
  • base_url (str, optional): The base URL of the API endpoint. This is the root address where API calls are directed.
  • tags (List[str], optional): Tags which can be used for filtering.


"model": "gpt-4",
"api_key": os.environ['OPENAI_API_KEY']


By default this will create a model client which assumes an OpenAI API (or compatible) endpoint. To use custom model clients, see here.


A common, useful pattern used is to define this config_list is via JSON (specified as a file or an environment variable set to a JSON-formatted string) and then use the config_list_from_json helper function to load it:

config_list = autogen.config_list_from_json(

# Then, create the assistant agent with the config list
assistant = autogen.AssistantAgent(name="assistant", llm_config={"config_list": config_list})

This can be helpful as it keeps all the configuration in one place across different projects or notebooks.

This function interprets the env_or_file argument as follows:

  • If env_or_file is an environment variable then:
    • It will first try to load the file from the path specified in the environment variable.
    • If there is no file, it will try to interpret the environment variable as a JSON string.
  • Otherwise, it will try to open the file at the path specified by env_or_file.

Why is it a list?

Being a list allows you to define multiple models that can be used by the agent. This is useful for a few reasons:

  • If one model times out or fails, the agent can try another model.
  • Having a single global list of models and filtering it based on certain keys (e.g. name, tag) in order to pass select models into a certain agent (e.g. use cheaper GPT 3.5 for agents solving easier tasks)
  • While the core agents, (e.g. conversable or assistant) do not have special logic around selecting configs, some of the specialized agents may have logic to select the best model based on the task at hand.

How does an agent decide which model to pick out of the list?

An agent uses the very first model available in the “config_list” and makes LLM calls against this model. If the model fails (e.g. API throttling) the agent will retry the request against the 2nd model and so on until prompt completion is received (or throws an error if none of the models successfully completes the request). In general there’s no implicit/hidden logic inside agents that is used to pick “the best model for the task”. However, some specialized agents may attempt to choose “the best model for the task”. It is developers responsibility to pick the right models and use them with agents.

Config list filtering

As described above the list can be filtered based on certain criteria. This is defined as a dictionary of key to filter on and values to filter by. For example, if you have a list of configs and you want to select the one with the model “gpt-3.5-turbo” you can use the following filter:

filter_dict = {"model": ["gpt-3.5-turbo"]}

This can then be applied to a config list loaded in Python with filter_config:

config_list = autogen.filter_config(config_list, filter_dict)

Or, directly when loading the config list using config_list_from_json:

config_list = autogen.config_list_from_json(env_or_file="OAI_CONFIG_LIST", filter_dict=filter_dict)


Model names can differ between OpenAI and Azure OpenAI, so tags offer an easy way to smooth over this inconsistency. Tags are a list of strings in the config_list, for example for the following config_list:

config_list = [
{"model": "my-gpt-4-deployment", "api_key": "", "tags": ["gpt4", "openai"]},
{"model": "llama-7B", "base_url": "", "tags": ["llama", "local"]},

Then when filtering the config_list you can can specify the desired tags. A config is selected if it has at least one of the tags specified in the filter. For example, to just get the llama model, you can use the following filter:

filter_dict = {"tags": ["llama", "another_tag"]}
config_list = autogen.filter_config(config_list, filter_dict)
assert len(config_list) == 1

Adding http client in llm_config for proxy

In Autogen, a deepcopy is used on llm_config to ensure that the llm_config passed by user is not modified internally. You may get an error if the llm_config contains objects of a class that do not support deepcopy. To fix this, you need to implement a __deepcopy__ method for the class.

The below example shows how to implement a __deepcopy__ method for http client and add a proxy.

#!pip install httpx
import httpx

class MyHttpClient(httpx.Client):
def __deepcopy__(self, memo):
return self

config_list = [
"model": "my-gpt-4-deployment",
"api_key": "",
"http_client": MyHttpClient(proxy="http://localhost:8030"),

llm_config = {
"config_list": config_list,

Other configuration parameters

Besides the config_list, there are other parameters that can be used to configure the LLM. These are split between parameters specifically used by Autogen and those passed into the model client.

AutoGen specific parameters

  • cache_seed - This is a legacy parameter and not recommended to be used unless the reason for using it is to disable the default caching behavior. To disable default caching, set this to None. Otherwise, by default or if an int is passed the DiskCache will be used. For the new way of using caching, pass a Cache object into initiate_chat.

Extra model client parameters

It is also possible to passthrough parameters through to the OpenAI client. Parameters that correspond to the OpenAI client or the OpenAI completions create API can be supplied.

This is commonly used for things like temperature, or timeout.


llm_config = {
"config_list": [
"model": "my-gpt-4-deployment",
"api_key": os.environ.get("AZURE_OPENAI_API_KEY"),
"api_type": "azure",
"base_url": os.environ.get("AZURE_OPENAI_API_BASE"),
"api_version": "2024-02-15-preview",
"model": "llama-7B",
"base_url": "",
"api_type": "openai",
"temperature": 0.9,
"timeout": 300,

Other helpers for loading a config list

  • get_config_list: Generates configurations for API calls, primarily from provided API keys.
  • config_list_openai_aoai: Constructs a list of configurations using both Azure OpenAI and OpenAI endpoints, sourcing API keys from environment variables or local files.
  • config_list_from_models: Creates configurations based on a provided list of models, useful when targeting specific models without manually specifying each configuration.
  • config_list_from_dotenv: Constructs a configuration list from a .env file, offering a consolidated way to manage multiple API configurations and keys from a single file.

See this notebook for examples of using the above functions.