how to connect ollama model in existing config openclaw.json | Friends of the Crustacean 🦞🤝 | Page 1

untold grail Apr 21, 2026, 4:53 PM

#

how to connect ollama model in existing config openclaw.json

runic marshBOT Apr 21, 2026, 4:53 PM

#

glad meteorBOT Apr 21, 2026, 4:53 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

runic marshBOT Apr 21, 2026, 4:53 PM

#

gentle sableBOT Apr 21, 2026, 4:54 PM

#

If you want to wire Ollama into an existing ~/.openclaw/openclaw.json, this is the safe pattern.

First, check your version:

openclaw --version

For local Ollama on the same machine, the easiest setup is:

ollama pull gemma4
export OLLAMA_API_KEY="ollama-local"
openclaw models set ollama/gemma4

And in ~/.openclaw/openclaw.json:

#

{
  agents: {
    defaults: {
      model: {
        primary: "ollama/gemma4"
      }
    }
  }
}

If you want an explicit Ollama provider block in config, use the native Ollama API, not /v1:

#

  models: {
    providers: {
      ollama: {
        baseUrl: "http://127.0.0.1:11434",
        apiKey: "ollama-local",
        api: "ollama",
        models: [
          {
            id: "gemma4",
            name: "gemma4",
            input: ["text"],
            reasoning: false,
            cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
            contextWindow: 8192,
            maxTokens: 81920

#

          }
        ]
      }
    }
  },
  agents: {
    defaults: {
      model: {
        primary: "ollama/gemma4"
      }
    }
  }
}

Two important gotchas:

#

Do not use http://host:11434/v1, use http://host:11434
If you already have agents.defaults.models as an allowlist, you also need to add ollama/gemma4 there, or OpenClaw will reject it as “not allowed”

Docs:

If you paste your current openclaw.json, I can tell you the exact block to add without breaking the rest.

untold grail Apr 21, 2026, 5:00 PM

#

  "agents": {
    "defaults": {
      "compaction": {
        "mode": "safeguard",
        "reserveTokensFloor": 1000
      },
      "workspace": "/root/.openclaw/workspace",
      "model": {
        "primary": "ollama/vayne:latest"
      },```

gentle sableBOT Apr 21, 2026, 5:01 PM

#

Yep, that part is in the right place:

agents.defaults.model.primary = "ollama/vayne:latest"

But that line alone is not enough. You also need OpenClaw to see an Ollama provider.

If Ollama is local on the same machine

This is the simplest path. Keep your current model line, then make sure:

ollama list
export OLLAMA_API_KEY="ollama-local"

If ollama list shows vayne:latest, OpenClaw can usually use it without an explicit provider block.

#

If you want it fully in `openclaw.json`

Add this too:

{
  agents: {
    defaults: {
      model: {
        primary: "ollama/vayne:latest"
      }
    }
  },
  models: {
    providers: {
      ollama: {
        baseUrl: "http://127.0.0.1:11434",

#

        apiKey: "ollama-local",
        api: "ollama",
        models: [
          {
            id: "vayne:latest",
            name: "vayne:latest",
            input: ["text"],
            reasoning: false,
            cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
            contextWindow: 8192,
            maxTokens: 81920
          }
        ]
      }
    }

#

}
}

Important gotcha

Use:

http://127.0.0.1:11434

not

http://127.0.0.1:11434/v1

#

The /v1 OpenAI-compatible path is the wrong one for Ollama in OpenClaw.

If it’s still not working, send these two outputs and I can tell you exactly what’s missing:

openclaw --version
openclaw models status

Docs: https://docs.openclaw.ai/providers/ollama

untold grail Apr 21, 2026, 5:03 PM

#

    "mode": "merge",
    "providers": {
      "ollama": {
        "baseUrl": "http://127.0.0.1:8000/v1",
        "api": "openai-completions",
        "apiKey": "noapikeyfree",
        "models": [
          {
            "id": "Lliama-3.1-70B-instruct",
            "name": "Local Llama 3.2 3B",
            "contextWindow": 4096,
            "maxTokens": 2048,
            "input": [
              "text"
            ],
            "cost": {
              "input": 0,
              "output": 0,
              "cacheRead": 0,
              "cacheWrite": 0
            },
            "reasoning": false
          }```

gentle sableBOT Apr 21, 2026, 5:04 PM

#

Ah, I see the issue.

What you pasted is not native Ollama mode right now, it’s an OpenAI-compatible /v1 backend:

baseUrl: "http://127.0.0.1:8000/v1",
api: "openai-completions"

So there are 2 different cases:

1) If this is actually Ollama

Use Ollama’s native API instead:

#

  models: {
    mode: "merge",
    providers: {
      ollama: {
        baseUrl: "http://127.0.0.1:11434",
        apiKey: "ollama-local",
        api: "ollama"
      }
    }
  },
  agents: {
    defaults: {
      model: {
        primary: "ollama/vayne:latest"
      }

#

    }
  }
}

Important:

no /v1
api should be "ollama", not "openai-completions"

2) If `127.0.0.1:8000/v1` is vLLM / LM Studio / some proxy

Then your config is OpenAI-compatible local server, not Ollama. In that case I’d do this instead:

{
  models: {

#

    mode: "merge",
    providers: {
      local: {
        baseUrl: "http://127.0.0.1:8000/v1",
        apiKey: "noapikeyfree",
        api: "openai-completions",
        models: [
          {
            id: "Lliama-3.1-70B-instruct",
            name: "Local Llama",
            contextWindow: 4096,
            maxTokens: 2048,
            input: ["text"],
            cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
            reasoning: false

#

          }
        ]
      }
    }
  },
  agents: {
    defaults: {
      model: {
        primary: "local/Lliama-3.1-70B-instruct"
      }
    }
  }
}

One more likely problem

#

Your model entry has a suspicious mismatch:

id: Lliama-3.1-70B-instruct
name: Local Llama 3.2 3B

That looks inconsistent, and Lliama may be a typo. OpenClaw uses the id. It has to match the exact model ID your server exposes.

If you send either:

ollama list

or

#

openclaw models status

I can tell you which of the two setups you actually want.

Docs:

untold grail Apr 21, 2026, 5:34 PM

#

my models:
NAME ID SIZE MODIFIED
vayne:latest 5274c16b1cd9 2.0 GB 12 minutes ago
vayne-latest:latest 5274c16b1cd9 2.0 GB 33 minutes ago

"⚠️ Something went wrong while processing your request. Please try again, or use /new to start a fresh session."

  "agents": {
    "defaults": {
      "compaction": {
        "mode": "safeguard",
        "reserveTokensFloor": 1000
      },
      "workspace": "/root/.openclaw/workspace",
      "model": {
        "primary": "ollama/vayne:latest"
      },
      "models": {
        "ollama/vayne:latest": {},
        "/root/Llama-3.2-3B-Instruct-Q4_K_M.gguf": {},
        "google/gemini-1.5-flash-latest": {}
      }
    }
  },


 "models": {
    "mode": "merge",
    "providers": {
      "ollama": {
        "baseUrl": "http://127.0.0.1:11434",
        "api": "ollama",
        "apiKey": "ollama-local",
        "models": [
          {
            "id": "vayne:latest",
            "name": "vayne latest",
            "contextWindow": 4096,
            "maxTokens": 2048,
            "input": [
              "text"
            ],
            "cost": {
              "input": 0,
              "output": 0,
              "cacheRead": 0,
              "cacheWrite": 0
            },
            "reasoning": false
          }```

gentle sableBOT Apr 21, 2026, 5:36 PM

#

Your Ollama wiring looks basically correct now. I don’t think the connection config is the main problem anymore.

What I’d fix first:

In agents.defaults.models, remove this entry:

"/root/Llama-3.2-3B-Instruct-Q4_K_M.gguf": {}

That section should contain model refs like provider/model, not file paths.

So make it more like:

"models": {
  "ollama/vayne:latest": {},

#

  "google/gemini-1.5-flash-latest": {}
}

Your Ollama model is only 2.0 GB, which is very small for OpenClaw.
That often works for tiny prompts, but fails on full agent/tool prompts with the generic:

“Something went wrong while processing your request”

So at this point, I’m more suspicious of the model/runtime than the JSON.

Best next test

Run these:

#

openclaw --version
openclaw models status
openclaw infer model run --model ollama/vayne:latest --prompt "Reply with exactly: ok" --json
openclaw logs --follow

How to read the result

If infer model run fails, the issue is the local model/backend
If infer model run works but Discord chat still fails, the session is probably wedged or the model is collapsing on agent/tool prompts

In that case:

try /new
keep the config as native Ollama
consider a larger Ollama model, because 2 GB is pretty likely to struggle here

Also, since you’re on the default Ollama host (127.0.0.1:11434), you can simplify things by letting Ollama auto-discover models instead of manually listing them.

#

Docs:

If you paste the output of openclaw models status or the first error lines from openclaw logs --follow, I can probably pinpoint it fast.

untold grail Apr 21, 2026, 5:43 PM

#

"LLM request failed: provider rejected the request schema or tool payload."

gentle sableBOT Apr 21, 2026, 5:44 PM

#

That error is the giveaway.

It means the model/backend is rejecting OpenClaw’s tool schema, not that Ollama is unreachable.

For your vayne:latest model, try disabling tools in the model entry:

{
  "models": {
    "mode": "merge",
    "providers": {
      "ollama": {
        "baseUrl": "http://127.0.0.1:11434",
        "api": "ollama",
        "apiKey": "ollama-local",
        "models": [

#

          {
            "id": "vayne:latest",
            "name": "vayne latest",
            "contextWindow": 4096,
            "maxTokens": 2048,
            "input": ["text"],
            "cost": {
              "input": 0,
              "output": 0,
              "cacheRead": 0,
              "cacheWrite": 0
            },
            "reasoning": false,
            "compat": {
              "supportsTools": false

#

Also clean this up in agents.defaults.models:

"/root/Llama-3.2-3B-Instruct-Q4_K_M.gguf": {}

That should not be there. Keep only valid refs like:

#

"ollama/vayne:latest": {}

Then restart:

openclaw gateway restart

and try a fresh session:

/new

Important tradeoff:

#

supportsTools: false should stop the schema rejection
but that model won’t be able to use tools
if you want full OpenClaw agent behavior, you’ll probably need a stronger model than this 2 GB one

Docs:

If you want, paste the updated model block and I’ll sanity-check it before you restart.

untold grail Apr 21, 2026, 8:46 PM

#

how to connect groq in openclaw.json instead of ollama

gentle sableBOT Apr 21, 2026, 8:46 PM

#

Yep, for Groq you usually do not add a custom models.providers.groq block.

Just do these 2 things in ~/.openclaw/openclaw.json:

add your API key
change the default model from ollama/... to groq/...

Example:

{
  env: {
    GROQ_API_KEY: "gsk_..."
  },

  agents: {

#

    defaults: {
      model: {
        primary: "groq/llama-3.3-70b-versatile"
      },
      models: {
        "groq/llama-3.3-70b-versatile": {}
      }
    }
  }
}

If you’re replacing Ollama entirely

You can remove the old custom Ollama block:

#

models.providers.ollama

and also remove old allowlist entries like:

"ollama/vayne:latest": {}

Important

If your gateway runs as a daemon, put the key where the daemon can see it, for example:

~/.openclaw/.env, or
env in openclaw.json

To see current Groq models

#

Use:

openclaw models list | grep groq

Then restart:

openclaw gateway restart

Docs:

If you want, paste your current full model section and I’ll rewrite the exact Groq version for you.

untold grail Apr 21, 2026, 8:47 PM

#

  "agents": {
    "defaults": {
        "llm": { "idleTimeoutSeconds": 0 },
      "compaction": {
        "mode": "safeguard",
        "reserveTokensFloor": 1000
      },
      "workspace": "/root/.openclaw/workspace",
      "model": {
        "primary": "ollama/dolphin-llama3:8b-v2.9-q2_K"
      },
      "models": {
        "ollama/vayne:latest": {},
        "google/gemini-1.5-flash-latest": {},
        "ollama/dolphin-llama3:8b-v2.9-q2_K": {}
      }
    }
  },


 "models": {
    "mode": "merge",
    "providers": {
      "ollama": {
        "baseUrl": "http://127.0.0.1:11434",
        "api": "ollama",
        "apiKey": "ollama-local",
        "models": [
          {
            "id": "dolphin-llama3:8b-v2.9-q2_K",
            "name": "vayne latest",
            "contextWindow": 16384,
            "maxTokens": 2048,
            "input": [
              "text"
            ],
            "cost": {
              "input": 0,
              "output": 0,
              "cacheRead": 0,
              "cacheWrite": 0
            },
            "reasoning": false,
            "compat": { "supportsTools": false }
          }```

gentle sableBOT Apr 21, 2026, 8:48 PM

#

If you’re trying to make this Ollama config work, it looks mostly okay now 👍

A few notes:

What looks right

primary matches the provider/model ref:

"primary": "ollama/dolphin-llama3:8b-v2.9-q2_K"

native Ollama URL is correct:

"baseUrl": "http://127.0.0.1:11434",
"api": "ollama"

compat.supportsTools: false is the right workaround for schema/tool-payload failures

What I’d clean up

#

Remove the stale model if you’re not using it anymore:
```
"ollama/vayne:latest": {}
```
This name is misleading:
```
"name": "vayne latest"
```
It won’t break selection, but I’d rename it to something matching the actual model, like:
```
"name": "dolphin-llama3 8b"
```

Important expectation

Because you set:

#

"compat": { "supportsTools": false }

this model should work better for plain chat, but it will not be able to use tools.

Next step

After saving, do:

openclaw gateway restart

then start a fresh session:

#

/new

One clarification

This is still an Ollama config, not a Groq config.
So if your goal is Groq instead of Ollama, this is the wrong provider block.

If you want, I can rewrite this exact snippet into a clean Groq version next.

untold grail Apr 21, 2026, 8:49 PM

#

yes please

gentle sableBOT Apr 21, 2026, 8:49 PM

#

Yep, here’s the clean Groq version of your config.

You can remove the whole custom Ollama provider block and use this instead:

{
  env: {
    GROQ_API_KEY: "gsk_..."
  },

  agents: {
    defaults: {
      llm: { idleTimeoutSeconds: 0 },
      compaction: {
        mode: "safeguard",
        reserveTokensFloor: 1000

#

      },
      workspace: "/root/.openclaw/workspace",
      model: {
        primary: "groq/llama-3.3-70b-versatile",
        fallbacks: ["google/gemini-1.5-flash-latest"]
      },
      models: {
        "groq/llama-3.3-70b-versatile": {},
        "google/gemini-1.5-flash-latest": {}
      }
    }
  }
}

What to remove

#

Delete the old Ollama stuff, especially:

models.providers.ollama

and old allowlist entries like:

"ollama/vayne:latest": {}
"ollama/dolphin-llama3:8b-v2.9-q2_K": {}

Notes

Groq is built in, so you don’t need a custom models.providers.groq block
if your gateway runs as a daemon, putting GROQ_API_KEY in ~/.openclaw/.env is often cleaner than inline config
Groq model availability changes, so if that exact model isn’t available, check:

#

openclaw models list | grep groq

Then restart:

openclaw gateway restart

and start fresh:

/new

Docs: https://docs.openclaw.ai/providers/groq

#

Glad that helped! 🎉
If this fixes it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

untold grail Apr 21, 2026, 9:01 PM

#

    "mode": "merge",
    "providers": {
      "openai-compatible": {
        "baseUrl": "https://api.groq.com/openai/v1",
        "api": "openai-completions",
        "apiKey": "...",
        "models": [
          {
            "id": "llama-3.1-70b-versatile",
            "name": "vayne latest",
            "contextWindow": 16384,
            "maxTokens": 2048,
            "input": [
              "text"
            ],
            "cost": {
              "input": 0,
              "output": 0,
              "cacheRead": 0,
              "cacheWrite": 0
            },
            "reasoning": false,

gentle sableBOT Apr 21, 2026, 9:02 PM

#

That can work, but I wouldn’t do Groq that way unless you really want a generic custom provider.

The important catch

If your provider id is:

"openai-compatible"

then your model ref is not groq/... anymore, it becomes:

"openai-compatible/llama-3.1-70b-versatile"

So your agents.defaults.model.primary would need to match that exact prefix.

#

But the recommended Groq setup is simpler

For Groq, use the built-in provider instead of a custom OpenAI-compatible block:

{
  env: {
    GROQ_API_KEY: "gsk_..."
  },
  agents: {
    defaults: {
      model: {
        primary: "groq/llama-3.3-70b-versatile"
      },
      models: {
        "groq/llama-3.3-70b-versatile": {}
      }

#

    }
  }
}

Why this is better

less config
correct provider prefix (groq/...)
you don’t have to hand-maintain baseUrl, api, contextWindow, etc.
fewer ways to misconfigure it

If you insist on the custom provider

Then make it consistent:

#

{
  models: {
    mode: "merge",
    providers: {
      "openai-compatible": {
        baseUrl: "https://api.groq.com/openai/v1",
        api: "openai-completions",
        apiKey: "...",
        models: [
          {
            id: "llama-3.1-70b-versatile",
            name: "Groq Llama",
            contextWindow: 16384,
            maxTokens: 2048,
            input: ["text"],

#

            cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
            reasoning: false
          }
        ]
      }
    }
  },
  agents: {
    defaults: {
      model: {
        primary: "openai-compatible/llama-3.1-70b-versatile"
      },
      models: {
        "openai-compatible/llama-3.1-70b-versatile": {}
      }

#

    }
  }
}

Also, I’d rename "name": "vayne latest" since that’s just confusing here.

So, short version: yes, your custom block can work, but built-in groq is the cleaner and safer config.

untold grail Apr 21, 2026, 9:11 PM

#

  --openai-compatible-base-url "https://api.groq.com/openai/v1" \
  --openai-compatible-api-key "..." \
  --openai-compatible-model-id "llama-3.1-70b-versatile"
error: unknown option '--provider'```

gentle sableBOT Apr 21, 2026, 9:13 PM

#

Yep, that error makes sense.

--provider is not a valid top-level flag for the command you ran, and those --openai-compatible-* flags are not OpenClaw CLI flags in 2026.4.9.

So for Groq, don’t do it as a generic openai-compatible CLI setup.

Use one of these instead

Option 1, easiest: config file

Put this in ~/.openclaw/openclaw.json:

{
  env: {
    GROQ_API_KEY: "gsk_..."
  },

#

  agents: {
    defaults: {
      model: {
        primary: "groq/llama-3.3-70b-versatile"
      },
      models: {
        "groq/llama-3.3-70b-versatile": {}
      }
    }
  }
}

Then:

#

openclaw gateway restart

Option 2, CLI auth + model set

Use the actual auth subcommand:

openclaw models auth paste-token --provider groq
openclaw models set groq/llama-3.3-70b-versatile
openclaw gateway restart

If you want interactive setup instead:

#

openclaw configure --section model

Important

If you use the built-in groq provider, you do not need:

models.providers.openai-compatible
--openai-compatible-base-url
--openai-compatible-api-key
--openai-compatible-model-id

Those are the wrong path for this.

Docs:

#

https://docs.openclaw.ai/cli/configure

If you want, I can give you the smallest possible Groq-only openclaw.json next.

untold grail Apr 21, 2026, 9:58 PM

#

⚠️ Something went wrong while processing your request. Please try again, or use /new to start a fresh session.

  2   "env": {
  3     "GROQ_API_KEY": "..."
  4   },
  5   "agents": {
  6     "defaults": {
  7       "llm": {
  8         "idleTimeoutSeconds": 0
  9       },
 10       "compaction": {
 11         "mode": "safeguard",
 12         "reserveTokensFloor": 20000
 13       },
 14       "workspace": "/root/.openclaw/workspace",
 15       "model": {
 16         "primary": "qwen/qwen3-32b"
 17       },
 18       "models": {
 19         "google/gemini-1.5-flash-latest": {},
 20         "qwen/qwen3-32b": {}
 21       }
 22     }
 23   },```

gentle sableBOT Apr 21, 2026, 9:58 PM

#

I see the mismatch now.

You’re mixing:

Groq auth
```
"GROQ_API_KEY": "..."
```

with

a Qwen provider model ref
```
"primary": "qwen/qwen3-32b"
```

So OpenClaw is not actually using Groq there.

Fix

#

If you want Groq, both places need to use the groq/... prefix:

{
  "env": {
    "GROQ_API_KEY": "..."
  },
  "agents": {
    "defaults": {
      "llm": {
        "idleTimeoutSeconds": 0
      },
      "compaction": {
        "mode": "safeguard",
        "reserveTokensFloor": 20000
      },

#

      "workspace": "/root/.openclaw/workspace",
      "model": {
        "primary": "groq/llama-3.3-70b-versatile"
      },
      "models": {
        "google/gemini-1.5-flash-latest": {},
        "groq/llama-3.3-70b-versatile": {}
      }
    }
  }
}

Key point

These two must match the same provider:

#

env.GROQ_API_KEY
agents.defaults.model.primary
agents.defaults.models

Then do

openclaw gateway restart

and in chat:

/new

If you want Qwen instead

Then keep qwen/..., but you’d need Qwen provider auth, not GROQ_API_KEY.

#

If you want the safest next step, run:

openclaw models list | grep groq
openclaw models status

and paste the Groq lines here. That’ll confirm the exact model ref your install sees.

untold grail Apr 21, 2026, 10:00 PM

#

but at groq website the model qwen is written like this qwen/qwen3-32b

gentle sableBOT Apr 21, 2026, 10:00 PM

#

Yep, exactly, and that’s the subtle part.

On Groq’s site, qwen/qwen3-32b is the model ID.

In OpenClaw, model refs are:

provider/model-id

So if the provider is Groq and the model ID is qwen/qwen3-32b, the full OpenClaw ref becomes:

groq/qwen/qwen3-32b

So your config should look like this

#

{
  "env": {
    "GROQ_API_KEY": "..."
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "groq/qwen/qwen3-32b"
      },
      "models": {
        "groq/qwen/qwen3-32b": {},
        "google/gemini-1.5-flash-latest": {}
      }
    }
  }

#

Why `qwen/qwen3-32b` alone failed

Because OpenClaw reads that as:

provider = qwen
model = qwen3-32b

which is not the same as:

provider = groq
model = qwen/qwen3-32b

That extra groq/ prefix matters.

#

After changing it:

openclaw gateway restart

then:

/new

I’m glad you caught that, that’s a super easy one to trip over. If this works, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

untold grail Apr 21, 2026, 10:19 PM

#

how to connect deepseek api

gentle sableBOT Apr 21, 2026, 10:20 PM

#

For DeepSeek, the clean setup is similar to Groq.

Easiest

openclaw onboard --auth-choice deepseek-api-key

That will prompt for the key and usually set:

deepseek/deepseek-chat

as the default model.

If you want to edit `openclaw.json` directly

Use the built-in provider, no custom models.providers.deepseek block needed:

#

{
  "env": {
    "DEEPSEEK_API_KEY": "sk-..."
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "deepseek/deepseek-chat"
      },
      "models": {
        "deepseek/deepseek-chat": {}
      }
    }
  }
}

#

If you want the reasoning model instead:

"primary": "deepseek/deepseek-reasoner"

Then restart

openclaw gateway restart

and in chat:

/new

#

Important

If your gateway runs as a daemon, make sure DEEPSEEK_API_KEY is visible to it, for example in:

~/.openclaw/.env, or
the env block in openclaw.json

Docs:

https://docs.openclaw.ai/providers/deepseek

If you want, I can rewrite your current config into a DeepSeek version the same way I did for Groq.

untold grail Apr 21, 2026, 10:28 PM

#

how configure contextwindow with that

gentle sableBOT Apr 21, 2026, 10:29 PM

#

Yep, but with DeepSeek I’d split it like this:

contextWindow = the model’s native max context metadata
contextTokens = the effective cap you want OpenClaw to use

For most setups, you don’t need to set either because the built-in DeepSeek catalog already knows them.

If you want to cap it manually

Use a custom override like this:

{
  "env": {
    "DEEPSEEK_API_KEY": "sk-..."
  },
  "agents": {

#

    "defaults": {
      "model": {
        "primary": "deepseek/deepseek-chat"
      },
      "models": {
        "deepseek/deepseek-chat": {}
      }
    }
  },
  "models": {
    "mode": "merge",
    "providers": {
      "deepseek": {
        "baseUrl": "https://api.deepseek.com",
        "apiKey": "${DEEPSEEK_API_KEY}",

#

        "api": "openai-completions",
        "models": [
          {
            "id": "deepseek-chat",
            "name": "DeepSeek Chat",
            "input": ["text"],
            "reasoning": false,
            "cost": {
              "input": 0,
              "output": 0,
              "cacheRead": 0,
              "cacheWrite": 0
            },
            "contextWindow": 131072,
            "contextTokens": 65536,

#

            "maxTokens": 8192
          }
        ]
      }
    }
  }
}

What that does

contextWindow: 131072 = model metadata
contextTokens: 65536 = tell OpenClaw to stay under 64k
maxTokens: 8192 = output cap

Important

If your goal is just “don’t use the full context”, set contextTokens, not only contextWindow.

#how to connect ollama model in existing config openclaw.json

If Ollama is local on the same machine

If you want it fully in openclaw.json

Important gotcha

1) If this is actually Ollama

2) If 127.0.0.1:8000/v1 is vLLM / LM Studio / some proxy

One more likely problem

Best next test

How to read the result

If you’re replacing Ollama entirely

Important

To see current Groq models

What looks right

What I’d clean up

Important expectation

Next step

One clarification

What to remove

Notes

The important catch

But the recommended Groq setup is simpler

Why this is better

If you insist on the custom provider

Use one of these instead

Option 1, easiest: config file

Option 2, CLI auth + model set

Important

Fix

Key point

Then do

If you want Qwen instead

So your config should look like this

Why qwen/qwen3-32b alone failed

Easiest

If you want to edit openclaw.json directly

Then restart

Important

If you want to cap it manually

What that does

Important

If you want it fully in `openclaw.json`

2) If `127.0.0.1:8000/v1` is vLLM / LM Studio / some proxy

Why `qwen/qwen3-32b` alone failed

If you want to edit `openclaw.json` directly