How to Configure Different LLM Providers in Neuro SAN (OpenAI, Anthropic, Azure, Bedrock, Gemini, Ollama)

Configure LLM providers in Neuro SAN by setting the class key in the llm_config block to openai, anthropic, azure-openai, bedrock, gemini, or ollama, then specify the model_name and required environment variables.

Neuro SAN is an open-source framework for building agentic AI networks using Large Language Models. To configure different LLM providers in Neuro SAN, you modify the llm_config HOCON block that defines which LangChain factory to instantiate and which model endpoint to call. This configuration lives in registries/llm_config.hocon and can be included in any agent network definition.

Understanding the LLM Configuration Architecture

The llm_config block is the central mechanism for LLM provider selection in Neuro SAN. This block typically resides in registries/llm_config.hocon and is designed to be included across multiple agent network files.

The configuration uses the class key to determine which LangChain chat model factory to instantiate. This mapping is defined in neuro_san/internals/run_context/langchain/llms/default_llm_info.hocon in the core Neuro SAN repository. When you specify "class": "anthropic", the system instantiates the appropriate LangChain ChatAnthropic class using the parameters you provide.

Supported LLM Providers and Configuration Examples

Each provider requires specific environment variables and model naming conventions. The model_name value must match the provider's expected identifier format.

OpenAI

Set "class": "openai" and provide your API key via the OPENAI_API_KEY environment variable.

# registries/llm_config.hocon

{
    "llm_config": {
        "class": "openai",
        "model_name": "gpt-4o",
        "temperature": 0.7,
        "max_tokens": 4096
    }
}

Anthropic

Set "class": "anthropic" and export ANTHROPIC_API_KEY.

{
    "llm_config": {
        "class": "anthropic",
        "model_name": "claude-3-7-sonnet",
        "temperature": 0.5
    }
}

Azure OpenAI

Use "class": "azure-openai" and set AZURE_OPENAI_API_KEY, AZURE_OPENAI_ENDPOINT, and optionally AZURE_OPENAI_DEPLOYMENT_NAME. The model_name must start with azure- to ensure correct endpoint selection.

{
    "llm_config": {
        "class": "azure-openai",
        "model_name": "azure-gpt-4o",
        "temperature": 0.7
    }
}

Amazon Bedrock

Set "class": "bedrock" and configure AWS credentials via AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION, or use credentials_profile_name to reference a named profile in ~/.aws/credentials.

{
    "llm_config": {
        "class": "bedrock",
        "model_name": "bedrock-us-claude-3-7-sonnet",
        "credentials_profile_name": "my-aws-profile",
        "region_name": "us-west-2"
    }
}

Google Gemini

Use "class": "gemini" and set GOOGLE_API_KEY.

{
    "llm_config": {
        "class": "gemini",
        "model_name": "gemini-3-flash",
        "temperature": 0.7
    }
}

Ollama

Set "class": "ollama" for local or remote Ollama instances. No API key is required, but the model must be available in the Ollama server. Use base_url for remote deployments.

{
    "llm_config": {
        "class": "ollama",
        "model_name": "qwen3:8b",
        "base_url": "http://my-docker-host:11434"
    }
}

Applying LLM Configuration in Agent Networks

You can apply LLM configurations at the network level or override them for specific agents.

Global Configuration via Registry Inclusion

Include the central registry in your agent network file to apply settings to all agents:

# registries/basic/music_nerd.hocon

{
    include "registries/llm_config.hocon"

    "agents": [
        {
            "name": "MusicNerd",
            "instructions": "Answer music-history questions.",
            "toolbox": "get_current_date_time"
        }
    ]
}

Per-Agent Overrides

Embed an llm_config block inside a specific agent to override the network default:

{
    include "registries/llm_config.hocon"

    "agents": [
        {
            "name": "MusicNerd",
            "instructions": "Answer music-history questions.",
            "llm_config": {
                "class": "anthropic",
                "model_name": "claude-3-7-sonnet",
                "temperature": 0.5
            }
        }
    ]
}

Troubleshooting Common Configuration Issues

Authentication and naming errors are the most common pitfalls when you configure different LLM providers in Neuro SAN.

• Missing environment variables: The server starts successfully, but LLM calls fail with authentication errors. Verify that OPENAI_API_KEY, ANTHROPIC_API_KEY, GOOGLE_API_KEY, or AWS credentials are exported in your shell or .env file.

• Azure model naming: If the model_name does not start with azure-, Neuro SAN treats it as a standard OpenAI model and attempts to use the wrong endpoint, resulting in 404 or authentication errors.

• Bedrock region and profile mismatches: Amazon Bedrock requires the correct region_name (e.g., us-west-2) where the model is enabled. If using credentials_profile_name, ensure the profile exists in ~/.aws/credentials and has sufficient IAM permissions for Bedrock invocation.

• Ollama model availability: When using "class": "ollama", the specified model_name must be pulled and available in the Ollama server. If running Ollama in Docker or on a remote host, verify the base_url points to the correct host and port (default 11434).

Summary

• Configure LLM providers in Neuro SAN using the llm_config HOCON block, setting the class key to openai, anthropic, azure-openai, bedrock, gemini, or ollama.
• Centralize configuration in registries/llm_config.hocon and include it in agent networks, or override settings per-agent by embedding llm_config inside specific agent definitions.
• Set required environment variables for each provider: OPENAI_API_KEY, ANTHROPIC_API_KEY, AZURE_OPENAI_API_KEY, GOOGLE_API_KEY, or AWS credentials for Bedrock.
• Use provider-specific naming conventions: Azure models must start with azure-, and Ollama requires the model to be locally available or accessible via base_url.

Frequently Asked Questions

Can I use different LLMs for different agents in the same network?

Yes. While you can set a global llm_config in registries/llm_config.hocon and include it at the network level, you can override this for any specific agent by adding an llm_config block directly inside that agent's definition. This allows one agent to use GPT-4o while another uses Claude 3.7 Sonnet within the same agent network.

How do I add a custom model not listed in the default LLM info?

If your model uses an existing provider class (like openai or bedrock), simply specify the custom model_name in your llm_config. If you need to add a completely new provider or custom factory, you must add an entry to neuro_san/internals/run_context/langchain/llms/default_llm_info.hocon in the core Neuro SAN repository, defining the mapping between your new class value and the LangChain factory implementation.

Why does my Azure OpenAI configuration fail with authentication errors?

Azure OpenAI requires the model_name to start with the prefix azure- (for example, azure-gpt-4o). If you omit this prefix, Neuro SAN treats the configuration as a standard OpenAI request and attempts to use the OpenAI endpoint rather than the Azure endpoint, resulting in authentication or 404 errors. Additionally, verify that AZURE_OPENAI_API_KEY and AZURE_OPENAI_ENDPOINT are correctly exported in your environment.

Does Neuro SAN support local LLMs without internet access?

Yes, via the Ollama provider. Set "class": "ollama" in your llm_config and specify a locally available model name (such as qwen3:8b or llama3). No API key is required, but the model must be pulled and running in your local Ollama server. For remote or Docker-based Ollama deployments, use the base_url parameter to point to the correct host and port (default is http://localhost:11434).

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}