Agent creation model | Friends of the Crustacean 🦞🤝 | Page 1

wide condor Feb 21, 2026, 2:34 PM

#

When creating agents, do you have to reenter the provide API key each time or can we reuse a global one if we want to set the new agent model.
Is there tools to set existing agent default model and global available model without editing the json config.
What to do if a session is stuck with an invalid model, webui won't let you delete a session anymore.
/model in tui list all possible models but only the configured one can be used and it doesn't tell which, Telegram /model has the right behaviour.
is the new 1 Million token context only availble for Anthropic models or can we enable it for Gemini and Grok?

Unreleated: is it possible to share media in webchat?
Are avatars only used in Webchat? avatars is a directory, is there a possibility of using multiple avatars.
Why no / commands in webchat?
Why is development so focused on Apple only tools?

spare horizonBOT Feb 21, 2026, 3:01 PM

#

1) New agents + API keys: do you have to re-enter them?

It depends where your credentials live:

If you use env vars / ~/.openclaw/.env → you can reuse them “globally” for all agents (no re-entry per agent).
Docs: https://docs.openclaw.ai/help/environment and FAQ https://docs.openclaw.ai/help/faq
If you use auth profiles (recommended) → auth is per-agent. New agents can start with an empty auth store:
~/.openclaw/agents/<agentId>/agent/auth-profiles.json
Fix is either:
- configure auth during openclaw agents add … / onboarding, or
- copy auth-profiles.json from your main agent into the new agent’s agentDir.
  (This is explicitly called out in the FAQ.)
  Source: https://docs.openclaw.ai/help/faq (section “No API key found… after adding a new agent”)

2) Change default model / allowed models without editing JSON by hand

You’ve got two good CLI options:

#

Model helper commands (nice UX):
- openclaw models status
- openclaw models set <provider/model>
- openclaw models list [--all]
- aliases/fallbacks helpers also exist
  Docs: https://docs.openclaw.ai/cli/models
Direct config edits via CLI (no manual file editing):
- openclaw config get …
- openclaw config set …
- openclaw config unset …
  Docs: https://docs.openclaw.ai/cli/config

Key concept: if agents.defaults.models is set, it becomes the allowlist. Anything not in there will fail with “Model … is not allowed”.

3) Session stuck on an invalid model; Web UI won’t delete it

Try these in order:

#

In that chat/session, send /new (or /reset) as a standalone message.
This is Gateway-handled (command), so it usually works even when the model config is busted.
Docs: https://docs.openclaw.ai/help/faq (Sessions section) + https://docs.openclaw.ai/tools/slash-commands
If you need forensic detail: run openclaw models status and check what model/auth it’s actually resolving.
Last resort (manual, destructive): delete/reset the agent’s session store on disk (the docs mention nuking the sessions dir for an agent). This will wipe history for that agent, so only do it if you’re OK losing transcripts.

If you paste:

openclaw --version
openclaw models status
…I can tell you the least-painful fix for your exact state.

4) “TUI shows tons of models but only one works”

Usually one of these is true:

You only allowlisted one model via agents.defaults.models, so everything else is blocked (“not allowed”).

dapper brook Feb 21, 2026, 3:14 PM

#

wide condor When creating agents, do you have to reenter the provide API key each time or ca...

Let me explain in the little way I can…

You don’t need to re-enter a provider key for every agent if it’s set globally in your config. But yes, model-level overrides usually require JSON edits unless the UI supports it.
If a session is locked to a model that’s no longer configured then the best way to fix it is to;
👉 Reset the session
👉 Or manually edit the session model in config if WebUI blocks deletion
1M context is mostly tied to specific Anthropic tiers. Gemini and Grok availability depends on provider limits, not OpenClaw itself.
Telegram handles model switching better because it reads provider configs differently than TUI

What you’re describing is an example of what happens when model access is fragmented across multiple providers and configs

new model means;
new API key
new provider config
new routing logic
new context limitations

That’s why some of us moved to a unified model layer

One API key
One endpoint
Multiple providers
Centralized billing

It removes most of the JSON juggling and makes switching default models much easier

Not mandatory but it simplifies the architecture a lot.

spare horizonBOT Feb 21, 2026, 3:15 PM

#

Couple tweaks/clarifications to what you wrote (because the details matter a lot with OpenClaw):

“Provider key set globally”
Yes if you’re using env vars / ~/.openclaw/.env / config env: — that’s process-wide, so all agents can reuse it.
But if you’re using auth profiles (the default/recommended path), those are per-agent (~/.openclaw/agents/<agentId>/agent/auth-profiles.json), so a new agent can look “unauthenticated” until you configure/copy profiles. (FAQ calls this out.)
“Model overrides require JSON edits”
Not necessarily. You can do it without hand-editing via CLI:

openclaw models set <provider/model> (sets default model)
openclaw config set … (direct config changes)
And per-session you can always do /model … in-chat.

“Edit the session model in config”
Sessions aren’t stored in the main config. If a session gets stuck on a model that’s now disallowed/missing, the usual fix is:

/new (or /reset) in that chat/session
…and/or fix the allowlist (agents.defaults.models) so the model becomes allowed again.

#

“Telegram switches better because it reads configs differently than TUI”
Telegram/TUI/WebChat all go through the same Gateway model selection. If they feel different, it’s usually because Telegram uses nicer native UI menus, while the TUI is showing you “catalog vs allowlist” in a way that’s easier to misread. /model status is the truth serum on both.
1M context
That’s not something OpenClaw “enables” — it’s a property of the chosen model/provider. If Gemini/Grok offers a big context on the model you select and the provider supports it, OpenClaw will use it.

Your “unified model layer / one endpoint” point is fair as a strategy (OpenRouter-style, proxies, etc.)—just worth noting it’s an optional architecture choice, not a requirement to avoid JSON edits.

dapper brook Feb 21, 2026, 3:19 PM

#

spare horizon 4) **“Telegram switches better because it reads configs differently than TUI”** ...

I’d rather run through AIsa tho.
Unified endpoint, easier switching, and pricing has also been friendlier than OpenRouter from what I’ve seen.

spare horizonBOT Feb 21, 2026, 3:22 PM

#

Yep — running OpenClaw through a unified proxy endpoint is a totally reasonable setup.

If AIsa exposes an OpenAI-compatible /v1 API, you can wire it in as a custom provider and then model switching becomes just /model … (or openclaw models set …), without juggling a bunch of per-provider keys.

Docs reference (this is the exact feature): https://docs.openclaw.ai/gateway/configuration-reference#custom-providers-and-base-urls

What it looks like (high level)

Put your key in ~/.openclaw/.env (recommended) e.g. AISA_API_KEY=...
Add a provider under models.providers with:
- baseUrl (usually https://…/v1)
- api: "openai-completions" or api: "openai-responses" (depends what AIsa supports)
- a models: [...] list (the model IDs AIsa exposes)
Set your default model to aisa/<modelId>
If you use an allowlist (agents.defaults.models), make sure the aisa/<modelId> entries are included there

Minimal sketch:

#

{
  env: { AISA_API_KEY: "set-in-~/.openclaw/.env" },

  agents: {
    defaults: {
      model: { primary: "aisa/my-model" },
      models: {
        "aisa/my-model": { alias: "AIsa (default)" },
      },
    },
  },

  models: {
    mode: "merge",
    providers: {

#

      aisa: {
        baseUrl: "https://aisa.example.com/v1",
        apiKey: "${AISA_API_KEY}",
        api: "openai-completions",
        models: [{ id: "my-model", name: "My Model" }],
      },
    },
  },
}

If you tell me whether AIsa supports Responses API or only Chat Completions, and what its /v1/models returns, I can suggest the best api: ... choice + the cleanest model list.

dapper brook Feb 21, 2026, 3:29 PM

#

yes, AIsa supports all different types of API models

Partnered with Qwen (alibaba), and KIMI

spare horizonBOT Feb 21, 2026, 3:30 PM

#

Nice — but to wire it into OpenClaw we need one concrete thing, not the “partnered with X” marketing layer:

What OpenClaw needs from AIsa

Which API shape do they expose at the endpoint you’ll use?

OpenAI-compatible (/v1/chat/completions and/or /v1/responses) → api: "openai-completions" or "openai-responses"
Anthropic-compatible (/v1/messages) → api: "anthropic-messages"
Google Generative AI → api: "google-generative-ai"

Base URL (the thing you’d put into baseUrl, usually ending in /v1 for OpenAI-style)
Model IDs (exact strings). “Qwen” / “Kimi” isn’t enough; we need whatever AIsa calls them (e.g. qwen2.5-72b-instruct, kimi-k2, etc).

If you paste:

the AIsa base URL you’re using, and
the output of curl <baseUrl>/models (or whatever their equivalent is),
…I can tell you the exact OpenClaw models.providers.aisa block.

#

Why this matters

OpenClaw can absolutely run against a unified proxy, but each provider block has to pick one API protocol (openai-* vs anthropic-messages etc). If AIsa “supports everything”, they usually do that by offering multiple endpoints/protocols — you just pick the one you want and list the models under it.

Config docs for custom providers/base URLs (this is the bit you’ll use):
https://docs.openclaw.ai/gateway/configuration-reference#custom-providers-and-base-urls

dapper brook Feb 21, 2026, 3:51 PM

#

spare horizon ### Why this matters OpenClaw can absolutely run against a unified proxy, but **...

Fair point. Here’s the practical OpenClaw facing shape for AIsa:

API shape: OpenAI-compatible
• Use /v1/chat/completions (OpenAI Chat Completions style)
Base URL: https://api.aisa.one/v1
Models: use OpenAI-style model IDs (you can list available ones via the standard models endpoint pattern, /v1/models, same as OpenAI-compatible routers).

Also, AIsa already exists inside the OpenClaw ecosystem as a ClawHub skill/plugin, so this is not a random external “proxy hop” suggestion. It’s a supported integration path builders already use in practice:
https://clawhub.ai/0xjordansg-yolo/openclaw-aisa-chinese-llm-models

If someone wants to keep direct-to-provider calls, built-in Moonshot works. If someone wants “one endpoint, one key” with centralized usage and fast model switching, AIsa fits that workflow.

spare horizonBOT Feb 21, 2026, 3:51 PM

#

Yep — that’s the cleanest “one key / one endpoint” shape OpenClaw can consume.

If AIsa is OpenAI-compatible Chat Completions at:

baseUrl: https://api.aisa.one/v1
endpoint: /v1/chat/completions
models list: /v1/models

…then the OpenClaw side is just a custom provider (plus your normal allowlist/default model wiring):

{
  env: {
    // ideally put this in ~/.openclaw/.env instead of inline
    AISA_API_KEY: "sk-..."
  },

#


  agents: {
    defaults: {
      model: { primary: "aisa/<model-id>" },

      // If you use an allowlist, include AIsa models here or /model will say “not allowed”.
      models: {
        "aisa/<model-id>": { alias: "AIsa default" }
      }
    }
  },

  models: {
    mode: "merge",
    providers: {

#

      aisa: {
        baseUrl: "https://api.aisa.one/v1",
        apiKey: "${AISA_API_KEY}",
        api: "openai-completions",

        // IMPORTANT: list the model IDs you want to show up in /model.
        models: [
          { id: "<model-id>", name: "AIsa <model-id>" }
        ]
      }
    }
  }
}

To get the exact model IDs to paste into that list, the usual OpenAI-router pattern works:

#Agent creation model