Configure and switch OpenClaw model providers

OpenClaw supports multiple AI model providers including OpenAI GPT series, Anthropic Claude series, Google Gemini models, and local models through Ollama. Each provider offers different tradeoffs in reasoning quality, cost per token, latency characteristics, and data privacy posture.

Provider selection criteria should include task complexity requirements (simple tasks may not need the most capable models), budget constraints (providers vary significantly in per-token pricing), privacy requirements (some deployments require local model execution without data transmission), and reliability requirements (providers have different uptime track records and outage frequencies).

Consider starting with one provider for initial deployment, establishing operational baselines, then evaluating alternative providers for specific use cases that might benefit from different capability profiles. Running multiple providers simultaneously through fallback configuration provides resilience without requiring immediate full migration.

API keys provide authentication to model provider services and must be protected from unauthorized access. Store API keys in environment variables rather than configuration files that may be committed to version control. Use secret management tools like HashiCorp Vault, AWS Secrets Manager, or platform-native secret storage for production deployments.

When entering API keys in the OpenClaw configuration, verify the credentials are correct before saving. Incorrect keys produce authentication failures that block all model communication. After saving new credentials, run the connectivity validation command to confirm successful authentication with the provider.

Key rotation procedures should maintain overlap between old and new credentials to allow validation before full cutover. Generate a new API key in the provider dashboard, add it to your OpenClaw configuration while retaining the old key temporarily, validate connectivity with the new key, then remove the old key after confirming stable operation.

Model switching involves changing the provider or model variant used for agent reasoning. Changes should follow a controlled sequence to prevent service disruption. Never switch models during peak production usage windows when rollback would be disruptive.

The switching sequence begins with validating the new provider or model configuration in a test context. Run the model connectivity validation command with the new configuration to confirm authentication succeeds and the model responds with appropriate quality. Compare test outputs between current and target configurations.

After validation, configure the new model as a fallback alongside the current primary model. Run production workloads through the fallback to verify real-world performance before committing to the switch. Monitor error rates, response quality, and latency metrics during the fallback evaluation period.

When satisfied with the fallback evaluation, promote the new configuration to primary status. The previous primary becomes the new fallback for rapid rollback if issues emerge. Maintain fallback configuration until the new primary proves stable over at least one full production usage cycle.

Configure fallback providers to ensure continuity when the primary provider experiences outages or degradation. Fallback triggers include authentication failures, sustained high latency exceeding defined thresholds, and error rate increases above normal baseline levels.

The fallback configuration specifies which provider to route to when conditions trigger fallback activation. Choose a fallback provider with different failure characteristics than the primary to avoid common-mode failures where both providers fail simultaneously due to shared infrastructure dependencies.

Fallback activation is automatic when configured thresholds are exceeded, but you can also manually trigger fallback through the management interface or command line. Manual fallback is useful during known outage windows when you want to proactively shift traffic rather than wait for automatic detection.

After a fallback activation, the system periodically checks primary provider health and automatically returns to primary when it recovers. Configure the health check interval based on your tolerance for false positives versus detection speed.

Ollama enables running local language models without API costs or network dependencies. For deployments requiring complete data privacy or operating in network-isolated environments, local models through Ollama provide a viable alternative to cloud-hosted providers.

Ollama configuration requires installing the Ollama server locally, downloading desired model weights, and configuring OpenClaw to connect to the local Ollama endpoint. Model quality depends on available local compute resources and the specific model weights downloaded.

Local models introduce operational complexity in model weight management, version updates, and hardware scaling that cloud providers abstract away. Evaluate whether the privacy benefits justify the operational overhead for your specific use case.