OpenClawDocs
View as MarkdownView this page as plain textOpen in ChatGPTAsk questions about this pageOpen in ClaudeAsk questions about this page

Providers

Ollama setup

Auth rules

Local and LAN hosts

Loopback, private-network, .local, and bare-hostname Ollama URLs do not need a real bearer token. OpenClaw uses the ollama-local marker for these.

Remote and Ollama Cloud hosts

Public remote hosts and https://ollama.com require a real credential: OLLAMA_API_KEY, an auth profile, or the provider's apiKey. For direct hosted use, prefer the ollama-cloud provider.

Custom provider ids

A custom provider with api: "ollama" follows the same rules. For example, an ollama-remote provider pointed at a private LAN host can use apiKey: "ollama-local"; sub-agents resolve that marker through the Ollama provider hook instead of treating it as a missing credential. memory.search.provider can also point at a custom provider id so embeddings use that Ollama endpoint.

Auth profiles

SQLite auth stores hold the credential for a provider id; put endpoint settings (baseUrl, api, models, headers, timeouts) in models.providers.<id>. Older flat auth-profiles.json files such as { "ollama-windows": { "apiKey": "ollama-local" } } are not a runtime format; openclaw doctor --fix imports them into SQLite as a canonical ollama-windows:default API-key profile with a backup. A baseUrl value in that legacy file is noise and should move to provider config.

Memory embedding scope

Bearer auth for Ollama memory embeddings is scoped to the host it was declared for:

  • A provider-level key is sent only to that provider's host.
  • memory.search.remote.apiKey and per-agent overrides are sent only to their remote embedding host.
  • A pure OLLAMA_API_KEY env value is treated as the Ollama Cloud convention and is not sent to local/self-hosted hosts by default.

Getting started

Manual setup

  • Install and start Ollama

    Get it from ollama.com/download, then pull a model:

    bash
    ollama pull gemma4

    For hybrid cloud access, run ollama signin on the same host.

  • Set a credential

    bash
    export OLLAMA_API_KEY="ollama-local"    # local/LAN host, any value worksexport OLLAMA_API_KEY="your-real-key"   # https://ollama.com only

    Or in config: openclaw config set models.providers.ollama.apiKey "OLLAMA_API_KEY".

  • Select the model

    bash
    openclaw models listopenclaw models set ollama/gemma4

    Or in config:

    json5
    {  agents: {    defaults: {      model: { primary: "ollama/gemma4" },    },  },}

    • Cloud models through a local host

    Cloud + Local routes both local and :cloud models through one reachable Ollama host — this is Ollama's hybrid flow and the mode to pick during setup when you want both.

    OpenClaw prompts for the base URL, discovers local models, and checks ollama signin status. When signed in, it suggests hosted defaults (kimi-k2.5:cloud, minimax-m2.7:cloud, glm-5.1:cloud, glm-5.2:cloud). If not signed in, setup stays local-only until you run ollama signin.

    For cloud-only access without a local daemon, use openclaw onboard --auth-choice ollama-cloud and see Ollama Cloud — that path does not need ollama signin or a running server:

    bash
    openclaw onboard --auth-choice ollama-cloudopenclaw models set ollama-cloud/kimi-k2.5:cloud

    The cloud model list shown during openclaw onboard is populated live from https://ollama.com/api/tags, capped at 500 entries, so the picker reflects the current hosted catalog. If ollama.com is unreachable or returns no models at setup time, OpenClaw falls back to its hardcoded suggested list so onboarding still completes.

    Was this useful?
    On this page

    On this page