Skip to main content

OpenClaw

Point OpenClaw at the gateway. Config alone is enough, so it works in a hardened container with nothing installed into it.

The route below is the common sandboxed case: OpenClaw in a locked-down container, inference on xAI Grok via Oracle Cloud Infrastructure Generative AI. Oracle credentials stay server-side on the gateway; the container holds only its own client key. You need a running gateway the container can reach, and console admin access.

Other model menus (Claude, GPT, direct xAI, aliases, mixed fleets), the Connect and plugin install paths, and troubleshooting live in the OpenClaw reference.

1
Store the Oracle credential on the gateway

Console Providers, or PUT /admin/provider-keys (field list). oracleRegion is required, no default; production uses IAM request signing (no API key).

2
Point routing at your providers

Console Routing: single for Grok-only, or dispatch by requested model for a multi-vendor menu.

3
Mount the config

Write the file below to ~/.openclaw/openclaw.json (or wherever OPENCLAW_CONFIG_PATH points). Read-only works.

4
Mint an agent key and pass it as an env var

Console Users → Agents → Add agent mints an ark_svc_… key attributed to the agent name (client keys). Set it as ANYRAY_CLIENT_KEY on the container; OpenClaw substitutes ${ANYRAY_CLIENT_KEY} at load, and no credential touches disk.

5
Allow the gateway through egress

OpenClaw also reaches other hosts (model-catalog refresh at boot, chat channels): allowlist by what OpenClaw needs, not this route alone.

Grok on Oracle OCI
{
  models: {
    providers: {
      anyray: {
        // Bare origin, no `/v1`: the anthropic-messages transport appends
        // `/v1/messages` itself.
        baseUrl: 'https://gateway.example.anyray.ai',
        // Without the explicit api kind OpenClaw serves the entry over
        // openai-completions: wrong dialect, wrong path.
        api: 'anthropic-messages',
        apiKey: '${ANYRAY_CLIENT_KEY}',
        headers: {
          'x-anyray-api-key': '${ANYRAY_CLIENT_KEY}',
          // OpenClaw drops its implicit beta headers on a custom host.
          'anthropic-beta': 'interleaved-thinking-2025-05-14',
          // Labels this traffic as OpenClaw. User and team come from the key,
          // not from here.
          'x-anyray-metadata': '{"tool":"openclaw"}',
        },
        // A provider OpenClaw does not ship must list its own models. OCI keeps
        // its dotted vendor prefix on the wire, so the id is `xai.grok-4.3`,
        // not `grok-4.3`.
        models: [
          {
            id: 'xai.grok-4.3',
            name: 'Grok 4.3 (Anyray)',
            reasoning: true,
            input: ['text'],
            contextWindow: 1000000,
            maxTokens: 128000,
          },
        ],
      },
    },
  },
  mcp: {
    servers: {
      // Lets the model read back anything the optimizer replaced with a
      // marker. Without it, trims are irreversible. Same key as above.
      anyray: {
        url: 'https://gateway.example.anyray.ai/mcp',
        transport: 'streamable-http',
        headers: { 'x-anyray-api-key': '${ANYRAY_CLIENT_KEY}' },
      },
    },
  },
  agents: {
    // Routing stays inert until the primary model resolves to a routed
    // provider.
    defaults: { model: { primary: 'anyray/xai.grok-4.3' } },
  },
}
Two fields decide whether this works

anthropic-messages takes a bare origin and appends /v1/messages; openai-completions takes a /v1-suffixed base and appends /chat/completions. Omitting api serves the entry over openai-completions against a bare origin: wrong dialect, a path the gateway 404s. Prefer anthropic-messages where the model supports it (carries cache_control and thinking blocks the OpenAI wire cannot).

Validate

openclaw config validate names any unresolved environment variable, so a missing key surfaces as a warning, not a runtime 401.

Adding more vendors​

Claude and Grok can share the one anthropic-messages entry above: the gateway serves /v1/messages natively for anthropic and translates for oracle, x-ai, nebius, tensormesh, litellm, truefoundry. openai has no /v1/messages, so GPT gets its own openai-completions entry. Ready-made configs for each shape: Config variants.

A multi-vendor menu does not route itself

The gateway never infers a provider from a model id. An entry spanning vendors with no x-anyray-provider pinned needs a conditional routing config keyed on params.model (routing examples). single mode sends every model to that one provider (upstream 404 for the rest), and several stored provider keys with no routing config fail every request with Either x-anyray-config or x-anyray-provider header is required.

The key​

ANYRAY_CLIENT_KEY is a gateway client key: mint an agent key (ark_svc_…) per deployment, never share one, and put it straight into the container's secret store. The key sets the attributed user and team; x-anyray-metadata carries tool only. Rotation is a new key plus a restart, since openclaw.json references ${ANYRAY_CLIENT_KEY}, not the value.

Close the retrieval loop​

The mcp block above is what makes optimization safe to run. When the optimizer replaces bulky content with an [anyray: … retrieve ctx_…] marker, the model reads the original back through that server. Drop the block and retrieval-dependent optimization is held back, while what still runs trims irreversibly.

openclaw mcp status anyray shows it connected with two tools (anyray_retrieve, anyray_recall) after one daemon restart. How the loop works in general: the retrieval reference.

Machines running anyray-connect get a local mcp.servers.anyray written for them, so they need no block here.