Fireworks Provider Setup: Auth and Model Selection

Fireworks provides open-weight and routed models via an API that is compatible with OpenAI. To use the current Fire Pass GLM router, two Kimi models that come pre-cataloged, plus any Fireworks model or router id at runtime, install the official Fireworks provider plugin.

Getting started

Install the plugin

openclaw plugins install @openclaw/fireworks-provider

Set the Fireworks API key

openclaw onboard --auth-choice fireworks-api-key

openclaw onboard --non-interactive --accept-risk --skip-health \
  --auth-choice fireworks-api-key \
  --fireworks-api-key "$FIREWORKS_API_KEY"

export FIREWORKS_API_KEY=fw-...

During onboarding the key is stored against the fireworks provider inside your auth profiles, and Fireworks' current Fire Pass GLM 5.2 Fast router becomes the default model.

Verify the model is available

openclaw models list --provider fireworks

The output should list GLM 5.2 Fast, Kimi K2.6, and Kimi K2.6 Fast. When FIREWORKS_API_KEY cannot be resolved, openclaw models status --json flags the missing credential under auth.unusableProfiles.

Non-interactive setup

When installing from a script or in CI, supply every value on the command line:

openclaw onboard --non-interactive \
  --mode local \
  --auth-choice fireworks-api-key \
  --fireworks-api-key "$FIREWORKS_API_KEY" \
  --skip-health \
  --accept-risk

Since --mode falls back to local, this run matches the Direct flag command shown earlier. Execute it on the Gateway host: onboarding a remote client (--mode remote) only sets up the local client connection, and it does not configure provider credentials on the server.

Built-in catalog

Setup records connection settings and aliases, but it does not copy generated catalog rows into your config. Catalog seeding stays on as long as models.mode: "replace" is given explicitly; any custom model rows you added remain untouched.

Note

OpenClaw pins every Fireworks Kimi model to thinking: off, because on Fireworks Kimi may leak chain-of-thought into the visible reply unless the request turns thinking off explicitly. If you route that same model straight through Moonshot, Kimi's reasoning output is kept. Switching between providers is covered in thinking modes.

Custom Fireworks model ids

Any Fireworks model or router id works at runtime in OpenClaw. Take the exact id Fireworks shows and add the fireworks/ prefix. Dynamic resolution relies on the Fire Pass template's OpenAI-compatible API and treats GLM ids as text-only, while other dynamic ids declare text + image input. Whenever an id matches the Kimi pattern, thinking gets disabled automatically. To get a model with different capabilities, define a custom model entry listing the input types it supports.

{
  agents: {
    defaults: {
      model: {
        primary: "fireworks/accounts/fireworks/models/<your-model-id>",
      },
    },
  },
}

How model id prefixing works

In OpenClaw, each Fireworks model ref begins with fireworks/ and then the exact id or router path taken from the Fireworks platform. For example:

• Router model: fireworks/accounts/fireworks/routers/kimi-k2p6-turbo
• Direct model: fireworks/accounts/fireworks/models/<model-name>

When building the API request, OpenClaw removes the fireworks/ prefix and passes what remains to the Fireworks endpoint as the OpenAI-compatible model field.

Why thinking is forced off for Kimi

Because Fireworks serves Kimi with no separate reasoning channel, chain-of-thought may appear in the visible content stream. On each Fireworks Kimi request, OpenClaw sends thinking: { type: "disabled" } and removes reasoning, reasoning_effort, and reasoningEffort from the payload (extensions/fireworks/stream.ts). The provider policy (extensions/fireworks/thinking-policy.ts) advertises only the off thinking level for Kimi model ids, keeping manual /think switches and provider-policy surfaces consistent with the runtime contract.

To run Kimi reasoning across the whole pipeline, set up the Moonshot provider and send that same model through it.

Environment availability for the daemon

When the Gateway is deployed as a managed service (launchd, systemd, Docker), the Fireworks key has to be readable by that process, not merely by the shell you are typing in.

Warning

Exporting a key in an interactive shell alone does nothing for a launchd or systemd daemon, unless that environment is imported into the daemon as well. Put the key in ~/.openclaw/.env or through env.shellEnv so the gateway process can read it.

OpenClaw reads ~/.openclaw/.env at config load time, which means keys kept there are available to managed gateway services on any platform. Once you rotate the key, restart the gateway (or run openclaw doctor --fix again).

Related

• Model providers, Picking providers, model refs, and how failover works.

• Thinking modes, /think levels, provider policies, and routing models that support reasoning.

• Moonshot, Run Kimi with native thinking output via Moonshot's own API.

• Troubleshooting, General troubleshooting and FAQ.