# How to Configure Custom LLM Providers (Azure, Vertex, Bedrock, Local Models) in Strix

> Configure custom LLM providers like Azure, Vertex, Bedrock, or local models in Strix using environment variables. Integrate seamlessly without code changes.

- Repository: [Strix/strix](https://github.com/usestrix/strix)
- Tags: how-to-guide
- Published: 2026-03-26

---

**Strix discovers LLM providers entirely through environment variables—set `STRIX_LLM` with a provider prefix like `azure/`, `vertex_ai/`, `bedrock/`, or `ollama/` along with corresponding API credentials to route requests to Azure OpenAI, Google Vertex AI, AWS Bedrock, or local Ollama instances without modifying any code.**

The open-source **Strix** framework (usestrix/strix) simplifies AI agent development by using an OpenAI-compatible abstraction layer that lets you **configure custom LLM providers** through standardized environment variables. Whether you're deploying on Azure's enterprise infrastructure, Google's Vertex AI, AWS Bedrock, or running models locally via Ollama, Strix dynamically resolves the correct endpoints and authentication schemes at runtime. This guide walks through the exact environment variables, configuration logic, and code examples needed to connect each provider.

## Understanding Strix's LLM Configuration Architecture

Before diving into provider-specific setups, it's essential to understand how Strix internalizes these settings. The framework uses three core components to transform environment variables into live LLM connections:

- **`resolve_llm_config()`** in [`strix/config/config.py`](https://github.com/usestrix/strix/blob/main/strix/config/config.py) (lines 89-115): Parses `STRIX_LLM` and extracts the model name, API key, and base URL.
- **`LLMConfig`** in [`strix/llm/config.py`](https://github.com/usestrix/strix/blob/main/strix/llm/config.py): Validates the model configuration, applies timeouts, and prepares the final client settings.
- **`resolve_strix_model()`** in [`strix/llm/utils.py`](https://github.com/usestrix/strix/blob/main/strix/llm/utils.py) (lines 47-62): Maps `strix/` aliases to canonical provider names for LiteLLM compatibility.

When `STRIX_LLM` lacks the `strix/` prefix, the system falls back to generic API base resolution (lines 126-133 in [`strix/config/config.py`](https://github.com/usestrix/strix/blob/main/strix/config/config.py)), passing the raw model identifier directly to the HTTP client while injecting provider-specific credentials into the request headers.

## Configuring Azure OpenAI

Azure OpenAI requires specific environment variables to authenticate against your Azure resource rather than OpenAI's public API.

- `STRIX_LLM="azure/<deployment-name>"` — The deployment name from your Azure OpenAI resource.
- `AZURE_API_KEY` — Your Azure OpenAI API key.
- `AZURE_API_BASE` — Base URL (e.g., `https://mycompany.openai.azure.com`).
- `AZURE_API_VERSION` — API version string (defaults to latest supported).

**How it works:** When `resolve_llm_config()` detects the `azure/` prefix in `STRIX_LLM`, it bypasses the Strix alias system and passes the raw deployment name to the HTTP client. The underlying LiteLLM transport injects the `AZURE_*` variables into the request headers to authenticate against Microsoft's endpoint.

```bash
export STRIX_LLM="azure/gpt-5.4-deployment"
export AZURE_API_KEY="YOUR-AZURE-KEY"
export AZURE_API_BASE="https://mycompany.openai.azure.com"
export AZURE_API_VERSION="2025-11-01-preview"

```

See `docs/llm-providers/azure.mdx` for detailed setup instructions.

## Configuring Google Vertex AI

Vertex AI integration relies on Google Cloud project identifiers and optional service account credentials.

- `STRIX_LLM="vertex_ai/<model-id>"` — Model identifier (e.g., `gemini-3-pro-preview`).
- `VERTEXAI_PROJECT` — Google Cloud project ID.
- `VERTEXAI_LOCATION` — Region (`global`, `us-central1`, etc.).
- `GOOGLE_APPLICATION_CREDENTIALS` (optional) — Path to service account JSON key.

**How it works:** Strix treats Vertex models as non-strix prefixes, triggering the generic base-URL logic in `resolve_llm_config()`. LiteLLM constructs the final URL using `https://{location}-aiplatform.googleapis.com/v1/projects/{project}/locations/{location}/publishers/google/models/{model}` and authenticates via Application Default Credentials if no service account key is provided.

```bash
export STRIX_LLM="vertex_ai/gemini-3-pro-preview"
export VERTEXAI_PROJECT="my-gcp-project"
export VERTEXAI_LOCATION="global"
export GOOGLE_APPLICATION_CREDENTIALS="$HOME/.gcp/vertex-sa.json"

```

Reference: `docs/llm-providers/vertex.mdx`

## Configuring AWS Bedrock

AWS Bedrock uses standard AWS credential chains rather than API keys.

- `STRIX_LLM="bedrock/<model-id>"` — Full Bedrock model ID (e.g., `anthropic.claude-4-5-sonnet-20251022-v1:0`).
- `AWS_PROFILE` or `AWS_ACCESS_KEY_ID` / `AWS_SECRET_ACCESS_KEY` — Standard AWS credentials.
- `AWS_REGION` — Region where Bedrock is enabled.

**How it works:** Similar to other non-strix providers, `resolve_llm_config()` passes the model name directly while LiteLLM reads AWS environment variables to construct signed HTTP requests to the Bedrock endpoint. No separate API key variable is required.

```bash
export STRIX_LLM="bedrock/anthropic.claude-4-5-sonnet-20251022-v1:0"
export AWS_PROFILE="my-aws-profile"
export AWS_REGION="us-east-1"

```

Documentation: `docs/llm-providers/bedrock.mdx`

## Configuring Local Models (Ollama)

For local development or air-gapped environments, Strix supports Ollama and other OpenAI-compatible local servers.

- `STRIX_LLM="ollama/<model-name>"` or `local/<model-name>` — Local model identifier.
- `OLLAMA_API_BASE` — Base URL (e.g., `http://localhost:11434/v1`).
- `LLM_API_KEY` (optional) — If your local server requires authentication.

**How it works:** The `ollama/` prefix triggers the local endpoint logic in `resolve_llm_config()`, using `OLLAMA_API_BASE` as the target URL. Strix sends standard OpenAI-compatible JSON payloads to `http://localhost:11434/v1/chat/completions`, allowing seamless switching between cloud and local models.

```bash
export STRIX_LLM="ollama/llama2"
export OLLAMA_API_BASE="http://localhost:11434/v1"

```

See `docs/llm-providers/local.mdx` for detailed Ollama setup.

## Programmatic Configuration Examples

While environment variables are the primary interface, you can also instantiate configurations directly in Python.

**Azure OpenAI programmatic setup:**

```python
import os
from strix.llm.config import LLMConfig

os.environ.update({
    "STRIX_LLM": "azure/gpt-5.4-deployment",
    "AZURE_API_KEY": "my-azure-key",
    "AZURE_API_BASE": "https://mycompany.openai.azure.com",
    "AZURE_API_VERSION": "2025-11-01-preview",
})

cfg = LLMConfig()
print(f"Model: {cfg.model_name}")          # azure/gpt-5.4-deployment

print(f"API base: {cfg.api_base}")         # https://mycompany.openai.azure.com

print(f"Litellm model: {cfg.litellm_model}")  # openai/gpt-5.4

```

**One-line Vertex AI execution:**

```bash
export STRIX_LLM="vertex_ai/gemini-3-flash-preview" \
  VERTEXAI_PROJECT="my-gcp-project" \
  VERTEXAI_LOCATION="global" \
  && strix run my-agent --task "scan codebase"

```

**Direct LLM instantiation for local models:**

```python
from strix.llm.llm import LLM

llm = LLM(
    model="ollama/llama2",
    api_key=None,
    api_base="http://localhost:11434/v1"
)
response = llm.chat(messages=[{"role": "user", "content": "Explain Strix architecture"}])
print(response)

```

## Summary

- **Environment-driven configuration:** Strix relies entirely on environment variables to select providers and authenticate requests, requiring no code changes when switching between Azure, Vertex, Bedrock, or local models.
- **Provider prefixes matter:** Use `azure/`, `vertex_ai/`, `bedrock/`, or `ollama/` prefixes in `STRIX_LLM` to trigger provider-specific resolution paths in [`strix/config/config.py`](https://github.com/usestrix/strix/blob/main/strix/config/config.py).
- **Core resolution pipeline:** The `resolve_llm_config()` function (lines 89-115) parses inputs, `LLMConfig` validates and builds the client configuration, and `resolve_strix_model()` handles alias translation for LiteLLM compatibility.
- **OpenAI compatibility:** All providers ultimately receive OpenAI-compatible HTTP requests, allowing Strix to support any endpoint conforming to that schema without SDK dependencies.

## Frequently Asked Questions

### Can I use multiple LLM providers simultaneously in one Strix application?

Yes. While the global `STRIX_LLM` environment variable sets the default provider, you can instantiate specific providers programmatically by creating `LLM` objects with explicit `model`, `api_key`, and `api_base` parameters. This allows you to route different tasks to different providers within the same codebase.

### Why does Strix use the `strix/` prefix for some models but not others?

The `strix/` prefix triggers the alias resolution system in [`strix/llm/utils.py`](https://github.com/usestrix/strix/blob/main/strix/llm/utils.py), which maps shorthand names like `strix/gpt-5.4` to canonical provider identifiers. When you use provider-specific prefixes like `azure/` or `bedrock/`, Strix bypasses this alias system and passes the model name directly to the underlying LiteLLM transport, enabling native access to provider-specific features.

### How do I troubleshoot connection errors to my custom LLM provider?

First, verify that `resolve_llm_config()` can parse your `STRIX_LLM` value by checking if it falls into the generic base-URL resolution path (lines 126-133 in [`strix/config/config.py`](https://github.com/usestrix/strix/blob/main/strix/config/config.py)). Ensure provider-specific variables like `AZURE_API_BASE` or `VERTEXAI_PROJECT` are exported in your shell environment, not just set in a configuration file that Strix might not load. For local models, confirm the `OLLAMA_API_BASE` includes the `/v1` suffix required for OpenAI compatibility.

### Does Strix install SDKs for Azure, Google Cloud, or AWS automatically?

No. Strix communicates with all providers through LiteLLM using OpenAI-compatible HTTP requests. It does not ship provider-specific SDKs, which keeps the installation lightweight. You only need the standard AWS CLI credentials, gcloud authentication, or Azure API keys configured in your environment—no additional Python packages required for provider connectivity.