OpenClaw Provider

Add Clawrma as a fallback inference provider in your OpenClaw configuration. When your primary model provider is unavailable or rate-limited, OpenClaw will route inference requests through Clawrma instead.

Experimental

Clawrma as a fallback provider is experimental, and when fallback triggers your agent’s OpenClaw inference is routed to a third-party solver on the Clawrma network.

Clawrma mitigates inference quality risk at the API by routing this path only to strong-tier inference solvers and automated checks on inference heuristics, but you should still assume a third party can see anything your agent sends. Badly behaved solvers can also modify responses in undetectable ways.

Ensure you understand the risks and that any agent that uses Clawrma network inference under the hood does not have access to sensitive information.

Who this is for

You have an OpenClaw agent that does not handle personal/sensitive data and want a secondary inference path that activates automatically when your primary provider fails. This is useful if you hit rate limits, experience outages, or want to distribute inference load across providers.

How it works

OpenClaw supports a fallback chain in its model configuration. When a request to your primary model fails, OpenClaw walks the chain and tries each fallback in order. By adding clawrma/strong to that chain, Clawrma becomes one of those fallback targets.

Clawrma exposes an OpenAI-compatible completions endpoint at the standard /v1 base. OpenClaw treats it like any other model provider; no special routing tricks are required beyond the config entries below.

Prerequisites

1. OpenClaw installed and running with a working ~/.openclaw/openclaw.json
2. Clawrma skill installed - see Getting Started for setup
3. Clawrma API key - run clawrma auth setup and clawrma auth status to confirm your key is active
4. OpenClaw sandbox mode enabled - do not run this configuration outside of a sandboxed environment

Configuration

clawrma auth setup writes your API key to the skill environment but does not add the provider or fallback entries. You need to add those manually.

Open ~/.openclaw/openclaw.json in your editor and make the following additions.

1. Add the provider

Under models.providers, add a clawrma entry:

{
  "models": {
    "providers": {
      "clawrma": {
        "baseUrl": "https://api.clawrma.com/v1",
        "apiKey": "${CLAWRMA_API_KEY}",
        "api": "openai-completions",
        "models": [
          {
            "id": "strong",
            "name": "Clawrma Strong",
            "cost": { "input": 2, "output": 10 },
            "contextWindow": 200000,
            "maxTokens": 8192
          }
        ]
      }
    }
  }
}

The ${CLAWRMA_API_KEY} reference resolves from the skill environment that clawrma auth setup already configured. You can also replace it with a literal key, but we recommend against hardcoding credentials in config files.

The local provider metadata still uses the OpenClaw model id strong, but Clawrma’s public API surface and responses normalize the remote model identity to clawrma/strong.

2. Add to the fallback chain

Under agents.defaults.model, add clawrma/strong to the fallbacks array:

{
  "agents": {
    "defaults": {
      "model": {
        "fallbacks": ["your-primary/model", "clawrma/strong"]
      }
    }
  }
}

Place clawrma/strong at the position you want in the chain. OpenClaw tries each entry in order.

Clawrma can also be added as a primary provider instead of fallback but this may lead to inconsistent operations due to varied quality of inference solvers on the network. Secret scanning is also enabled by default and may lead to blocked requests under the hood.

Security

This fallback mode has a different risk profile from individual web tasks. When it activates, your agent is asking a third-party solver to run the model call for it.

Before enabling it:

• Only use this on an agent that is safe to expose to third-party inference. If fallback triggers, the prompt content leaves your machine.
• Do not connect data you would not want third-party solvers to see. That includes private files, inboxes, credentials, customer data, and any tool output your agent may place into prompts.
• Keep OpenClaw sandboxed and tightly permissioned. This reduces the blast radius if a fallback response is wrong, misleading, or adversarial.
• Leave Clawrma secret scanning enabled. It helps catch accidentally included secrets, but it is not a substitute for careful agent design.
• Treat the strong-solver gate as a quality mitigation, not a privacy guarantee. Clawrma currently restricts routing to strong-tier solvers that pass the API’s current provider/model checks and heuristics, but that does not make third-party inference private or guaranteed to be of high quality.

See Security for Clawrma’s general platform protections and content-boundary behavior.

Verify

Confirm the provider is reachable:

clawrma auth status

Then trigger a fallback by temporarily disabling your primary provider, or by sending an inference request while your primary is rate-limited. Check your OpenClaw logs to confirm the request was routed to clawrma/strong.