openclaw - 💡(How to fix) Fix [Feature]: Support multiple Ollama hosts by decoupling provider keys from API types [1 participants]

Summary

Allow multiple provider instances to use the api: "ollama" driver by decoupling the provider's unique ID from its API implementation type.

Problem to solve

Currently, OpenClaw appears to use the top-level provider key as the lookup mechanism for the API driver. This creates a 1:1 mapping constraint where only one Ollama instance can be registered.

Users with distributed setups (e.g. a low-power CPU host for light tasks and a powerful GPU host for heavy inference) cannot target these machines independently within OpenClaw.

Any custom key (like ollama-cpu) results in a No API provider registered error, even if api: "ollama" is specified. This forces a "one size fits all" approach to local LLM hosting which is inefficient for mixed-workload environments.

Proposed solution

Modify the provider factory/initialization logic to use the api field to resolve the driver, while preserving the provider key as a unique instance identifier.

providers:
  ollama-cpu: # Unique ID
    api: ollama # Driver lookup
    baseUrl: http://192.168.1.10:11434
  ollama-gpu: # Unique ID
    api: ollama # Driver lookup
    baseUrl: http://192.168.1.50:11434

The system should instantiate the OllamaProvider class (or equivalent) for every entry where api: "ollama" is found, passing the specific baseUrl and other parameters from that specific configuration block to the instance.

Alternatives considered

• External Proxy (e.g. LiteLLM): Adding a proxy layer to multiplex the requests. Why it's weaker: It adds unnecessary infrastructure complexity, increased latency, and a new point of failure for a feature that is already standard for other provider types (like OpenAI).

• Environment Variable Swapping: Manually changing the OLLAMA_HOST before startup. Why it's weaker: It prevents concurrent access to both hosts and requires manual intervention/restarts.

Impact

Affected users/systems: Users running multi-node local LLM setups or those transitioning between edge devices and workstation GPUs.

Severity: Blocks workflow. It prevents the architectural goal of offloading small tasks (heartbeats/summaries) to efficient hardware while reserving GPUs for complex queries.

Frequency: Always. The limitation is hard-coded into the current registration logic.

Consequence: Extra manual work (swapping configs), unnecessary power consumption (running small models on big GPUs), or forced adoption of complex third-party proxy tools.

Evidence/examples

Current Error Log (Representative): Error: No API provider registered for api: ollama-cpu (Note: This occurs even when the sub-field api: ollama is correctly set, because the registry keys off the parent name.)

This behavior is inconsistent with how openai-completions is handled in OpenClaw and other similar frameworks, where the api type defines the logic and the key defines the instance.

Additional information

This change would significantly improve OpenClaw's utility in home lab environments where hardware heterogeneity is common. Decoupling the ID from the Driver is a standard pattern that would make the provider system more robust for future plugins as well.