Airflow Summit 2026 is coming August 31 - September 2 in Austin, TX. Register now to secure your spot!

LlamaIndex Connection

The llamaindex connection type configures access to LLM and embedding providers for LlamaIndex. It backs LlamaIndexHook (see LlamaIndexHook for hook usage and installation instructions).

Default Connection IDs

The LlamaIndexHook uses llamaindex_default by default.

Configuring the Connection

Embedding Model (Extra field)

Default LlamaIndex embedding model name (e.g. text-embedding-3-small). This field appears as a dedicated input in the connection form (via conn-fields) and stores its value in extra["embed_model"].

LLM Model (Extra field)

Default LlamaIndex LLM model name (e.g. gpt-4o). This field appears as a dedicated input in the connection form (via conn-fields) and stores its value in extra["llm_model"].

API Key (Password field)

The API key for your LLM/embedding provider, passed as api_key= to the LlamaIndex model constructor.

Host (optional)

Optional base URL, passed as api_base= (for example, to point at an OpenAI-compatible proxy that serves official OpenAI model names).

The schema, port, and login fields are hidden in the connection form; they are not used by this connection type.

OpenAI models only, BYO for other vendors

LlamaIndexHook.get_embedding_model() always returns an OpenAIEmbedding instance, and get_llm() always returns an OpenAI LLM instance, regardless of the host you set. Setting host to point at a different server does not relax any validation – each class validates the model name against its own built-in list: a chat/completion-model list (ALL_AVAILABLE_MODELS, e.g. gpt-4o) for OpenAI, and a separate, much smaller embedding-model list (OpenAIEmbeddingModelType, e.g. text-embedding-3-small) for OpenAIEmbedding. The two lists mostly do not overlap – current-generation names such as gpt-4o or text-embedding-3-small are only valid for one of the two classes – though a handful of legacy names (ada, babbage, curie, davinci) happen to appear in both. The classes differ only in when their respective check runs:

  • OpenAIEmbedding validates the model name in its constructor, so get_embedding_model() raises immediately for a name not in its list.

  • OpenAI (the LLM class) accepts any model name string at construction time, but validates it lazily on first use, inside its metadata property. Any call that touches metadata – including .chat() and .complete() – raises a ValueError for a name not in its list. There is no constructor argument on either class that overrides this check (no context_window= / is_chat_model= argument).

In practice this means local or self-hosted models (Ollama, vLLM, and similar) are not usable through this connection type, even via host=, unless the server is configured to answer to an official OpenAI model name. For other vendors and for local models, instantiate the LlamaIndex class directly in your @task and pass it to the operator’s embed_model= / llm= parameter – this bypasses the hook and this connection type entirely (see LlamaIndexHook).

Model resolution order

Both get_embedding_model() and get_llm() resolve the model identifier from, in order:

  1. The embed_model / llm_model constructor argument on LlamaIndexHook.

  2. extra["embed_model"] / extra["llm_model"] on the connection.

If neither is set, the hook raises a ValueError when the model is needed.

Examples

OpenAI (embeddings and LLM)

{
    "conn_type": "llamaindex",
    "password": "sk-...",
    "extra": "{\"embed_model\": \"text-embedding-3-small\", \"llm_model\": \"gpt-4o\"}"
}

LLM only (embeddings unset)

{
    "conn_type": "llamaindex",
    "password": "sk-...",
    "extra": "{\"llm_model\": \"gpt-4o\"}"
}

Was this entry helpful?