LLM Providers

AgentNode binds OpenAI-compatible hosted providers, local Ollama, and custom endpoints from a single provider registry. Credentials are resolved host-side — through an environment variable or the credential vault — and an environment variable always wins. Ollama runs locally and needs no API key when it is already running on your machine.

Supported providers

These presets are built in. They are the providers that agentnode setup, agentnode auth, and the host-side LLM binding understand.

Every key provider authenticates with an API key. Only Ollama is keyless. The Slug is what you pass to agentnode auth and llm.default_provider.

Set the default provider

Choose which provider the host-side LLM binding uses by default, then confirm it is configured.

$ agentnode config set llm.default_provider openai
$ agentnode auth status          # shows each provider and its effective source
$ agentnode auth test openai     # validate the key via a free endpoint

Add credentials

Store a key in the credential vault, or export the provider's environment variable (which overrides the vault):

$ agentnode auth set deepseek    # prompts for the key (hidden input)
# or, per shell / CI:
$ export DEEPSEEK_API_KEY=sk-...

Storage backends, env precedence, and the connector vault are covered in Credentials & Connectors.

Use Ollama locally

Ollama is a keyless, local provider — no account and no per-token cost. Select it as the default, then check that your local Ollama is reachable.

$ agentnode config set llm.default_provider ollama
$ agentnode auth test ollama   # localhost reachability check (not a key check)

This path needs no hosted API key, but it is not zero-setup: you must install Ollama, have it running, and pull a model. AgentNode never installs or starts Ollama for you, and never probes it automatically.

OpenAI-compatible and custom endpoints

Any endpoint that implements the OpenAI chat-completions API can be added as a config entry under llm.providers.<name> — no code change per provider. Endpoints that deviate from that protocol are not guaranteed to work.

{
  "llm": {
    "default_provider": "my-llm",
    "providers": {
      "my-llm": {
        "base_url": "https://my-host/v1",
        "api_key_env": "MY_LLM_API_KEY",
        "default_model": "my-model",
        "requires_key": true
      }
    }
  }
}

A custom entry can also override a preset field (for example, a different default_model). Set requires_key to false for a local, keyless endpoint.

Providers vs the runtime

This page covers which providers exist and how their credentials are configured. How an agent or the tool loop actually calls a model — registering tools, the auto tool-loop, and per-provider client wiring — lives in the LLM Runtime docs. Either way, keys stay host-side: a sandboxed agent reaches a model only through a host-side broker, so the provider key never enters the container.

Troubleshooting

Related

• Credentials & Connectors — vault storage, env precedence, connector secrets.
• LLM Runtime — how agents call models (AgentNodeRuntime, meta-tools, tool loop).
• Quick Start — install, set up, and run your first capability.
• Execution Sandbox — how untrusted code is isolated from your keys.
• Agents — agent tiers and llm_access.