help with setup

[undone salmon]

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

[silk heath]

That config won’t work as-is — a bunch of the keys/sections don’t match OpenClaw’s schema, and a few provider concepts are mixed up.

What’s wrong / what to change

1. providers is not a top-level block

• Custom model endpoints go under models.providers, not providers.
• Docs: https://docs.openclaw.ai/gateway/configuration#models

2. OAuth is not configured with auth: "oauth" in a provider block

• Codex OAuth is the built-in provider openai-codex (you log in via CLI).
• Google Antigravity OAuth is the built-in provider google-antigravity (plugin + CLI login).
• You generally don’t set baseUrl for those in config; you enable the plugin and login, and OpenClaw stores tokens in auth profiles.
• Docs: https://docs.openclaw.ai/concepts/model-providers

3. google-antigravity is not “Claude via OpenAI-compatible endpoint”

• Don’t put Claude model IDs under google-antigravity. If you want Claude, use the anthropic/* provider models.
• (Antigravity is a Google auth path for Google models.)

4. Heartbeat config is in the wrong place

• It’s agents.defaults.heartbeat, not gateway.heartbeat.
• There is no silent_hours / silent_hours field in the schema.
• Docs: https://docs.openclaw.ai/gateway/configuration (search for agents.defaults.heartbeat)

5. Your “memory/chromadb/embeddingModel” block doesn’t match OpenClaw

• OpenClaw durable memory is Markdown (MEMORY.md + memory/*.md) and optional semantic search is configured via memory / agents.defaults.memorySearch.
• Docs: https://docs.openclaw.ai/concepts/memory

6. Your channels: { default/coding/secure_local } block is not a thing

• In OpenClaw, channels means WhatsApp/Telegram/Discord/etc config.
• If you want “coding uses Codex” vs “secure_local uses Ollama”, do it with multi-agent routing (agents.list + bindings) or just switch models in the same session using /model.
• Docs: https://docs.openclaw.ai/concepts/channel-routing

7. Model failover key name

• Use agents.defaults.model: { primary, fallbacks: [...] } (plural fallbacks).
• Docs: https://docs.openclaw.ai/gateway/configuration (search fallbacks)

---

“Can I use all those models in the same OpenClaw + same session?”

Yes — within one agent, you can /model <alias> back and forth and it stays the same session context. But OpenClaw won’t auto-pick “coding vs secure_local” based on a custom channels.coding block; that part needs to be either:

• manual (/model codex, /model fast, etc.), or
• multi-agent (different agents, routed by Discord channel / DM / etc).

---

What else you need to do (checklist)

1. Validate your install + schema drift

openclaw --version
openclaw doctor

2. Auth/login for the providers you want

• Codex OAuth:

  openclaw models auth login --provider openai-codex --set-default
  

• Google Antigravity OAuth (if you actually want it):

  openclaw plugins enable google-antigravity-auth
  openclaw models auth login --provider google-antigravity --set-default
  

• API-key providers: set env vars (or models.providers.<id>.apiKey), e.g. ZAI_API_KEY, OPENAI_API_KEY, ANTHROPIC_API_KEY, etc.

3. Confirm OpenClaw sees the models + auth

openclaw models list
openclaw models status

---

If you paste your openclaw --version and (redacted) output of openclaw doctor / openclaw models status, I can tell you exactly which blocks to remove/rename and what the minimal “hybrid cloud + Ollama local + fallbacks + aliases” config should look like for your setup.

[autumn ginkgo]

can you write the files I need to replace for me ? antigravity oauth Claude 4.5 Opus, ollama cloud Kimi 2.5 (80B), antigravity oauth Gemini 3 Pro
antigravity Claude Sonnet 4.5, ollama cloud Qwen3-Coder-Next, ollama cloud MiniMax m2.1
ollama Qwen3-8B, ollama local Ministral 3B, antigravity oauth Gemini 3 Flash
local Qwen 3 VL, local Skywork-Browser
local TimesFM 2.0.0 wsl2 , local Chronos wsl2
local Flux.1 wsl2 , SDXL WSL2, local AudioCraft (MusicGen/AudioGen) wsl2
local F5-TTS WSL2, local Whisper (2025) BAAI/bge-m3 codex gpt 5.3 antigravity claude code 4.6

[silk heath]

I can’t directly write/replace files on your Pi from Discord, but I can give you copy‑pasteable files that match the real OpenClaw schema.

Also: your model list mixes LLMs (Claude/Gemini/Ollama/etc) with non‑LLM tools (TimesFM, Chronos, Flux/SDXL, Whisper, MusicGen, TTS). OpenClaw’s models config is for chat-capable models behind an OpenAI/Anthropic-style API. The non‑LLM stuff needs either:

• a skill (custom tool integration), or
• you wrap it behind an OpenAI-compatible “chat” proxy (LiteLLM/custom server) so OpenClaw can call it like an LLM.

Below is a solid “hybrid cloud + Ollama local + Ollama remote” baseline that will work for “same OpenClaw + same session, switch models with /model”.

---

File 1) ~/.openclaw/openclaw.json (or .json5)

Paste this, then adjust the placeholders (especially OLLAMA_CLOUD_BASE_URL):

{

  $schema: "https://docs.openclaw.ai/schema/openclaw.schema.json",

  gateway: {
    name: "Pi_v5.1_Hybrid",
    mode: "local",
    port: 3456,
    bind: "loopback",

    // Optional but recommended (or set OPENCLAW_GATEWAY_TOKEN in .env)
    // auth: { mode: "token", token: "${OPENCLAW_GATEWAY_TOKEN}" },
  },

  // Use .env for secrets/keys (recommended)
  env: {
    shellEnv: { enabled: true }, // optional convenience

  },

  agents: {
    defaults: {
      // Default model for the agent (same session; you can switch with /model)
      model: {
        // Pick ONE primary you know you have working first.
        // Examples (don’t guess IDs — verify with `openclaw models list`):
        primary: "ollama/ministral:3b",
        fallbacks: [
          "anthropic/claude-sonnet-4-5",
          "google-antigravity/gemini-3-pro",
        ],
      },

      // Allowlist + aliases for /model
      // IMPORTANT: Only put models here that actually exist on your providers.
      models: {
        // ---- Anthropic (Claude) ----
        "anthropic/claude-opus-4-5": { alias: "opus" },
        "anthropic/claude-sonnet-4-5": { alias: "sonnet" },

        // ---- Google Antigravity (Gemini via OAuth plugin) ----
        "google-antigravity/gemini-3-pro": { alias: "g3p" },
        "google-antigravity/gemini-3-flash": { alias: "flash" },

        // ---- Ollama LOCAL (runs where the Gateway runs!) ----
        // These IDs must match `ollama list` exactly.
        "ollama/ministral:3b": { alias: "fast-local" },
        "ollama/qwen3:8b": { alias: "qwen8b" },

[delicate kernel]

openclaw configure will get you a working bot and your bot can then add onto its config. your bot has access to the schema for the config so it'll know what to do

[silk heath]

        // If your Ollama has these and they support tools:
        // "ollama/qwen3-coder-next": { alias: "coder-local" },
        // "ollama/qwen3-vl": { alias: "vl" },
        // "ollama/skywork-browser": { alias: "browser" },

        // ---- Ollama “cloud” / remote box (custom provider below) ----
        "ollama-cloud/kimi-k2.5-80b": { alias: "kimi" },
        "ollama-cloud/qwen3-coder-next": { alias: "coder" },
        "ollama-cloud/minimax-m2.1": { alias: "m2.1" },
      },

      heartbeat: {
        every: "30m",
        target: "last",

        // No "silent_hours" config key exists; if you need quiet hours, do it operationally
        // (disable heartbeats overnight) or via separate automation outside of heartbeat.
      },

      // Memory: OpenClaw durable memory is Markdown (MEMORY.md + memory/*.md).
      // Semantic search is configured via memorySearch (not chromadb).
      //
      // If you want BGE-M3 embeddings locally, you need a LOCAL embedding setup that OpenClaw supports.
      // Start with defaults first; then tune memorySearch after everything else is stable.
      // memorySearch: { provider: "openai" | "gemini" | "local", ... }
    },
  },

  // Custom providers (base URLs) go here:
  models: {

    mode: "merge",
    providers: {
      // Remote Ollama box (or “Ollama Cloud”) MUST be reachable from the Gateway host.
      // If your Gateway is on a Pi, DO NOT use localhost unless Ollama is on the Pi.
      "ollama-cloud": {
        baseUrl: "${OLLAMA_CLOUD_BASE_URL}", // e.g. "http://100.x.y.z:11434/v1" (Tailscale IP) or "http://192.168.1.50:11434/v1"
        apiKey: "${OLLAMA_CLOUD_API_KEY}",   // can be any string; Ollama doesn’t require a real key
        api: "openai-completions",
        models: [
          { id: "kimi-k2.5-80b", name: "Kimi K2.5 80B (remote)" },
          { id: "qwen3-coder-next", name: "Qwen3 Coder Next (remote)" },
          { id: "minimax-m2.1", name: "MiniMax M2.1 (remote)" },
        ],
      },
    },

  },
}

Docs:

• Models + custom providers: https://docs.openclaw.ai/gateway/configuration#models
• Model providers overview (OAuth vs API keys): https://docs.openclaw.ai/concepts/model-providers
• Ollama provider behavior: https://docs.openclaw.ai/providers/ollama

---

File 2) ~/.openclaw/.env (example)

# Remote Ollama box (NOT localhost unless it’s on the same machine as the Gateway)

OLLAMA_CLOUD_BASE_URL="http://192.168.1.50:11434/v1"
OLLAMA_CLOUD_API_KEY="ollama-local"

# Enable LOCAL Ollama autodiscovery (Ollama on the Gateway host)
OLLAMA_API_KEY="ollama-local"

# If you enable gateway token auth:
# OPENCLAW_GATEWAY_TOKEN="paste-a-long-random-token-here"

# Cloud keys (only if you use those providers)
# ANTHROPIC_API_KEY="..."
# GEMINI_API_KEY="..."    # (not needed if you use google-antigravity OAuth instead)
# ZAI_API_KEY="..."

---

Required CLI steps (for the OAuth ones you asked for)

Google Antigravity (Gemini OAuth)

openclaw plugins enable google-antigravity-auth
openclaw models auth login --provider google-antigravity --set-default

Claude (Anthropic)

Claude is not “antigravity”. Use Anthropic auth (API key or setup-token).
Docs: https://docs.openclaw.ai/providers/anthropic

---

Then restart + verify

openclaw doctor
openclaw gateway restart
openclaw models list
openclaw models status

---

Two quick questions so I can finish this exactly for your setup

1. Where is the Gateway running physically (Pi?) and where are the “WSL2” services running? (PC on LAN? Tailscale?)
2. Do your TimesFM/Chronos/Flux/SDXL/Whisper/TTS endpoints expose an OpenAI-compatible chat API (/v1/chat/completions or /v1/responses)? If not, they can’t just be added under models.providers and need skills/wrappers.

Answer those and paste your openclaw models list output (just the provider/model lines; no secrets) and I’ll rewrite the config with the correct model IDs for your machine.

[silk heath]

Yep — The Smart One is right here.

If you want this to be actually working (not “a huge config that looks right”), the best path is:

1. Get a minimal working bot via the wizard

openclaw --version
openclaw configure
# (or: openclaw configure --section models --section channels)

This writes a schema-valid config and avoids guessing keys like providers, silent_hours, etc.

2. Login/auth using the CLI flows (especially OAuth providers)

# Codex OAuth (if you want it)
openclaw models auth login --provider openai-codex --set-default

# Google Antigravity (Gemini OAuth)
openclaw plugins enable google-antigravity-auth
openclaw models auth login --provider google-antigravity --set-default

3. Verify what OpenClaw actually sees

openclaw models list
openclaw models status

4. Only then start “adding onto config” (custom baseUrls, remote Ollama boxes, etc.) under:

• models.providers (custom endpoints)
• agents.defaults.models (aliases/allowlist)
• agents.defaults.model (primary + fallbacks)

If you paste the output of openclaw models list (just the model refs) I can tell you exactly what to add next without inventing model IDs.

[autumn ginkgo]

I am on my bots v5 already lfmao, spend time on other stuff and then when I ask for model testing I realize no images, no music, and oh scrap

[silk heath]

That’s the key gotcha: adding “image/music models” to models.providers doesn’t magically give OpenClaw image/music output.

OpenClaw’s models config is for LLMs you chat with (text in/out, sometimes vision in). Image/music generation is typically done via skills (tools) that call a generator (ComfyUI/Flux/SDXL, AudioCraft/MusicGen, Whisper, TTS, etc.), save a file, then send it as an attachment.

So when you say “no images, no music” — there are two different problems:

1) “No images” = can’t understand images you send?

That’s vision / inbound media understanding (optional). Configure tools.media.image (and/or pick a multimodal LLM as your active /model). Docs:

• https://docs.openclaw.ai/nodes/media-understanding

2) “No images / no music” = can’t generate images/music on request?

That needs a generator backend + a skill:

• Flux/SDXL: run ComfyUI (WSL2 is fine) and expose its HTTP API to the machine running the Gateway (LAN/Tailscale). Then write/install a skill that hits ComfyUI, downloads the output PNG, and returns it so OpenClaw can attach it.
• MusicGen/AudioCraft / F5-TTS / Whisper: same pattern—wrap your local Python scripts/services behind a skill.

Skill docs:

• https://docs.openclaw.ai/tools/creating-skills

One important reality check

If your Gateway is on a Pi, “WSL2 local” is not local to the Pi. The Pi must reach those services over the network (e.g. http://<tailscale-ip>:port/...), otherwise you’ll always get “no image/music” behavior because nothing is reachable.

Fastest way forward

Reply with just:

1. Where is the Gateway running (Pi?) and where is WSL2 running (Windows PC?)
2. For “no images”: do you mean understand inbound images or generate images?

Then I’ll give you a minimal, correct config snippet for (a) vision understanding and (b) one concrete generator path (ComfyUI Flux or SDXL), instead of trying to jam 15 tools into the LLM model registry.

[autumn ginkgo]

still if I install Audicraft and /model audiocraft it will give me the audio straight into our conversation no?

[silk heath]

No — not “just by installing AudioCraft”.

AudioCraft (MusicGen/AudioGen) is a generator library/runtime, not a chat surface. OpenClaw won’t automatically know to run it, capture the WAV/MP3 it produces, and attach it back into Discord.

To get “audio straight into our conversation” you need one of these integration paths:

Option A (recommended): AudioCraft behind a small local HTTP service + an OpenClaw skill

Flow:

1. You run a local service (WSL2 is fine) like: POST /musicgen with { prompt, duration }
2. Service generates out.wav (or mp3) and returns it (or a URL)
3. OpenClaw skill calls that endpoint, downloads the file, then sends it as an attachment back into Discord.

This is the “it feels native” experience.

Option B: Skill runs a command locally (exec) to generate audio

Only works if:

• the generator is installed on the same machine (or node) where the skill executes, and

• OpenClaw has permission/tools to run it (exec) and access the output file to attach it.

This is usually more fragile than Option A, but quick for prototypes.

Option C: Use a hosted TTS/music API instead

Same as A, but the backend is a cloud API.

---

Quick clarifying question

Where do you want AudioCraft to run?

• WSL2 Windows box, while the Gateway is on Pi (most common), or
• directly on the Pi?

If it’s WSL2 + Pi, we’ll do Option A with a Tailscale/LAN URL and a skill. That will give you “generate music → bot replies with an audio file” reliably.

[autumn ginkgo]

through wsl2

[silk heath]

WSL2 is perfect for this — but AudioCraft still won’t “just show up” in Discord unless you give OpenClaw a way to call it and send the resulting file back.

The simplest reliable setup is:

1) Run a tiny “MusicGen server” in WSL2 (HTTP)

Your goal: from the Pi (Gateway host), you can do:

• POST http://<wsl2-host>:7777/generate → returns an mp3/wav

Critical: bind the server to 0.0.0.0 and make it reachable from the Pi (LAN or Tailscale). If the Pi can’t curl it, OpenClaw can’t use it.

Quick connectivity test from the Pi:

curl -v http://<wsl2-host>:7777/health

(If you want, I’ll give you a minimal FastAPI example for AudioCraft/MusicGen — but first confirm whether you’ll reach WSL2 via Tailscale IP or LAN IP.)

2) Add an OpenClaw skill that calls that server + sends the audio file

Create a skill folder in your agent workspace (default):

mkdir -p ~/.openclaw/workspace/skills/audiocraft-musicgen

Create:
~/.openclaw/workspace/skills/audiocraft-musicgen/SKILL.md

Example SKILL.md (copy/paste):

---
name: audiocraft_musicgen
description: Generate short music clips via a MusicGen/AudioCraft HTTP server and send them back as an audio attachment.
---

# AudioCraft / MusicGen skill

When the user asks to generate music:
1) Generate audio by calling the MusicGen server (WSL2) over HTTP.
2) Save the result into `media/out.mp3` inside the workspace.
3) Send it back to the current chat as an attachment using the `message` tool.
4) Reply with exactly `NO_REPLY` (to avoid sending an extra text message after the attachment).

Assumptions:
- The MusicGen server base URL is in env var `MUSICGEN_URL` (example: http://100.x.y.z:7777).
- The endpoint is `POST $MUSICGEN_URL/generate` with JSON: { "prompt": "...", "seconds": 10 } returning audio bytes (mp3).

Implementation notes:
- Use the `exec` tool to run curl:

  curl -fsSL -X POST "$MUSICGEN_URL/generate" \
    -H "content-type: application/json" \
    -d '{"prompt":"<PROMPT>","seconds":10}' \
    -o "media/out.mp3"

- Then send:
  message.send with `media: "media/out.mp3"` and a short caption.

Docs for skills: https://docs.openclaw.ai/tools/creating-skills
Docs for sending media: https://docs.openclaw.ai/nodes/images (concept applies beyond WhatsApp; “send with media” is the key)

3) Set one env var on the Pi (so the skill knows where WSL2 is)

In ~/.openclaw/.env on the Pi:

MUSICGEN_URL="http://<reachable-wsl2-ip>:7777"

Then restart (or reload) the gateway so it picks up the skill + env:

openclaw gateway restart

4) Reality checks (the usual “why it doesn’t send audio”)

• Discord file size limits: keep clips short (e.g. 6–12 seconds) and prefer MP3.
• WSL2 reachability: WSL2 localhost is not Pi localhost. Use LAN or Tailscale.
• Tool permissions/sandbox: if you’ve locked down tools, the skill needs exec + message and write access to the workspace.

Two quick answers and I’ll tailor the exact code

1. Will the Pi reach WSL2 via Tailscale or plain LAN IP?
2. Do you want the server to return mp3 (recommended) or wav?

[autumn ginkgo]

if I was doing a project, could I ask my bot to just prompt himself the /model command so it first makes for example the UI/UX and the main model , lets say GLM 4.7 calls opus 4.6 with /model , then when its done with the frontend calls codex gpt 5.3 with /model ? or am I tripping? this is an example if its possible then can they jump anytime autonomously?

[silk heath]

You’re not tripping — multi-model “handoff” workflows are doable, but not exactly the way you described.

What is possible

A) Manual switching in the same session (you drive it)

You can switch the active session model any time with /model, do a phase of work, then switch again.

That’s the clean “same context, different brain” mode — but it’s you sending /model (it’s a slash command handled by the gateway, not something the LLM typically triggers for itself).
Docs: https://docs.openclaw.ai/help/faq#how-do-i-switch-models-on-the-fly-without-restarting

B) Autonomous multi-model work (recommended): sub-agents

This is the closest match to what you want “autonomously”:

• Keep GLM (or whatever) as the orchestrator
• When it hits “UI/UX phase” → it spawns a sub-agent using Opus (model override)
• When it hits “coding phase” → it spawns a sub-agent using Codex
• Each sub-agent runs in its own session and announces results back into your Discord thread

You can do this with natural language like:

“Design the UI/UX using Opus as a sub-agent, then implement using Codex as a sub-agent, then merge results.”

And you can monitor/control them with:

• /subagents list
• /subagents stop …

Docs: https://docs.openclaw.ai/tools/subagents

The key limitation

• Fallbacks (agents.defaults.model.fallbacks) are for errors/timeouts/rate limits, not “switch to a better model for this task.”
• “Autonomously jump models mid-project” is best done via sub-agents, not by the main agent flipping /model back and forth.

If you tell me what aliases you want (e.g. glm, opus, codex) and confirm you already see them in /model list, I can give you a tight config snippet for:

• main orchestrator model
• sub-agent default model (optional)
• allowlist/aliases so sub-agents can request the right ones without “Model not allowed” errors.

[autumn ginkgo]

subagent would automatically switch to main agent when task done/end?

[silk heath]

Yes.

A sub-agent is a separate, temporary worker session. It runs the task you gave it, and when it finishes it announces the result back into your current chat (the main agent’s conversation). After that, you’re effectively “back” with the main agent because:

• the main session is still the one attached to the Discord thread
• the sub-agent doesn’t stay “in control” unless you keep talking to it explicitly via /subagents send ...

A few practical notes:

• Sub-agent sessions are auto-archived later (default ~60 min) unless configured otherwise.
• If you want the main agent to continue automatically after the sub-agent returns, just phrase the request like:
  “Spawn a sub-agent to do UI/UX, then when it announces, integrate it and proceed to coding.”

You can always check what’s running with:

• /subagents list

[autumn ginkgo]

what do you think on setting up chromadb + faiss as secondary hybrid with rag wapper and BAAI/bge-m3 for running openclaw, is it really gamechanger? even better than paying for supermemory ai? is it worth? is there anything better? will I see massive difference on how openclaw runs?

[silk heath]

ChromaDB + FAISS isn’t a “drop-in upgrade” for OpenClaw right now — there’s no built-in config path where you flip memory.backend: chromadb and suddenly everything gets better. If you want that stack, you’re talking about building a custom RAG service + a skill/tool that queries it and injects results into the prompt.

Will it be a gamechanger / massive difference?

Only if your pain is specifically retrieval over lots of external text (docs, repos, notes, transcripts) that you don’t already keep in MEMORY.md / memory/*.md.

If your pain is more like:

• “the agent forgets what it was doing mid-task”
• “it loses context”
• “it doesn’t follow through”

…then a vector DB won’t fix that. That’s more about session management, compaction, task structure, and using sub-agents, not RAG.

What OpenClaw already has (the “80%”)

OpenClaw already supports semantic memory search over MEMORY.md + memory/**/*.md (and can index extra paths), using embeddings + keyword fallback. That’s usually enough for “personal assistant memory”.
Docs: https://docs.openclaw.ai/concepts/memory

And if you want a bigger retrieval jump without building your own Chroma/FAISS stack, look at the QMD backend (BM25 + vectors + reranking sidecar) which is actually described as an integrated option:

Docs: https://docs.openclaw.ai/concepts/memory (QMD section)

“Better than paying for Supermemory AI?”

Different tradeoff:

• Supermemory (hosted) is mainly worth it for product UX + connectors + low-ops.
• Self-host (Chroma/FAISS/Qdrant/etc) is worth it for control/privacy + custom pipelines, but you pay in setup/maintenance and you still must integrate it into OpenClaw via a skill.

What I’d do (practical recommendation)

1. Get OpenClaw’s built-in memory search working well first (and/or QMD).
2. Only add Chroma/FAISS if you have a clear target like: “I want it to answer questions over 50k+ Markdown/PDF pages / a big repo / lots of transcripts”.

If you tell me what you want to “RAG” over (Discord logs? Notion? PDFs? Git repos?) and roughly how big it is, I’ll tell you whether you’ll likely feel a real improvement — and which route (built-in + extraPaths, QMD, or external RAG skill) is the least painful.

[autumn ginkgo]

yes, my pain is more like you say

“the agent forgets what it was doing mid-task”
“it loses context”
“it doesn’t follow through”

Can you give me a military grade idea to improve this?

[silk heath]

“Military grade” for this problem is less about RAG and more about (1) keeping enough context, (2) preventing context bloat, and (3) enforcing an execution loop so the agent can’t wander.

Here’s a battle-tested approach that actually moves the needle in OpenClaw:

1) Use a strong “orchestrator” model + don’t lie about context

If your primary model is small / low-context (common with local), it will inevitably lose the plot mid-task.

• Pick one solid model as the main agent default (GLM/Opus/Sonnet/etc).
• Use cheaper/local models for sub-tasks only.
• Make sure your model’s contextWindow is accurate (custom providers especially). If you overstate it, compaction/pruning timing gets worse.

2) Stop tool output from eating your context (big cause of “forgot what we were doing”)

Enable/tune context pruning so old tool results don’t crowd out the plan:

agents: {

  defaults: {
    contextPruning: {
      mode: "adaptive",
      keepLastAssistants: 5,
      // Optional: don’t prune browser/canvas results if you rely on them heavily
      // tools: { deny: ["browser", "canvas"] },
    },
  },
}

This keeps the “decision-making” messages but trims/clears old tool spam.

3) Make compaction safer (so summaries don’t destroy the plan)

Turn on “safer” compaction and force a memory flush before compaction:

agents: {
  defaults: {
    compaction: {
      mode: "safeguard",
      reserveTokensFloor: 24000,
      memoryFlush: {
        enabled: true,
        softThresholdTokens: 6000,
        prompt: "Write durable project state to memory/YYYY-MM-DD.md (decisions, next steps, constraints). Reply NO_REPLY.",
      },
    },
  },
}

This helps a lot with “it doesn’t follow through” across long sessions, because the bot writes down state before it gets summarized.

4) Force single-threaded execution (prevents derailment)

A hidden killer is concurrency + message queueing: you send follow-ups while it’s mid-run and it half-switches goals.

Set:

agents: { defaults: { maxConcurrent: 1, timeoutSeconds: 900 } },
messages: {
  inbound: { debounceMs: 1200 },
  queue: { mode: "collect", cap: 20, drop: "summarize" },
},

This makes it finish one thing, then process the backlog coherently.

5) Use sub-agents for “specialists” (instead of model-flipping the main brain)

Do not rely on fallbacks for “hard tasks”. Use sub-agents:

• Main agent: orchestrates + keeps the plan
• Sub-agent: UI/UX with Opus, coding with Codex, etc.
• Then main agent integrates.

This is the most reliable way to “jump models autonomously” without losing the central thread.

6) Add a “Mission File” checkpoint habit (this is the real military part)

For any project longer than ~10 minutes, have it create and maintain a single source of truth in the workspace, e.g.:

• PROJECT.md with:
  • Objective
  • Constraints
  • Current status
  • Next 3 actions
  • Definition of Done

And instruct it: after each phase, update PROJECT.md before continuing. That one habit crushes the “wander off / forget” failure mode.

---

If you paste your current agents.defaults block (redact keys) and tell me your primary model + rough context window (128k? 200k?), I’ll give you a ready-to-paste tuned config snippet (compaction + pruning + queue + subagents) that matches your setup exactly.

[autumn ginkgo]

what does this mean? Provider notes:
Z.AI (zai/*) only supports binary thinking (on/off). Any non-off level is treated as on (mapped to low).

[silk heath]

It’s about the “thinking” / reasoning mode knob.

OpenClaw can express different thinking levels (e.g. off / low / medium / high) for models that support it. But Z.AI’s GLM endpoint only supports a boolean: thinking is either off or on.

So that note means:

• If you set thinking to off → Z.AI runs with thinking disabled.
• If you set thinking to anything else (low, medium, high) → OpenClaw has no way to request different intensities, so it just turns thinking on.
• Internally it “maps” any non-off level to low because there’s no finer control available on that provider.

Practical impact:

• Don’t expect “high thinking” to be more than “low thinking” on Z.AI — they’re the same.
• If you want real multi-level thinking control, use a provider/model that supports it (Anthropic is the common example).

If you tell me where you saw that line (from /model status, logs, or the Control UI), I can point to the exact setting that triggered it and how to disable thinking for Z.AI if you want.

[autumn ginkgo]

what is the command to turn on mi zai glm 4.7 then

[silk heath]

To switch your session onto GLM 4.7 (Z.AI), send as a standalone message:

/model zai/glm-4.7

Then, if you want “thinking ON” for Z.AI, any non-off level works (it’s binary on/off for Z.AI):

/thinking low

To turn thinking off again:

/thinking off

If /model zai/glm-4.7 isn’t found or says “not allowed”:

• run /model list and pick it from the numbered list, or
• add "zai/glm-4.7" to agents.defaults.models (if you’re using an allowlist), and make sure ZAI_API_KEY is set on the gateway host.

[autumn ginkgo]

and how do I know how it was (enabled or disabled) before touching it?

[silk heath]

Use the thinking directive without an argument — it prints the current state.

Send:

/thinking

(or the shorter alias)

/think

That shows the current session thinking level (on/off/low/etc).

If you also want the “full picture” (model + auth profile + any pinned overrides), use:

/model status

That will show which model is active and any session overrides currently applied.

[autumn ginkgo]

timesFM and chronos can run directly as subagent or they need skill?

[silk heath]

They need a skill (or a wrapper).

A sub-agent is still just an LLM session (a “worker brain”). It can’t “become TimesFM/Chronos” unless TimesFM/Chronos are exposed behind something that looks like a callable tool.

You have 2 good integration patterns:

Option A (best): Run TimesFM/Chronos as an HTTP service (WSL2) + skill

• WSL2 runs POST /forecast (TimesFM) and POST /predict (Chronos)
• Skill calls the endpoint, gets JSON back, and the bot replies with the forecast (and/or attaches a CSV/plot)

This is the cleanest + works even if the Gateway is on the Pi.

Option B (quick prototype): Skill runs a local command (exec) on the machine that has them

• Write a small Python script that reads input JSON, outputs forecast JSON
• Skill calls it via exec
• Only works if OpenClaw can execute on the right machine (Pi vs WSL2 vs a paired node) and can access the output files.

So: sub-agent = orchestration, skill = actually running TimesFM/Chronos.

If you tell me where TimesFM/Chronos will run (WSL2 box IP/Tailscale) and what input format you want (CSV? JSON with timestamps?), I can sketch the minimal “forecast service + OpenClaw skill” interface.

[autumn ginkgo]

what about BAAI bge m3

[silk heath]

BAAI bge-m3 is not something you run “as a sub-agent”. It’s an embedding model (vectorizer) — useful for semantic memory search / RAG, not for chat replies by itself.

Where it fits in OpenClaw

It plugs into memory search (memory_search) via:

• agents.defaults.memorySearch (built-in SQLite + vectors + BM25 hybrid)
• optionally the QMD backend (different local retrieval engine)

Docs: https://docs.openclaw.ai/concepts/memory

If you want bge-m3 specifically

OpenClaw “local embeddings” expects a GGUF (or hf: URI that resolves to a GGUF) via node-llama-cpp.

Example (local embeddings):

{
  agents: {
    defaults: {
      memorySearch: {
        provider: "local",
        local: {
          // You need a GGUF here (either a local path or an hf: URI to a GGUF file)
          modelPath: "hf:<some-bge-m3-gguf-repo>/<file>.gguf"
        },
        fallback: "none"
      }
    }
  }
}

Important caveats:

• You must actually have a bge-m3 GGUF available. (If you only have the original HF transformers model, that’s not enough for this local path.)
• Local embeddings require native deps (node-llama-cpp). On a Pi this can be annoying/heavy.

The practical recommendation (for most people)

Use remote embeddings first (simpler, works great):

{
  agents: {
    defaults: {
      memorySearch: { provider: "openai", model: "text-embedding-3-small" }
      // or provider: "gemini"
    }
  }
}

Also: Codex OAuth does not grant embeddings, so for OpenAI embeddings you still need an actual OPENAI_API_KEY (docs mention this).

Will bge-m3 “massively fix” forgetting mid-task?

Usually no — bge-m3 helps when the agent decides to retrieve something it wrote before. Your symptoms (“loses the plot mid-task”) are more about context/compaction/pruning + execution loop, not embeddings quality.

If you want, paste what host your Gateway is on (Pi?) and whether you have OpenAI/Gemini keys available, and I’ll tell you the best “lowest ops” memorySearch config for your setup (local vs remote, plus whether to enable experimental.sessionMemory).

[silk heath]

Ese “Blindaje de Seguridad v5.1” como prompt puede servir como recordatorio de comportamiento (“no pegues keys en chat / no las guardes en archivos”), pero no convierte OpenClaw en un vault cifrado ni activa ninguna función real de “security.vault”.

Puntos clave (importantes):

1) Ese bloque de config "security": { "vault": ... } no existe en el schema de OpenClaw

En OpenClaw no hay una sección estándar gateway.security / security.vault como la que pones. Si lo agregas, lo normal es que:

• el config no valide o
• simplemente sea ignorado (dependiendo del validador/versión), pero no te da vault.

2) Cómo maneja secretos OpenClaw “de verdad” hoy

• API keys: lo más sano es env vars (o ${VAR} en config). OpenClaw soporta sustitución ${VAR}.
• OAuth (Codex/Antigravity/etc): se guarda en auth profiles en disco (ej. ~/.openclaw/agents/<agentId>/agent/auth-profiles.json). Eso es práctico, pero no es un vault cifrado.

O sea: el “zero persistence” que describes no es el comportamiento actual.

3) Si quieres un “vault cifrado” estilo militar: se hace fuera de OpenClaw

Lo viable es:

• guardar secretos en un secrets manager (1Password CLI, sops/age, pass, Vault, etc.)
• al arrancar el gateway, inyectar secretos como env vars (sin escribirlos en openclaw.json)

Ejemplo (patrón correcto en OpenClaw):

models: {
  providers: {
    "my-proxy": {
      baseUrl: "https://…",
      apiKey: "${MY_PROXY_API_KEY}"
    }
  }
}

…y MY_PROXY_API_KEY lo resuelve el sistema operativo (systemd/launchd/tu wrapper), no el LLM.

4) Para reducir leaks en la práctica (sin inventar features)

• No pegues keys en Discord (esto es el leak #1).
• Mantén activado el redaction por defecto (OpenClaw ya redácta tool outputs sensibles en logs en muchos casos).
• Evita /verbose full en canales públicos.
• Restringe tools/sandbox si es un bot expuesto.

---

Si me dices en qué host corre el Gateway (Pi) y cómo lo arrancas (systemd service? terminal?) te digo el enfoque más limpio para “vault cifrado externo → export env vars → OpenClaw” en tu caso.

[autumn ginkgo]

hello Krill, the 1password default skill on installation...is it only for API keys or also discord connection tokens with my bot will be stored there?

[silk heath]

The 1Password skill is just a helper for using the op CLI (read/inject/run secrets). It doesn’t automatically store anything for OpenClaw.

What gets stored where (by default)

• Discord bot token: either
  • plaintext in config: channels.discord.token, or
  • env var: DISCORD_BOT_TOKEN (env fallback)
    Docs: https://docs.openclaw.ai/channels/discord#quick-setup-beginner
• Model API keys: usually env vars (or config models.providers.*.apiKey).
• OAuth logins (Codex/Antigravity/etc): stored in OpenClaw’s auth profiles on disk (auth-profiles.json), not in 1Password.

If you want Discord tokens in 1Password

Yes, you can store the Discord token in 1Password — but you must wire it in yourself by starting the gateway with env injected from 1Password, e.g.:

• keep channels.discord.token unset (so it’s not written in plaintext), and
• set DISCORD_BOT_TOKEN via op run (or similar), so the secret never lands in openclaw.json.

So: 1Password can be used for API keys and Discord tokens, but only if you choose that pattern. OpenClaw won’t automatically move/manage those tokens in 1Password for you.

If you tell me what OS your Gateway runs on (Pi/Linux?) and how you start it (systemd service vs manual), I can show the cleanest op run -- … setup for that environment.

[autumn ginkgo]

will it load ollama models will load as subagents if doing openclaw onboard and selecting z ai glm 4.7 as a main? or I have to follow any further steps?

[silk heath]

No — picking Z.AI GLM 4.7 as your main model in openclaw onboard won’t automatically make Ollama models “load as subagents.”

What happens by default:

• Main agent uses whatever you set as agents.defaults.model.primary (GLM 4.7 in your case).
• Sub-agents (spawned via sessions_spawn) inherit the caller’s model unless you configure a sub-agent default model or explicitly override the model when spawning.

What you need to do (minimum)

1) Make Ollama models available to OpenClaw

If Ollama runs on the same machine as the Gateway:

• install/run Ollama
• ollama pull <model>
• set OLLAMA_API_KEY to any value (it’s just an enable flag)
• don’t define models.providers.ollama if you want autodiscovery

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

If your Gateway is on a Pi and Ollama is on WSL2, then localhost won’t work — you must point OpenClaw at the WSL2/LAN/Tailscale URL via models.providers (custom provider/baseUrl).

2) Set a default model for sub-agents (optional but recommended)

Add this to your config:

{
  agents: {
    defaults: {
      subagents: {
        model: "ollama/qwen3:8b",
        maxConcurrent: 1
      }
    }
  }
}

Also make sure that model is allowed if you’re using an allowlist (agents.defaults.models).

Docs: https://docs.openclaw.ai/tools/subagents

How to verify it’s working

Run:

openclaw models list
openclaw models status

and in chat you can check/manage subagents with:

/subagents list

If you tell me where Ollama is running (Pi local vs WSL2) and the exact model IDs from ollama list, I can give you the exact models.providers + subagents.model snippet that matches your topology.

[autumn ginkgo]

do I have to set anything up before doing it from openclaw?

[silk heath]

Yes — you need Ollama itself running + reachable before OpenClaw can use it (main agent or sub-agents). OpenClaw won’t “pull/load” Ollama models for you; it just sends requests to an Ollama server.

Minimal checklist (before you try it in OpenClaw)

1) On the machine that will run Ollama

• Install Ollama
• Pull the models you want:

  ollama pull qwen3:8b
  # etc
  ollama list
  

• Make sure the Ollama server is running.

2) Make sure the Gateway host can reach Ollama

From the machine running the OpenClaw Gateway (Pi/VPS/etc), test:

curl http://<ollama-host>:11434/api/tags

If that fails, OpenClaw can’t use Ollama (common issue when Ollama is on WSL2 but only bound to localhost).

3) Enable Ollama in OpenClaw

On the Gateway host, set an API key value (any string is fine; it’s an enable flag):

• Env var: OLLAMA_API_KEY=ollama-local
  (or via config: models.providers.ollama.apiKey)

Then confirm OpenClaw sees the models:

openclaw models list

openclaw models status

4) If you want sub-agents to use Ollama by default

Set:

agents: {
  defaults: {
    subagents: { model: "ollama/qwen3:8b" }
  }
}

And if you use an allowlist (agents.defaults.models), make sure that model is included there too.

---

If you tell me where your Gateway runs (Pi?) and where Ollama runs (WSL2?), I can tell you the exact “best practice” setup (local autodiscovery vs models.providers with a remote baseUrl).

[autumn ginkgo]

take into account I already have installed ollama and models

[silk heath]

Cool — if Ollama + the models are already installed, the remaining work is basically just making OpenClaw see/reach that Ollama server and (optionally) setting Ollama as the default sub-agent model.

1) First: is Ollama on the same machine as the OpenClaw Gateway?

This decides everything:

Case A — Same machine (easy)

OpenClaw will auto-discover Ollama at http://127.0.0.1:11434 if you set OLLAMA_API_KEY (any value):

export OLLAMA_API_KEY="ollama-local"
openclaw gateway restart
openclaw models list
openclaw models status

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

Case B — Ollama is on WSL2 / another machine (common)

Then 127.0.0.1:11434 on the Gateway host is not your WSL2 Ollama. You must:

1. Ensure the Gateway host can reach it:

curl http://<wsl2-or-windows-ip>:11434/api/tags

2. Add an explicit provider in OpenClaw config (models.providers.<name>.baseUrl: "http://<ip>:11434/v1"), because auto-discovery only targets 127.0.0.1:11434.

2) If you want sub-agents to use Ollama by default

Add:

agents: {
  defaults: {
    subagents: { model: "ollama/<your-model-id>" }
  }

}

And if you have an allowlist (agents.defaults.models), make sure that same ollama/... model is included or it’ll say “Model not allowed”.

3) Quick “am I done?” commands

Run these and you’ll know immediately:

openclaw models list
openclaw models status

Tell me: Is your Gateway running on the Pi, while Ollama is in WSL2 on a PC? If yes, paste the result of curl http://<PC-IP>:11434/api/tags from the Pi and I’ll give you the exact models.providers block to paste.

[autumn ginkgo]

pc, unify this prompt windows

[silk heath]

Got it — PC (Windows). Here’s the unified “Windows-first” setup for Ollama + OpenClaw.

Step 0 — Decide where the OpenClaw Gateway runs

• If the Gateway runs on the same PC (Windows/WSL2): easiest path (Ollama can stay localhost).
• If the Gateway runs on a Pi/VPS and Ollama is on your PC: you must expose Ollama to the network (LAN/Tailscale) and point OpenClaw at that IP.

I’ll give both.

---

A) Gateway on the same PC (recommended if you’re testing)

1) Confirm Ollama is reachable locally

PowerShell (or WSL2):

curl http://127.0.0.1:11434/api/tags

2) Enable Ollama in OpenClaw (just an enable flag)

Set OLLAMA_API_KEY in the environment where the gateway process runs.
Easiest: put it in OpenClaw’s global env file:

• WSL2/Linux gateway: ~/.openclaw/.env
• Windows native gateway: wherever you run openclaw gateway from (or set a system env var)

Value can be anything:

OLLAMA_API_KEY=ollama-local

3) Restart + verify

openclaw gateway restart
openclaw models list

openclaw models status

4) (Optional) Make sub-agents use Ollama by default

Add to config:

agents: { defaults: { subagents: { model: "ollama/<your-model-id>" } } }

---

B) Gateway NOT on the PC (Pi/VPS), but Ollama IS on the PC

You need two things:

1) Expose Ollama so the Gateway can reach it

• Make Ollama listen on a non-localhost interface (LAN or Tailscale)

• Allow inbound port 11434 in Windows firewall

Then from the Gateway host (Pi/VPS), this must work:

curl http://<PC-IP>:11434/api/tags

2) Tell OpenClaw to use that remote Ollama via models.providers

Because Ollama autodiscovery only targets 127.0.0.1:11434.

Example:

models: {
  mode: "merge",
  providers: {
    "ollama-pc": {

      baseUrl: "http://<PC-IP>:11434/v1",
      apiKey: "ollama-local",
      api: "openai-completions",
      models: [
        { id: "qwen3:8b", name: "Qwen3 8B (PC Ollama)" }
      ]
    }
  }
},
agents: {
  defaults: {
    models: { "ollama-pc/qwen3:8b": { alias: "qwen8b" } },
    subagents: { model: "ollama-pc/qwen3:8b" }
  }
}

---

One question so I don’t steer you wrong

Is your OpenClaw Gateway running on the PC now, or still on a Pi?

If you answer that + paste what curl http://127.0.0.1:11434/api/tags returns on the PC (just the fact it works / doesn’t), I’ll point you to the exact branch and the minimal config you need.

[autumn ginkgo]

what is the url to autenticate google antigravity oauth if you already set up another main model? in order to use as subagents

[silk heath]

There isn’t a single fixed “Antigravity OAuth URL” you bookmark.

OpenClaw’s Antigravity OAuth is a CLI login flow: you run a command on the gateway host, and it prints the exact URL (and/or device code) you must open for that login session.

Do this on the machine running the Gateway

openclaw plugins enable google-antigravity-auth
openclaw models auth login --provider google-antigravity --set-default

• That command will output something like “Open this URL…” (and usually a code). That’s the URL you use.
• After you complete it, verify:

openclaw models status
openclaw models list

Using it for sub-agents

You don’t need to change your “main model” for this. Once you’re logged in:

• sub-agents can use a google-antigravity/... model if it’s allowed.
• If you have an allowlist (agents.defaults.models), make sure the Antigravity model(s) you want appear there, otherwise you’ll hit “Model … is not allowed”.

If you tell me whether you’re using an allowlist (agents.defaults.models present) and paste the relevant part of your openclaw models status (redacted), I can tell you exactly what to add.

[autumn ginkgo]

al usar glm como principal y probar mis subagentes de antigravity oauth me sale este mensaje

Buena pregunta: ese “model not allowed” no era fallo del proveedor, era una restricción de política interna al lanzar sessions_spawn desde este agente.

En concreto:

• desde coding hay una lista de modelos permitidos para override en subagentes,
• cuando intenté forzar algunos modelos por parámetro model, el sistema lo bloqueó y siguió con el modelo permitido por defecto.

Por eso luego viste que sí respondían “OK”: el job se ejecutó igual, solo que no siempre con el override que yo pedía.
Si quieres, te puedo dejar la allowlist ajustada para que acepte esos overrides explícitos sin ese warning.

[silk heath]

Ese diagnóstico va bien encaminado: no era “fallo de Antigravity”, era que OpenClaw rechazó el override de modelo porque ese modelo no está permitido por tu allowlist.

En OpenClaw, si tienes agents.defaults.models configurado, eso se convierte en la lista de modelos permitidos para:

• /model …
• cualquier override de sesión
• y también el model: que pasas a sessions_spawn (sub-agents)

Cuando el override no está permitido, el sub-agent se ejecuta igual, pero con su modelo por defecto (por eso ves “OK” aunque no usó el modelo que pedías).

Cómo arreglarlo (lo correcto)

1. Asegúrate de que el modelo que quieres usar existe y está disponible

   • En chat: /model list (o /model)
   • En CLI: openclaw models list y openclaw models status

2. Añade esos modelos a agents.defaults.models
   Ejemplo (ajusta a los IDs reales que te salgan en /model list):

agents: {
  defaults: {
    models: {
      "zai/glm-4.7": { alias: "glm" },

      "google-antigravity/gemini-3-pro": { alias: "g3p" },
      "google-antigravity/gemini-3-flash": { alias: "g3f" },

      // Si lo que querías era Claude, NO es antigravity:
      "anthropic/claude-opus-4-5": { alias: "opus" }
    },

    // opcional: modelo por defecto para sub-agents
    subagents: { model: "google-antigravity/gemini-3-pro" }
  }

}

Ojo con una confusión común

• Google Antigravity OAuth → normalmente para Gemini (google-antigravity/*)
• Claude → es Anthropic (anthropic/*) y se autentica por otro flujo (API key o setup-token)

Si me pegas el texto exacto del error “Model … is not allowed” (la línea que te sale) o una captura de /model list, te digo exactamente qué provider/model tienes que añadir al allowlist para que el override funcione.

[autumn ginkgo]

me refiero a los modelos de claude que tiene antigravity oauth

[silk heath]

Ahhh vale — sí existen “Claude” detrás de Antigravity OAuth, pero no son anthropic/.... Son modelos bajo el provider:

• google-antigravity/...

Ejemplo que aparece en los docs/tests de OpenClaw:

• google-antigravity/claude-opus-4-5-thinking

Por qué te sale “model not allowed”

Porque si tienes agents.defaults.models definido, eso es el allowlist. Entonces aunque estés logueado en Antigravity, un sub-agent no puede usar google-antigravity/claude-... si no está en esa lista.

Pasos para dejarlo funcionando (GLM main + Claude Antigravity en subagents)

1. Activar + loguear Antigravity (en la máquina del Gateway)

openclaw plugins enable google-antigravity-auth
openclaw models auth login --provider google-antigravity --set-default

2. Confirma el ID exacto del modelo que te ofrece tu instalación
   En chat:

/model list

o en CLI:

openclaw models list
openclaw models status

3. Añádelo al allowlist
   En tu openclaw.json:

agents: {

  defaults: {
    models: {
      "zai/glm-4.7": { alias: "glm" },

      // Pon AQUÍ el exacto que te salga en /model list
      "google-antigravity/claude-opus-4-5-thinking": { alias: "ag-opus" }
    },

    // Opcional: que los subagents usen esto por defecto
    subagents: {
      model: "google-antigravity/claude-opus-4-5-thinking"
    }
  }
}

Con eso:

• mantienes GLM como principal
• y los sub-agentes ya pueden correr con Claude (Antigravity OAuth) sin bloquear el override.

Si me pegas lo que te sale en /model list para los google-antigravity/..., te digo cuál poner exactamente (porque los IDs pueden variar y no quiero inventármelos).

[autumn ginkgo]

el tema es que solo me sale 2-5 flash por algun motivo, pero si hago openclaw onboard con antigravity oauth si que me deja usar opus 4.6 opus 4.5 sonnet 4.5 gemini 3 pro y gemini 3 flash...

[silk heath]

Eso casi siempre pasa por una de estas 2 cosas (y ambas encajan perfecto con lo que describes):

1) Tienes un allowlist activo (agents.defaults.models) y te está “recortando” /model list

En OpenClaw, si existe agents.defaults.models, /model solo te muestra (y solo te deja usar) esos modelos.
Entonces aunque Antigravity esté bien logueado, si en tu allowlist solo está …gemini-2.5-flash…, eso es lo único que verás.

Cómo confirmarlo rápido (en chat):

1. Ejecuta:

/model status

2. Luego:

/model list

Si model status te indica que hay allowlist/aliases configurados, ahí está el “por qué”.

Fix: añade explícitamente los google-antigravity/... que quieres a agents.defaults.models (o temporalmente quita el allowlist para probar).

2) Te logueaste a Antigravity en otro agente (auth profiles son por agente)

El onboarding puede haberte creado/auth en un agente, pero ahora estás chateando con otro (o cambiaste routing).
Como los tokens viven en ~/.openclaw/agents/<agentId>/agent/auth-profiles.json, si estás en otro agentId, no aparecen esos modelos.

/model status te lo revela porque muestra qué agente está activo y qué auth-profiles.json está usando.

---

Nota importante sobre “Opus 4.6 / 4.5”

En Antigravity, los “Claude” suelen aparecer con IDs tipo:

• google-antigravity/claude-opus-4-5-thinking (ejemplo real de docs/tests)

O sea, aunque el UI te lo “nombre” como 4.6/4.5, el model id que OpenClaw lista/permite puede ser distinto (y a veces con -thinking).

---

Lo mínimo que necesito para decirte exactamente qué tocar

Pégame el output de:

• /model status (en el chat donde te falla)
• y si puedes, una captura/texto de /model list

Con eso te digo si es allowlist, agente equivocado, o modelo id distinto (y te paso el bloque exacto para agents.defaults.models).

[autumn ginkgo]

dice antigravity (5) pero si lo elijo solo se pone el gemini 2-5 flash

[silk heath]

Eso suena a que en tu picker “antigravity (5)” es el grupo/proveedor, y al elegirlo OpenClaw te está poniendo el modelo “default” de ese proveedor (en tu caso: gemini-2.5-flash). No estás seleccionando un modelo Claude concreto.

Lo normal cuando “onboard con antigravity” te dejaba ver Opus/Sonnet/etc y ahora no, es por allowlist:

• Si tienes agents.defaults.models definido, /model solo te deja escoger lo que esté ahí.
• Si en tu allowlist solo quedó google-antigravity/gemini-2.5-flash, aunque Antigravity tenga Claude disponibles, no te los va a mostrar ni permitir, y al “elegir Antigravity” cae al único permitido.

Cómo comprobarlo en 30 segundos (sin adivinar)

1. En el chat, ejecuta:

/model status

2. Luego intenta forzar directamente el Claude de Antigravity (con un ID conocido):

/model google-antigravity/claude-opus-4-5-thinking

• Si te responde “Model … is not allowed” → 100% es allowlist: tienes que añadir ese model id a agents.defaults.models.
• Si te responde “Unknown model …” → tu gateway ahora mismo no está resolviendo ese modelo (plugin/login/routing/agent distinto). En ese caso: en la máquina del gateway corre:

  openclaw plugins enable google-antigravity-auth
  openclaw models auth login --provider google-antigravity --set-default
  openclaw models list
  

Fix típico (cuando es allowlist)

Añade (copiando EXACTAMENTE los IDs que te salgan en /model list o openclaw models list):

agents: {
  defaults: {
    models: {
      "zai/glm-4.7": { alias: "glm" },

      "google-antigravity/claude-opus-4-5-thinking": { alias: "ag-opus" },
      "google-antigravity/claude-sonnet-4-5-thinking": { alias: "ag-sonnet" },

      "google-antigravity/gemini-2.5-flash": { alias: "ag-flash" }
    }
  }
}

Si me pegas el texto de /model status (o screenshot) te digo exactamente cuál de las dos (allowlist vs “unknown model”) es tu caso y qué línea hay que tocar.

[autumn ginkgo]

google-antigravity/gemini-3-flash
• google-antigravity/claude-opus-4-6-thinking
• google-antigravity/claude-sonnet-4.5
• google-antigravity/claude-code-4.6
• google-antigravity/gemini-3-pro

aparecen estos al hacer estatus , nisiquiera aparece el 2.5 que luego dice elegir, que raro

[silk heath]

Eso sí es raro, pero tiene una explicación bastante probable:

• En tu /model status aparecen modelos google-antigravity/... (Gemini 3, Claude Opus/Sonnet/Code).
• Si al “elegir Antigravity” te pone Gemini 2.5 Flash, entonces eso NO está viniendo de google-antigravity, sino de otro provider/alias (normalmente google/... o un atajo tipo gemini-flash que apunta a otra cosa).

La forma de salir de la duda y arreglarlo es forzar el modelo por ID completo (sin pasar por el “grupo”):

1) Fuerza Claude Antigravity explícitamente (en el chat)

Prueba exactamente:

/model google-antigravity/claude-opus-4-6-thinking

Luego inmediatamente:

/model status

Ahí debería decirte el Active model real. Si sigue diciendo algo como google/...gemini-2.5-flash, entonces no está aplicando el cambio (por allowlist/otro agente/otro override).

2) Para evitar estos líos: crea aliases “limpios”

En tu config, pon aliases para esos IDs (y así no dependes del selector por proveedor):

agents: {
  defaults: {
    models: {
      "google-antigravity/claude-opus-4-6-thinking": { alias: "ag-opus" },
      "google-antigravity/claude-sonnet-4.5": { alias: "ag-sonnet" },
      "google-antigravity/claude-code-4.6": { alias: "ag-code" },

      "google-antigravity/gemini-3-pro": { alias: "ag-g3p" },
      "google-antigravity/gemini-3-flash": { alias: "ag-g3f" }
    }
  }
}

Luego ya seleccionas con:

/model ag-opus

y para sub-agents puedes pedir “usa ag-opus” (o pasar ese alias como model en sessions_spawn).

3) Si el comando te responde “Model not allowed”

Entonces es 100% allowlist: te falta ese ID dentro de agents.defaults.models.

---

Pásame el output de /model status justo después de que te “ponga gemini 2.5 flash” (la línea donde dice el modelo activo). Con eso te digo si:

• te está resolviendo al provider equivocado (google vs google-antigravity), o
• hay un override/allowlist bloqueando el cambio.

[autumn ginkgo]

pero recuerda que todos ellos deben ser subagentes

[silk heath]

Perfecto — entonces la regla es:

• GLM (zai/glm-4.7) = agente principal (orquestador)
• Claude/Gemini via google-antigravity/* = SOLO sub-agentes

Eso se consigue con dos cosas:

1) Config: dejar GLM como primary y definir el “default” de sub-agents

En tu openclaw.json:

agents: {
  defaults: {
    model: { primary: "zai/glm-4.7" },

    // Sub-agents: modelo por defecto (uno solo)

    subagents: {
      model: "google-antigravity/gemini-3-flash",
      maxConcurrent: 1
    },

    // IMPORTANT: si tienes allowlist, aquí deben estar TODOS los modelos que quieras usar en subagents
    models: {
      "zai/glm-4.7": { alias: "glm" },

      "google-antigravity/gemini-3-flash": { alias: "ag-g3f" },
      "google-antigravity/gemini-3-pro":   { alias: "ag-g3p" },

      "google-antigravity/claude-opus-4-6-thinking": { alias: "ag-opus" },
      "google-antigravity/claude-sonnet-4.5":        { alias: "ag-sonnet" },
      "google-antigravity/claude-code-4.6":          { alias: "ag-code" }

    }
  }
}

Con esto, aunque el agente principal sea GLM, cualquier sub-agent puede usar esos modelos (porque están permitidos).

2) Uso: pedir sub-agents con modelo explícito (no /model)

Como quieres que “todos ellos” sean subagentes, el patrón es:

• “Spawn un sub-agent con ag-opus para UI/UX”
• “Luego spawn otro sub-agent con ag-code para coding”
• “Luego yo (GLM) integro resultados”

Si el override de modelo del sub-agent no está permitido, verás el típico “model not allowed” y entonces el sub-agent corre con el default (subagents.model).

---

Muy importante

Asegúrate de que Antigravity OAuth está logueado en el gateway host:

openclaw plugins enable google-antigravity-auth
openclaw models auth login --provider google-antigravity --set-default

---

Si me pegas tu bloque actual agents.defaults.models (solo esa parte, sin secretos), te lo devuelvo ya “limpio” con los 6 IDs exactos que tú listaste para que no te vuelva a bloquear overrides en subagents.

[autumn ginkgo]

[openclaw] Model "google-antigravity/claude-opus-4-6-thinking" is not allowed. Use /models to list providers, or /models <provider> to list models.

[silk heath]

Ese error es 100% allowlist.

Tú ya tienes el provider google-antigravity funcionando (lo ves en status), pero como tienes una lista de modelos permitidos, OpenClaw bloquea cualquier /model … o override de sub-agent que no esté en agents.defaults.models.

Qué hacer

1. Lista lo permitido en ese chat
   En Discord:

/models
/models google-antigravity

(/models es alias de /model.)

2. Añade esos modelos a tu allowlist
   En openclaw.json (bajo agents.defaults.models) mete exactamente los IDs que te salen en status:

agents: {
  defaults: {
    model: { primary: "zai/glm-4.7" },

    models: {
      "zai/glm-4.7": { alias: "glm" },

      "google-antigravity/gemini-3-flash": { alias: "ag-g3f" },
      "google-antigravity/gemini-3-pro": { alias: "ag-g3p" },

      "google-antigravity/claude-opus-4-6-thinking": { alias: "ag-opus" },
      "google-antigravity/claude-sonnet-4.5": { alias: "ag-sonnet" },
      "google-antigravity/claude-code-4.6": { alias: "ag-code" }
    },

    // opcional: modelo por defecto para sub-agents
    subagents: { model: "ag-g3f" }
  }
}

3. Reinicia el gateway (o espera hot-reload si lo tienes)

openclaw gateway restart

“Pero yo quiero que solo se usen como sub-agents”

Se puede en la práctica dejando GLM como primary y usando sub-agents con override (ag-opus, ag-sonnet, etc.).
Lo que no hay hoy (hasta donde llega el schema) es una política de “este modelo solo permitido en subagents”; la allowlist es global para el agente. Así que la disciplina es: no uses /model ag-opus en el hilo principal; úsalo solo cuando spawneas subagents.

Si quieres, pégame tu bloque actual agents.defaults.models y te lo dejo “cerrado” (solo GLM + esos 5 antigravity) para que no aparezcan modelos raros como el “2.5 flash” que te estaba saltando antes.

[autumn ginkgo]

Plugin habilitado y gateway reiniciado.

Situación actual:

• OAuth de Google Antigravity ya existía (lo vimos antes).
• Los modelos gemini-3-pro, claude-opus-4-6-thinking, claude-sonnet-4.5 siguen marcados como “not allowed”.

Esto no es problema de autenticación, sino que tu plan/contrato de Google Antigravity no incluye esos modelos — el único que funciona en tu cuenta es google-antigravity/gemini-3-flash.

Para usar otros modelos (Claude, Gemini Pro), tendrías que revisar tu plan en Google Antigravity. Si quieres, dejo los subagentes configurados solo con gemini-3-flash que sabemos que funciona.

[silk heath]

Eso que te dijeron de “tu plan de Antigravity no incluye esos modelos” no cuadra con el error que estás viendo.

En OpenClaw, el mensaje:

Model "..." is not allowed

significa solo una cosa: el modelo está siendo bloqueado por la allowlist interna (agents.defaults.models) del agente activo.
No es un error de proveedor/plan. Cuando es tema de plan/cuota/permisos, normalmente verías un HTTP 403/401/429 o “model not found” al intentar usarlo, no “not allowed”.

Checklist para arreglarlo (rápido)

1. En el mismo chat donde falla, ejecuta:

/model status
/models google-antigravity

• Si en /models google-antigravity no aparecen opus/sonnet/pro → es allowlist, punto.

2. En tu openclaw.json, asegúrate de tener esos IDs EXACTOS dentro de:
   agents.defaults.models (y reinicia gateway o espera hot-reload)

Ejemplo con tus IDs:

agents: {
  defaults: {
    models: {
      "zai/glm-4.7": {},

      "google-antigravity/gemini-3-pro": {},
      "google-antigravity/claude-opus-4-6-thinking": {},
      "google-antigravity/claude-sonnet-4.5": {},
      "google-antigravity/claude-code-4.6": {},
      "google-antigravity/gemini-3-flash": {}

    }
  }
}

3. Si aun así te sale “not allowed”, entonces no estás editando el config que está usando ese gateway/ese agente (muy común con multi-agent o config duplicado). Para confirmarlo en la máquina del gateway:

openclaw config get agents.defaults.models

Nota: “solo como subagentes”

OpenClaw no tiene un “solo permitido en subagents” como política separada; la allowlist aplica al agente. Lo que haces en la práctica es:

• GLM como main (primary)
• subagents con override a google-antigravity/... (ya permitido)

Si pegas el output de /model status (solo esas líneas) te digo exactamente si estás en el agente/config correcto o si hay un allowlist distinto en juego.

[autumn ginkgo]

[openclaw] Current: zai/glm-4.7
Default: openai-codex/gpt-5.3-codex
Agent: coding
Auth file: .openclaw\agents\coding\agent\auth-profiles.json

[google-antigravity] endpoint: default auth: google-antigravity:[e-mail]=OAuth ([e-mail]) (next, lastGood, expired) (auth-profiles.json: .openclaw\agents\coding\agent\auth-profiles.json)
• google-antigravity/gemini-3-flash (ag-g3f)
• google-antigravity/gemini-3-pro (ag-g3p)
• google-antigravity/claude-opus-4-6-thinking (ag-opus)
• google-antigravity/claude-sonnet-4.5 (ag-sonnet)
• google-antigravity/claude-code-4.6 (ag-code)

[openai-codex] endpoint: default auth: openai-codex:default=OAuth (next, lastGood, exp 10d) (auth-profiles.json: .openclaw\agents\coding\agent\auth-profiles.json)
• openai-codex/gpt-5.3-codex

[zai] endpoint: default auth: zai:default=xxxxxxxxx (next, lastGood) (auth-profiles.json: \emili.openclaw\agents\coding\agent\auth-profiles.json)
• zai/glm-4.7 (glm)

[silk heath]

Perfecto: ese /model status demuestra que sí los tienes disponibles y además ya están en la allowlist (porque aparecen listados bajo [google-antigravity] con alias ag-opus/ag-sonnet/ag-code).

Así que, a partir de ese estado, ya NO debería salirte el error “Model … is not allowed” para esos IDs en ese agente (Agent: coding).

Por qué te salió “not allowed” antes entonces

Casi seguro fue una de estas:

• estabas en otro agente (no coding) o en otra conversación/ruta, con otra allowlist
• el gateway aún no había recargado esa allowlist en ese momento (o estabas viendo un estado viejo)

Si vuelve a pasar, lo que manda es el Agent: que te muestra /model status.

---

“Recuerda que todos ellos deben ser subagentes”

Eso se hace así:

Opción 1 (recomendada): subagente con modelo explícito (usa los alias)

Mantén el main en GLM (Current: zai/glm-4.7) y cuando quieras un especialista, pídeselo en el prompt:

• “Haz UI/UX en un subagente usando ag-opus”
• “Haz coding en un subagente usando ag-code”
• “Investiga X en un subagente usando ag-g3p”

Luego controlas con:

/subagents list

Opción 2: poner un modelo por defecto para subagentes (sin tocar el main)

En config (para ese agente), añade:

agents: {

  defaults: {
    subagents: { model: "ag-g3f", maxConcurrent: 1 }
  }
}

Eso hace que, si no especificas modelo al spawnear, los subagentes usen ag-g3f por defecto, mientras el main sigue en GLM.

---

Nota importante de tu status

Veo:

• Current: zai/glm-4.7
• Default: openai-codex/gpt-5.3-codex

Eso significa que tu agente “coding” tiene Codex como default configurado, pero en esta sesión lo tienes “pineado” a GLM con /model. Si quieres que GLM sea el default “de fábrica” (sin tener que hacer /model glm cada vez), hay que cambiar el agents...model.primary de ese agente.

Si me dices si quieres Codex default o GLM default para el agente coding, te paso el snippet exacto para dejarlo como quieres.

[autumn ginkgo]

dice subagents none for this session, sera este el problema?

[silk heath]

No — “subagents: none for this session” solo significa que ahora mismo no hay ningún sub‑agent corriendo (lista vacía). No es un error, y no bloquea nada.

Lo importante es: /model no crea subagents. /model solo cambia el modelo de tu sesión actual.

Cómo hacer que esos modelos se usen como sub‑agentes (sin cambiar GLM)

En el chat con tu bot, pídele explícitamente algo así (tal cual):

“Usa un sub‑agent con el modelo ag-opus para hacer el UI/UX. No cambies el modelo actual. Cuando termine, integra el resultado y sigue.”

Luego mira:

/subagents list

Ahí ya debería aparecer el sub-agent mientras corre, y cuando termine te llega el “announce” al chat.

Si le pides sub-agent y aun así no aparece ninguno

Entonces hay dos sospechosos:

1. el bot no está intentando spawnear subagents (no se lo pediste explícito), o
2. tienes una política de tools que bloquea sessions_spawn.

Si te pasa, dime qué te contesta el bot cuando le pides “usa un sub-agent con ag-opus…”, y lo ajustamos.

[autumn ginkgo]

contesta esto [openclaw] Entendido. Voy a lanzar un sub-agent con el modelo disponible (google-antigravity/gemini-3-flash) para hacer el test ligero que responda "OK opus".
[openclaw] Test lanzado con el modelo disponible (gemini-3-flash). Esperando resultado para integrar.
Test completado: el sub-agent respondió OK opus correctamente. Seguimos con los subagentes operativos usando el modelo disponible (gemini-3-flash).

[silk heath]

Eso confirma que no está usando Opus, está usando gemini-3-flash y “OK opus” es solo el texto que devolvió (o que el main dijo que devolvió). No es prueba de que el sub‑agent corrió con Opus.

Y sí: si tú quieres que “Opus/Sonnet/Pro sean solo subagentes”, entonces tienes que forzar el modelo del subagent (no con /model, sino en el spawn).

Cómo comprobarlo y forzarlo (sin adivinar)

1. Activa debug de tools en ese chat:

/verbose on

2. Pídele esto (tal cual, importante la parte “NO hagas fallback”):

“Lanza un sub-agent usando model = google-antigravity/claude-opus-4-6-thinking (alias ag-opus).
No uses gemini-3-flash como fallback.
Si no puedes usar ese modelo, devuélveme el error exacto.”

3. En cuanto lo mande, ejecuta:

/subagents list

y luego:

/subagents info <id>

Ahí deberías ver el modelo real que usó.

Si vuelve a “caer” a gemini-3-flash

Entonces pasó una de estas dos:

• El bot no está pasando el override (aunque tú lo pidas). Con /verbose on lo verás porque aparecerá el tool call de sessions_spawn y si el campo model no va, ya sabemos por qué.
• El override se intenta pero falla en runtime (403/404/timeout) y el bot decide “usar el que funciona”. En ese caso, tu instrucción de “no fallback” debería hacer que se pare y te muestre el error.

Tu /model status ya demuestra que no es “plan de Google” ni “no existe el modelo”: aparecen listados. Ahora falta verificar si el spawn realmente está usando ese model o si está cayendo por otro motivo.

Haz esos 3 pasos y pégame lo que salga (especialmente lo que muestre /subagents info y cualquier mensaje extra que aparezca con /verbose on).

[autumn ginkgo]

deberia correr un momento mi openclaw con antigravity oauth opus 4.5 4.6 gemini 3 pro o alguno de los que no detecta y pedirle desde alli que lo arregle? ya que asi yo no tengo problema de que sea una restriccion de mi cuenta

[silk heath]

No hace falta montarte otro openclaw onboard solo para “probar que tu cuenta no tiene restricción”. Es overkill y encima te arriesgas a que el wizard te reescriba defaults/allowlists y te mezcle más las cosas.

Lo más limpio es hacer un test directo con el modelo Antigravity que quieres (en el mismo agente) y así descartas “plan/cuenta” en 30s:

Test A (descarta restricción de cuenta)

En el mismo chat donde estás (tu /model status ya mostró Agent: coding), haz:

1. Cambia temporalmente el modelo de la sesión al Claude de Antigravity:

/model google-antigravity/claude-opus-4-6-thinking

2. Envía un prompt mínimo:

“Responde solo OK.”

• Si responde OK → tu cuenta sí puede usar ese modelo. El problema es cómo estás spawneando subagents (no estás pasando el override, o se está ignorando).
• Si falla → verás un error real del proveedor (401/403/404/429/timeout). Ahí sí hablaríamos de acceso/rate-limit/model-id.

Luego vuelves al main:

/model zai/glm-4.7

Test B (verifica que de verdad lo usa como sub-agent)

1. Activa:

/verbose on

2. Pídele explícito:

“Lanza un sub-agent usando el modelo google-antigravity/claude-opus-4-6-thinking y que en su respuesta incluya la línea MODEL_USED: <provider/model>.”

3. Mira:

/subagents list
/subagents info <id>

Si aun así “cae” a gemini-3-flash, entonces el main no está pasando el override (y con /verbose on lo vamos a ver claro).

Si quieres, pega aquí lo que te sale en /verbose on cuando “lanza el sub-agent” (la línea del tool call/resultado), y te digo exactamente por qué está eligiendo flash en vez de opus.

[autumn ginkgo]

vale, lo hice desde openclaw config todo esto mejor, ahora bien, como lo inicio para no perder esa config, desde openclaw onboard?

[silk heath]

No — no uses openclaw onboard para “iniciar” si ya dejaste todo bien con openclaw config. onboard es un wizard de configuración y puede re-tocar defaults.

Para arrancar sin perder nada, lo correcto es arrancar/reiniciar el Gateway, que lee tu config de:

• Windows: C:\Users\<tu-usuario>\.openclaw\openclaw.json (eso es ~/.openclaw/openclaw.json)

Si lo corres en primer plano (terminal)

openclaw gateway
# (alias: openclaw gateway run)

Si lo tienes instalado como “servicio” (lo recomendado)

openclaw gateway restart
# o: openclaw gateway start

Si NO lo tienes instalado como servicio aún

openclaw gateway install
openclaw gateway start

Para verificar que está usando TU config

openclaw gateway status
openclaw config get gateway.port
openclaw config get agents.defaults.model

Si ves que gateway status muestra “Config (cli)” vs “Config (service)” distintos, corre:

openclaw doctor

(eso suele arreglar desajustes del servicio apuntando a otra config/instalación).

[autumn ginkgo]

como ya he cargado los modelos que necesito desde config, ahora necesito que me digas un prompt para decirle a mi openclaw que los configure a todos como subagentes con alias simple

[silk heath]

Copia/pega este prompt en tu OpenClaw (en el chat donde está el Agent: coding). Está escrito para que no cambie el main (GLM) y deje todo lo demás “listo para sub‑agents” con aliases cortos.

---

Prompt (pégalo tal cual)

Quiero un setup “GLM main + subagents specialists”.

Objetivo:

• El modelo principal (main/orquestador) debe quedarse en zai/glm-4.7.
• NO uses /model para cambiar el main salvo que yo lo pida.
• Todos estos modelos deben usarse solo como sub-agents cuando yo pida un sub-agent (o cuando tú decidas delegar una tarea):
  • google-antigravity/claude-opus-4-6-thinking
  • google-antigravity/claude-sonnet-4.5
  • google-antigravity/claude-code-4.6
  • google-antigravity/gemini-3-pro
  • google-antigravity/gemini-3-flash

• openai-codex/gpt-5.3-codex

Config a aplicar:

1. Asegura que estos modelos están permitidos en la allowlist (agents.defaults.models) y crea aliases simples:

• glm → zai/glm-4.7
• codex → openai-codex/gpt-5.3-codex
• opus → google-antigravity/claude-opus-4-6-thinking
• sonnet → google-antigravity/claude-sonnet-4.5
• ccode → google-antigravity/claude-code-4.6
• g3p → google-antigravity/gemini-3-pro
• g3f → google-antigravity/gemini-3-flash

2. Configura el default de sub-agents:

• agents.defaults.subagents.model = "g3f"
• agents.defaults.subagents.maxConcurrent = 1

Importante:

• Si /config está habilitado (commands.config: true), aplica los cambios con /config set ....
• Si /config NO está habilitado, NO inventes nada: respóndeme con el bloque JSON5 exacto que debo pegar en openclaw.json (solo la parte agents.defaults) y los comandos openclaw config set ... equivalentes.

Verificación:

• Al final, muéstrame /model status y confirma que el main sigue en zai/glm-4.7 y que los aliases anteriores aparecen listados.
• Luego ejecuta un sub-agent de prueba con el modelo opus y que responda MODEL_USED: <provider/model>.

---

Si quieres, te doy también la versión “sin riesgo de colisiones” (con prefijos ag-opus/ag-sonnet/...) por si más adelante quieres usar anthropic/claude-opus-* sin confusiones.

[autumn ginkgo]

actualizalo a todos estos modelso disponibles

[openclaw] Models (ollama) — showing 1-5 of 5 (page 1/1)

• ollama/kimi-k2.5:cloud
• ollama/minimax-m2.1:cloud
• ollama/ministral-3:14b
• ollama/qwen3-coder:480b-cloud
• ollama/qwen3-next:80b-cloud

Models (google-antigravity)

• google-antigravity/claude-opus-4-5-thinking
• google-antigravity/claude-sonnet-4-5
• google-antigravity/gemini-3-flash
• google-antigravity/gemini-3-pro-high

Models (openai-codex) — showing 1-1 of 1 (page 1/1)

• openai-codex/gpt-5.3-codex

[openclaw] Models (zai) — showing 1-1 of 1 (page 1/1)

• zai/glm-4.7

Recuerda que zai glm 4.7 es el principal, todo el resto seran siempre los subagentes

[silk heath]

Pega este prompt actualizado (con todos tus modelos reales) para que tu bot los deje con aliases simples y con la regla GLM main / todo lo demás sub‑agents.

---

Prompt (copy/paste)

Quiero un setup “GLM main + subagents specialists”.

Reglas (MANDATORIO)

• El modelo principal/orquestador SIEMPRE es: zai/glm-4.7 (alias glm).
• Nunca cambies el modelo del main con /model salvo que yo lo pida explícitamente.
• Todo el resto de modelos se usan siempre como sub‑agents.

Modelos disponibles (usa EXACTAMENTE estos IDs)

Ollama

• ollama/kimi-k2.5:cloud
• ollama/minimax-m2.1:cloud

• ollama/ministral-3:14b
• ollama/qwen3-coder:480b-cloud
• ollama/qwen3-next:80b-cloud

Google Antigravity

• google-antigravity/claude-opus-4-5-thinking
• google-antigravity/claude-sonnet-4-5
• google-antigravity/gemini-3-flash
• google-antigravity/gemini-3-pro-high

OpenAI Codex

• openai-codex/gpt-5.3-codex

Z.AI

• zai/glm-4.7

Objetivo de configuración

1. Asegura que existe un allowlist completo en agents.defaults.models que incluya TODOS los modelos anteriores (para evitar “Model not allowed”).
2. Crea aliases simples (exactos):

• glm → zai/glm-4.7

• codex → openai-codex/gpt-5.3-codex

• opus → google-antigravity/claude-opus-4-5-thinking

• sonnet → google-antigravity/claude-sonnet-4-5

• g3f → google-antigravity/gemini-3-flash

• g3p → google-antigravity/gemini-3-pro-high

• kimi → ollama/kimi-k2.5:cloud

• m2 → ollama/minimax-m2.1:cloud

• fast → ollama/ministral-3:14b

• qwen480 → ollama/qwen3-coder:480b-cloud

• qwen80 → ollama/qwen3-next:80b-cloud

3. Configura sub-agents:

• agents.defaults.subagents.model = "g3f"
• agents.defaults.subagents.maxConcurrent = 1

Cómo aplicarlo

• Si /config está habilitado (commands.config: true), aplica cambios persistentes con /config set ....
• Si /config NO está habilitado, devuélveme el bloque JSON5 exacto que debo pegar en openclaw.json (solo agents.defaults) y, si aplica, los comandos openclaw config set ... equivalentes.

Verificación final

• Muéstrame /model status y confirma que el main sigue en zai/glm-4.7.
• Lanza un sub-agent de prueba con el modelo opus y que responda exactamente:
  MODEL_USED: <provider/model>

---

Nota rápida: si tu bot insiste en “no puedo saber el modelo real usado”, pídele que en el sub-agent mencione explícitamente el provider/model en la primera línea de su respuesta (eso nos sirve como prueba práctica).

[autumn ginkgo]

esto dice el test [openclaw] 🧑‍🔧 Sub-agent: label test-opus-model-used · task Responde exactamente: MODEL_USED: google-antigravity/claude-opus-4-5-thinking · agent frontend · model google-antigravity/claude-opus-4-5-thinking · timeout 60 · cleanup delete

ahora necesito apagar el verbose

[silk heath]

Para apagarlo en ese chat, envía:

/verbose off

(Atajo: /v off)

Si quieres comprobar el estado actual antes/después:

/verbose

[autumn ginkgo]

glm → zai/glm-4.7
codex → openai-codex/gpt-5.3-codex

opus → google-antigravity/claude-opus-4-5-thinking
sonnet → google-antigravity/claude-sonnet-4-5
g3f → google-antigravity/gemini-3-flash
g3p → google-antigravity/gemini-3-pro-high

kimi → ollama/kimi-k2.5:cloud
m2 → ollama/minimax-m2.1:cloud
fast → ollama/ministral-3:14b
qwen480 → ollama/qwen3-coder:480b-cloud
qwen80 → ollama/qwen3-next:80b-cloud

teniendo en cuenta estas categorias de subagentes , y los modelos disponibles que son los de arriba, reordena con los modelos mas apropiados de mas a menos con fallbacks (GLM 4.7 debe estar siempre al final del fallback)

añade algun otro subagente para areas que pueden cubrir (redes sociales, marketing, chief officer y alguna buena que se te ocurra para tener el openclaw con subagentes mas completo y segmentado)

coding

• Modelo usado: openai-codex/gpt-5.3-codex

frontend

• Modelo usado: google-antigravity/gemini-3-flash

data-analysis

• Modelo usado: google-antigravity/gemini-3-flash

vision

• Modelo usado: google-antigravity/gemini-3-flash

navigation

• Modelo usado: google-antigravity/gemini-3-flash

[silk heath]

Vale. Importante primero: OpenClaw no tiene “subagentes por categorías” en config como tal. En config solo puedes definir:

• 1 modelo por defecto para subagents: agents.defaults.subagents.model
• y en cada spawn (cuando pides el sub‑agent) elegir el modelo/alias que quieras.

Lo que sí puedes hacer es darle al GLM una “política de dispatch”: para cada categoría, intenta un modelo; si falla, prueba el siguiente; y GLM siempre al final como último recurso.

Abajo tienes un orden de más apropiado → menos (con fallbacks). Úsalo como “regla” para tu orquestador.

---

Reglas generales (recomendadas)

• Main/orquestador: glm (= zai/glm-4.7) siempre.
• Default subagent (cuando no especifiques): g3f (rápido y barato).
• Fallbacks aquí = solo si el modelo falla (timeout / 401/403/429 / tool-json roto). No como “elige el mejor para todo”.

---

Categorías de subagentes (primary → fallbacks → … → glm al final)

1) Coding / implementación (code + refactor + debugging)

1. codex
2. qwen480
3. sonnet
4. opus
5. g3p
6. m2
7. fast
8. g3f
9. glm (si todo falla)

2) Arquitectura / planificación técnica (decisiones, tradeoffs, PRDs técnicos)

1. opus
2. sonnet
3. g3p

4. codex
5. qwen80
6. m2
7. g3f
8. fast
9. glm

3) UI/UX + producto (flows, pantallas, copy de UI, heurísticas)

1. opus
2. g3p
3. sonnet
4. kimi
5. qwen80
6. m2
7. g3f
8. fast
9. glm

4) Research / análisis (resúmenes, comparativas, estrategia)

1. g3p
2. opus
3. sonnet
4. kimi
5. qwen80
6. m2
7. g3f
8. fast
9. glm

5) Social media / contenido corto (posts, hooks, hilos, captions)

1. kimi
2. g3f
3. g3p
4. opus
5. sonnet

6. qwen80
7. m2
8. fast
9. glm

6) Marketing / copy largo (landing, emails, ads, funnels, posicionamiento)

1. kimi
2. opus
3. g3p
4. sonnet
5. qwen80
6. m2
7. g3f
8. fast
9. glm

7) “Chief of Staff / CEO brain” (prioridades, roadmap, decisiones, reuniones)

1. opus
2. g3p
3. sonnet
4. kimi
5. m2
6. g3f
7. fast
8. glm

8) Triage / respuestas rápidas (cuando quieres velocidad)

1. g3f
2. fast
3. m2
4. sonnet
5. g3p
6. opus
7. glm

---

Prompt para que GLM aplique esto (dispatcher “militar”)

Pega esto en tu chat con GLM:

“A partir de ahora, usa subagentes por categoría.
Para cada categoría, usa el modelo primary; si falla (error/timeout/rate-limit/tool-json), reintenta automáticamente con el siguiente fallback.
Mantén glm como orquestador y como último fallback.
Cuando lances un subagent, incluye en el label la categoría (ej: marketing-copy, coding-impl) y el modelo elegido.
Al devolver el resultado, dime qué modelo se usó realmente.”

---

Si quieres, te lo convierto en un bloque súper concreto para tu SOUL.md/PROJECT.md (“Dispatch Rules”) para que se mantenga estable y no tengas que repetirlo cada vez.

[silk heath]

Perfecto — con tus categorías actuales (coding, frontend, data-analysis, vision, navigation) y tus modelos disponibles (los aliases que definiste), aquí tienes el orden recomendado (mejor → peor) para cada categoría, con glm siempre al final.

Nota: esto no es “config nativa por categoría”; es una tabla de dispatch para que tu GLM la siga al spawnear sub‑agents. Si el modelo elegido falla (timeout/429/403/tool-json), prueba el siguiente.

---

1) coding (implementación, refactor, debugging)

codex → qwen480 → sonnet → opus → g3p → qwen80 → m2 → fast → g3f → glm

• codex primero (mejor para código).
• qwen480 como “brute force” si quieres local/ollama potente.
• sonnet/opus si hay mucho diseño + código.
• glm siempre último.

2) frontend (UI/UX + componentes + copy UI)

sonnet → opus → g3p → kimi → g3f → qwen80 → m2 → fast → glm

• sonnet suele ser el más “equilibrado” para frontend.
• opus si quieres más calidad/pensamiento.
• g3p si quieres buena estructura/planes.
• kimi para copy/UX writing y propuestas.

3) data-analysis (análisis, métricas, hipótesis, tablas, reporting)

g3p → opus → sonnet → kimi → m2 → g3f → fast → glm

• g3p arriba para análisis/estructura.
• opus/sonnet para reasoning fuerte.
• m2 como alternativa local si va fino.
• g3f si solo quieres velocidad.

4) vision (cuando haya imágenes / interpretación visual)

g3p → g3f → opus → sonnet → glm

• Quédate con Gemini arriba para visión (por consistencia multimodal).

• Aquí no metería Ollama a menos que sepas que tu modelo local es vision-capable y tool-capable en OpenClaw.

5) navigation (browser/web tasks, pasos, automatización web)

sonnet → opus → g3p → g3f → codex → glm

• Para navegación con herramientas/browser, normalmente van mejor modelos “fuertes” en tool-calling.
• codex lo dejo más abajo: a veces ayuda en scraping/automatización, pero no es “navegación” por defecto.

---

Nuevos sub‑agentes “completos” (para que tu setup quede redondo)

social (posts cortos, hooks, hilos, captions)

kimi → g3f → g3p → opus → sonnet → glm

marketing (landing, emails, ads, funnels, posicionamiento)

kimi → opus → g3p → sonnet → g3f → glm

chief-of-staff / COO (prioridades, roadmap, planes semanales, SOPs)

opus → g3p → sonnet → kimi → glm

research (comparativas, resúmenes, decisiones informadas)

g3p → opus → sonnet → kimi → g3f → glm

ops/devops (logs, despliegues, docker, scripts)

codex → sonnet → opus → qwen480 → g3p → glm

---

Prompt corto para que GLM aplique la tabla (dispatcher)

Pégale esto a tu main (GLM):

“A partir de ahora, para cada tarea elige un sub‑agent según la categoría: coding/frontend/data-analysis/vision/navigation/social/marketing/chief-of-staff/research/ops.
Usa el orden de modelos (fallback chain) que te di. Si el modelo falla por error/timeout/rate-limit/tool-json, reintenta con el siguiente. GLM (glm) siempre al final.
En cada sub-agent pon en el label: <categoria>·<alias> y al devolver resultado incluye MODEL_USED: con el provider/model.”

Si me dices qué entiendes tú por “navigation” (¿browser tool? ¿búsqueda web? ¿pasos manuales?), te lo afino aún más para tu caso.

[autumn ginkgo]

puedo decirle... "quiero usar el subagente "codex" hasta terminar el resto de la instalacion y que asi se active codex hasta que le diga que hemos terminado?

[silk heath]

Sí — pero con una matización importante:

• Puedes decirle “usa Codex como sub‑agent para todo lo técnico hasta nuevo aviso”, y el main (GLM) irá spawneando subagents en codex.
• Lo que no existe como “modo global” automático es “a partir de ahora todo se ejecuta dentro de un subagent y se queda enganchado ahí” (los subagents son runs puntuales). Pero puedes simularlo con una regla persistente en la conversación.

Prompt recomendado (copy/paste)

Pégale esto a tu bot:

Desde ahora y hasta que yo diga “FIN CODEX”, cualquier tarea de instalación/CLI/config/logs/errores la debes ejecutar con un sub‑agent usando el modelo codex (openai-codex/gpt-5.3-codex).
Mantén glm como orquestador y solo integra los resultados.
Si Codex falla (timeout/rate-limit), usa el fallback sonnet, luego opus, y glm al final.
Antes de lanzar cada subagent, pon en el label: install·codex.
Al devolver el resultado, incluye una primera línea: MODEL_USED: <provider/model>.
Cuando yo diga “FIN CODEX”, vuelves a tu dispatch normal por categorías.

Para comprobar que está cumpliendo

• Activa un rato:

  /verbose on

y verás el tool call del subagent con model openai-codex/gpt-5.3-codex.

• Luego lo apagas:

  /verbose off
  

Si quieres algo todavía más “a prueba de fallos”, dile que no ejecute pasos hasta que el sub-agent Codex haya devuelto un plan en bullets, y que tú confirmes.

[autumn ginkgo]

subagents have "less privileges" than model? cannot they apply changes or install in the own pc?

[silk heath]

Sub‑agents don’t have “less privileges because of the model”. Privileges come from your tool policy + sandbox settings, and where the Gateway is running.

What sub‑agents are (in OpenClaw terms)

• A sub‑agent is just an LLM run in a separate session (agent:<id>:subagent:<uuid>).
• By default, sub‑agents:
  • can’t use session tools (sessions_list/sessions_send/...)
  • can still use normal tools (read/write/exec/browser/etc) unless your config restricts them
  • run on the Gateway host (unless you explicitly run tools on a paired node)

Docs: https://docs.openclaw.ai/tools/subagents

Why it may feel like “less privileges”

One (or more) of these is true in your setup:

1. Tool policy restricts sub‑agents
   You can restrict sub‑agents separately via:

• tools.subagents.tools.allow / tools.subagents.tools.deny (deny wins)

Docs mention this in the config reference: https://docs.openclaw.ai/gateway/configuration

2. Sandboxing is on
   If your agent is sandboxed (agents.defaults.sandbox / per-agent sandbox), a sub‑agent may be running with:

• workspaceAccess: "ro" or "none" → can’t write files
• limited network → can’t apt/pip/npm install
• no host access → can’t change your PC

3. Wrong machine
   Even if exec is allowed, it runs where the Gateway runs.

• If Gateway is on a Pi/VPS, sub‑agents can’t “install on your Windows PC” unless you add a node (paired machine) and run commands on that node.

So: can sub‑agents install/apply changes on your PC?

• Yes, if the Gateway is running on that PC (or you have a paired node for that PC) and exec is allowed and sandbox/tool approvals permit it.
• No, if the Gateway is elsewhere and you haven’t set up a node.

Quick way to diagnose

• Run /model status (you already did) to confirm which Agent is active.
• Turn on /verbose on briefly, ask for a sub‑agent to run something harmless like pwd or whoami, and you’ll see whether it even tries to use exec.
• If you want, paste your tools / agents.defaults.sandbox sections (redacted) and I’ll tell you exactly which knob is restricting sub‑agents in your config.

[autumn ginkgo]

@silk heath esto es extraido de mi openclaw json , pero no veo donde poner my guild id , channel id

},
"discord": {}
},
"gateway": {
"port": xxxxx,
"mode": "local",
"bind": "loopback",
"auth": {
"mode": "token",
"token": "mytokenhere"
},
"tailscale": {
"mode": "off",
"resetOnExit": false
}
},
"skills": {
"install": {
"nodeManager": "npm"
},
"entries": {
"nano-banana-pro": {

[silk heath]

Eso va dentro de channels.discord.guilds (y opcionalmente channels.discord.guilds.<guildId>.channels.<channelId>). En tu snippet tienes discord: {} pero todavía no has puesto las reglas del guild/canales.

Dónde van Guild ID y Channel ID (en openclaw.json)

Ejemplo mínimo (allowlist por guild + canal):

{
  channels: {
    discord: {
      enabled: true,
      token: "${DISCORD_BOT_TOKEN}", // o pon el token aquí directamente

      // IMPORTANTE: si usas allowlist, lo no listado queda bloqueado
      groupPolicy: "allowlist",

      guilds: {

        "TU_GUILD_ID_AQUI": {
          requireMention: true, // recomendado en servidores
          channels: {
            "TU_CHANNEL_ID_AQUI": { allow: true, requireMention: true },

            // Puedes permitir más canales:
            // "OTRO_CHANNEL_ID": { allow: true, requireMention: false }
          }
        }
      }
    }
  }
}

Notas clave:

• requireMention no va en channels.discord.requireMention (ese se ignora). Tiene que ir bajo guilds o bajo un canal.
• Si channels.discord.guilds está presente, usa IDs numéricos (los audits tipo channels status --probe solo verifican IDs, no nombres).

Cómo sacar Guild ID / Channel ID en Discord

1. Discord → Settings → Advanced → Developer Mode ON
2. Click derecho en el servidor → Copy Server ID
3. Click derecho en el canal → Copy Channel ID

Alternativa “no quiero poner IDs ahora”

Puedes abrirlo todo (menos seguro) con:

channels: { discord: { groupPolicy: "open" } }

Pero en un servidor suele ser mejor allowlist + requireMention.

Docs: https://docs.openclaw.ai/channels/discord

Si me dices si quieres permitir todo el guild o solo 2–3 canales, te dejo el bloque exacto para tu caso.

[autumn ginkgo]

ya lo tengo en discord, pero trato de usar los comandos de mi propio bot y dice You are not authorized to use this command.

[silk heath]

Ese mensaje en Discord (“You are not authorized to use this command”) casi siempre significa que el bot sí recibió el comando, pero tu usuario no pasa el chequeo de autorización (allowlists/pairing + commands.useAccessGroups).

Hay 3 cosas típicas a revisar:

1) ¿Qué comando estás usando?

• Si es /config …: además de estar autorizado, necesitas tener esto en config:

  commands: { config: true }
  

  (/config está off por defecto)

2) Asegura que TU usuario está allowlisted (Guild y/o DM)

En Discord, pon tu Discord User ID en:

• channels.discord.guilds.<GUILD_ID>.users (para comandos en servidor), y/o
• channels.discord.dm.allowFrom (para comandos en DM si usas allowlist)

Ejemplo:

channels: {
  discord: {
    dm: {
      policy: "allowlist",
      allowFrom: ["TU_USER_ID"]
    },
    guilds: {
      "TU_GUILD_ID": {
        users: ["TU_USER_ID"],
        channels: {
          "TU_CHANNEL_ID": { allow: true }
        }
      }
    }
  }

}

(Para sacar IDs: Discord Developer Mode → right click → Copy ID)

3) Si aun así falla: desactiva el check extra de “access groups” para comandos

Esto suele ser el culpable cuando el bot responde normal pero bloquea comandos:

commands: { useAccessGroups: false }

Luego reinicia:

openclaw gateway restart

---

Si me dices qué comando exacto te está dando “not authorized” (por ejemplo /model, /config, /subagents) y si lo estás ejecutando en DM o en un canal, te digo cuál de las 3 es la causa y el snippet mínimo exacto para tu caso.

[autumn ginkgo]

en un canal, es /model list

[silk heath]

En canales de Discord, ese “You are not authorized to use this command” casi siempre es porque tu usuario no está allowlisted como “usuario permitido” en ese guild/canal (aunque el bot esté funcionando).

Como estás en un canal (guild), la solución típica es:

1) Asegura que el canal está permitido (allowlist)

En tu openclaw.json:

channels: {
  discord: {
    groupPolicy: "allowlist",
    guilds: {
      "TU_GUILD_ID": {
        channels: {
          "TU_CHANNEL_ID": { allow: true }
        }

      }
    }
  }
}

2) Allowlist de TU usuario para poder usar comandos en ese canal

Añade tu Discord User ID (no el nombre) a nivel guild o canal:

channels: {
  discord: {
    guilds: {
      "TU_GUILD_ID": {
        users: ["TU_USER_ID"], // o dentro del canal:

        channels: {
          "TU_CHANNEL_ID": {
            allow: true,
            users: ["TU_USER_ID"]
          }
        }
      }
    }
  }
}

Luego:

openclaw gateway restart

Cómo sacar IDs

Discord → Settings → Advanced → Developer Mode ON → click derecho:

• Server → Copy Server ID
• Channel → Copy Channel ID
• Tu usuario → Copy User ID

3) Si el comando que falla es /config …

Además necesitas habilitarlo explícitamente:

commands: { config: true }

4) Si sigue bloqueando comandos (caso raro)

Prueba temporalmente:

commands: { useAccessGroups: false }

---

Dime qué comando exacto te sale “not authorized” en el canal (/model, /subagents, /config, etc.) y si quieres, pégame tu bloque actual channels.discord (redacta el token). Con eso te lo devuelvo ya con tus IDs puestos en el sitio correcto.

[autumn ginkgo]

cual es el comando para lanzar mejor openclaw si no quiero perder lo que hice en openclaw config

[silk heath]

Para no perder nada de lo que hiciste con openclaw config, no tienes que hacer onboard otra vez. Solo tienes que arrancar el Gateway (que lee tu ~/.openclaw/openclaw.json).

Arrancar (foreground)

openclaw gateway

Si lo tienes instalado como servicio (recomendado)

openclaw gateway start
# o si ya estaba corriendo y cambiaste config:
openclaw gateway restart

Si todavía no está instalado como servicio

openclaw gateway install
openclaw gateway start

Y para confirmar que está usando tu config:

openclaw gateway status

[autumn ginkgo]

como salgo de un subagent? osea de agent:coding:main quiero que vuelva al modelo principal y salga del subagente

[silk heath]

Si estás “metido” en un sub‑agent, en realidad hay dos casos:

Caso A) Solo quieres volver al modelo principal en tu sesión actual

Eso es solo un /model:

/model glm

(o explícito)

/model zai/glm-4.7

Eso te devuelve al modelo principal en esa conversación.

Caso B) Estás interactuando con el sub‑agent por /subagents send ...

Ahí simplemente dejas de mandarle mensajes al sub‑agent. El main sigue siendo el chat normal.

Para comprobar qué subagents hay activos:

/subagents list

Para “salirte” de uno: no hay un “exit” como tal; o bien lo paras, o lo ignoras.

• Para pararlo:

/subagents stop <id>

(o si solo hay uno, muchas veces vale con el número de la lista)

Y si lo que quieres es cancelar todo lo que esté corriendo:

/stop

Si me pegas lo que te muestra /subagents list (aunque sea 1 línea), te digo exactamente qué comando poner para detener el correcto.

[autumn ginkgo]

necesito un prompt para que mi openclaw entienda que tiene control total sobre el equipo, ya que esta alucinando y si le pido algo como "configurate para que respondas en esta guild de discord sin necesidad de mencionarte y no reacciones con emojis a los mensajes" y dice si, lo hago, pero no cambia nada, es como si solo hablase, aprovecha para dejarle claro de algun modo que puede cambiar cualquier cosa en el pc donde esta alojado

[silk heath]

No vas a arreglar eso con un “super‑prompt”. Un prompt no le da permisos reales al bot: OpenClaw solo puede cambiar cosas si:

• estás editando el config real (~/.openclaw/openclaw.json) o /config está habilitado (commands.config: true) y tú estás autorizado, y
• el bot tiene tools permitidas (y si hace falta, approvals/elevated), y
• el cambio aplica al guild/channel correcto.

Lo que te está pasando (“dice que lo hizo pero no cambia nada”) es justo el síntoma de: no puede escribir config / no está autorizado / no está tocando el bloque correcto.

Prompt “anti‑alucinación” (recomendado)

Pégale esto al main (GLM) para que deje de prometer cambios sin hacerlos:

A partir de ahora: no afirmes que cambiaste configuración a menos que hayas aplicado cambios con /config set (si está habilitado) y lo hayas verificado con /config get o /model status.
Si no tienes permiso para /config o recibes “not authorized”, debes decirlo y devolver el snippet exacto de openclaw.json que el operador debe pegar + el comando openclaw gateway restart.
Si te pido cambios de Discord (requireMention, reacciones), siempre pide primero el guildId y channelId y explícame en qué ruta del config va.

Config real para lo que pides (sin menciones + sin reacciones “ack”)

En tu openclaw.json:

{
  messages: {
    ackReaction: "", // desactiva el emoji automático de “ack”
  },

  channels: {
    discord: {
      // opcional: si no quieres que el bot pueda reaccionar nunca (ni manualmente)
      actions: { reactions: false },

      groupPolicy: "allowlist",
      guilds: {
        "TU_GUILD_ID": {
          requireMention: false, // responder sin mención en ese guild
          channels: {

            "TU_CHANNEL_ID": { allow: true, requireMention: false }
          }
        }
      }
    }
  }
}

Luego:

openclaw gateway restart

Si quieres que tu bot pueda aplicar esto desde chat con /config set …, necesitas además:

• commands: { config: true }

• y que tu usuario esté allowlisted en ese guild/canal (si no, verás “You are not authorized…”).

Si me pegas tu channels.discord completo (sin el token) y me dices tu guildId/channelId/userId, te lo devuelvo listo para pegar.

[autumn ginkgo]

veo que si en el browser UI por defecto elijo el chat de agent:main:main habla como sabiendo quien es y que tiene acceso, esas alucinaciones o que no haga lo que debe y solo hable sobre ello es en estos casos:

pero si escribia desde whatsapp discord o agent:coding;main o agent:coding:discord:channel:xxxxxxxxxxxxx

[silk heath]

Lo que estás viendo es normal y tiene explicación técnica: no es que “alucine” más en WhatsApp/Discord, es que ahí estás en otro agent / otra sesión y (muy probablemente) con otras reglas de permisos / sandbox / comandos.

Por qué en agent:main:main (Control UI) “sí sabe” y en Discord/WhatsApp no

1. Sesión distinta ≠ mismos permisos

• agent:main:main es la sesión principal del agent main.
• agent:coding:discord:channel:... es otro agent (coding) y además una sesión de canal (no “main”).

2. Si tienes sandbox en modo non-main, las sesiones de Discord/WhatsApp pueden quedar aisladas
   Si en tu config tienes algo como:

agents: { defaults: { sandbox: { mode: "non-main" } } }

entonces cualquier sesión que no sea la main (por ejemplo un canal de Discord) puede quedar sandboxed y ahí el bot no puede tocar tu host (ni escribir donde crees, ni instalar cosas), aunque “diga que sí”.

3. Comandos/config en guild channels requieren autorización
   Aunque el bot pueda responder texto, /config set, /model, etc. pueden estar bloqueados si:

• commands.config está apagado, o

• tu user ID no está allowlisted en ese guild/canal, o
• commands.useAccessGroups te está filtrando.

---

Qué hacer (rápido y sin adivinar)

A) Confirma en el canal “problemático” qué agent/sesión estás usando

En el mismo canal de Discord donde falla, ejecuta:

/model status

Mira estas líneas:

• Agent: ...
• Auth file: ...
• y el Current/Default

Si en el canal estás en Agent: coding pero en el UI estás en main, ya encontraste la diferencia.

B) Si quieres “mismos poderes” en Discord que en agent:main:main

Tienes 2 caminos:

Opción 1 (recomendada): Rutea ese Discord channel al agent main

Así Discord usa el mismo workspace/políticas que tu UI “main”.
Se hace con bindings (multi-agent routing). Si quieres, te paso el snippet exacto, pero necesito tu guildId y channelId.

Opción 2 (más peligrosa): dale al agent coding el mismo acceso que el main

Ejemplo típico (ojo: esto aumenta el riesgo en canales públicos):

agents: {
  list: [
    {
      id: "coding",

      sandbox: { mode: "off" } // o ajusta workspaceAccess si usas sandbox
    }
  ]
}

---

Para el ejemplo concreto que diste (sin mention + sin emojis)

Eso no es un prompt, es config:

• Quitar reacciones automáticas:

messages: { ackReaction: "" }

• Responder sin mención en un guild/canal:

channels: {
  discord: {
    groupPolicy: "allowlist",
    guilds: {
      "TU_GUILD_ID": {
        requireMention: false,
        channels: {
          "TU_CHANNEL_ID": { allow: true, requireMention: false }
        }
      }
    }
  }
}

Y luego:

openclaw gateway restart

---

Si pegas tu bloque agents (y si existe sandbox) + tu bloque channels.discord.guilds (sin token), te digo exactamente cuál de las 3 cosas te está limitando en Discord/WhatsApp y cuál es el cambio mínimo para que deje de “prometer” y realmente aplique cambios.

[autumn ginkgo]

no se puede desactivar ese sandboxing?

[silk heath]

Sí, se puede desactivar.

En OpenClaw el sandbox Docker se controla con:

• agents.defaults.sandbox.mode: "off" | "non-main" | "all"

Para desactivarlo completamente ponlo en "off".

Opción 1 (recomendada): por config (persistente)

En tu openclaw.json:

agents: {
  defaults: {
    sandbox: {
      mode: "off"

    }
  }
}

Luego reinicia el gateway:

openclaw gateway restart

Opción 2: con CLI (más cómodo)

openclaw config set agents.defaults.sandbox.mode "off"
openclaw gateway restart

Y verifica:

openclaw config get agents.defaults.sandbox

Aviso importante (especialmente en Discord/WhatsApp)

Si desactivas sandbox, las sesiones de canales/grupos también pueden acabar con acceso real a tu host (según tu tool policy). Si tu bot está en un guild con más gente, eso puede ser peligroso. Alternativa más segura: dejar mode: "non-main" y rutear solo tu canal/DM “de confianza” al agent que tenga acceso.

[autumn ginkgo]

es curioso, esto no me habia pasado en otras instalaciones, tiene que ver con la configuracion de subagentes? como puedo perdirle que quiero hablar en agent:main:main tanto por whatsap como por discord?

[silk heath]

No es por “subagentes” en sí; es por routing de agente + tipo de chat (DM vs canal/grupo) + sandbox non-main.

1) Por qué agent:main:main “se siente distinto”

agent:main:main es la sesión main (normalmente DMs).
En cambio:

• agent:coding:discord:channel:... = canal de Discord → sesión separada por diseño
• grupos/canales (Discord guild channels, WhatsApp groups) NO colapsan a main, para no mezclar contexto/seguridad.

Y si tienes agents.defaults.sandbox.mode: "non-main", entonces todo lo que NO sea main puede quedar sandboxed (menos acceso al host), y ahí el bot “dice que lo hace” pero realmente no puede.

2) “Quiero hablar en agent:main:main desde WhatsApp y Discord”

Esto solo es posible si hablas por DM en ambos:

• WhatsApp DM → normalmente cae en agent:<agentId>:main (tu agent:main:main si el agent es main)
• Discord DM al bot → también cae en agent:<agentId>:main

En un canal de servidor (guild channel) no vas a conseguir que sea agent:main:main; siempre será agent:...:discord:channel:....

Qué hacer:

1. Abre DM con tu bot en Discord (no canal) y manda:

   /model status
   

   Debe mostrarte Agent: main y sesión main.
2. En WhatsApp, habla en DM y comprueba igual con /model status.

3) Si tus DMs están yendo al agent coding (y no al main)

Entonces tu config/routing está mandando Discord/WhatsApp a coding. Solución: en config haz que el agent main sea el default o crea un binding para que Discord/WhatsApp vayan a main.

Si me pegas tu bloque agents.list + bindings (sin tokens), te digo exactamente qué línea está ruteando a coding y cómo dejar DMs en main sin romper tu setup.

[autumn ginkgo]

Como saber el modelo actual que esta corriendo

[silk heath]

En el chat, usa:

/model status

Eso te muestra el modelo actual (“Current”), el default y el agente/sesión.

Si solo quieres ver el modelo de forma rápida (sin el detalle), también sirve:

/model

(y te enseña el selector + cuál está activo).

[autumn ginkgo]

Si yo le pido a mi openclaw con multiples modelos configurados como agentes y en teoria tambien deberian como subagentes (aunque en la carpeta de subagents solo veo un srchivo llamado run) en el de (agents) si que les veo a todos

El caso, si le digo al modelo principal que para hacer una web trabaje en coordinacion con todos los agentes dedicados cada uno a su tarea y que vayan cambiando de uno a otro y cojan entre si lo que van haciendo para aunarlo?

[silk heath]

Sí, puedes pedirle al modelo principal que trabaje “en equipo” con varios modelos, pero hay que entender bien qué significa “agentes” vs “sub‑agentes” en OpenClaw y qué limitaciones hay.

1) “Agentes” (agents) vs “sub‑agentes” (subagents)

• Agents (agents.list): son “cerebros” separados con workspace/sesiones separados. Se usan sobre todo para routing (qué chat va a qué agente). No es un “equipo” automático.
• Sub‑agents (sessions_spawn): son “workers” temporales que el agente principal lanza para tareas concretas. Al terminar, anuncian el resultado de vuelta al chat principal.

Que en la carpeta de subagents solo veas algo como run puede ser normal: los sub‑agents son sesiones efímeras, no una lista de “modelos instalados” en una carpeta.

2) ¿Pueden “cambiar de uno a otro” y “coger entre sí” lo que van haciendo?

Sí, pero no como una mente colmena automática.

El patrón que funciona es:

1. El main/orquestador (GLM) define un plan y “contratos” de salida.
2. Lanza sub‑agents por especialidad (Codex para código, Opus/Sonnet para UX/arquitectura, etc.).
3. Cada sub‑agent devuelve deliverables claros (archivos, listas, snippets).
4. El main integra todo en un único resultado (o un único repo/workspace).

Para que “compartan” trabajo de verdad, dales un punto de encuentro:

• un archivo tipo PROJECT.md / SPEC.md / TODO.md en el workspace
• o una carpeta handoff/ donde cada sub‑agent escribe su entrega (handoff/ui.md, handoff/api.md, etc.)

Ojo: si usas agents distintos con workspaces distintos, no “ven” los mismos archivos. Para colaboración real, o los pones en el mismo workspace, o el main copia/pega entre ellos.

3) Prompt listo para usar (equipo de web)

Pega esto al GLM (main). Ajusta nombres si quieres:

Quiero construir una web. Tú eres el orquestador (mantente en glm).
Trabaja en coordinación con sub‑agentes (NO cambies el modelo del main).

Crea una carpeta handoff/ y usa estos sub‑agentes, en este orden (fallback si falla):

• UI/UX: opus → sonnet → g3p → glm
• Frontend implementación: codex → qwen480 → sonnet → glm
• Copy/Marketing: kimi → opus → g3p → glm
• QA/Checklist: sonnet → g3p → glm

Reglas de handoff:

• Cada sub‑agente debe escribir su entrega en handoff/<area>.md (por ejemplo handoff/ui.md, handoff/frontend.md, handoff/marketing.md, handoff/qa.md).
• Cada entrega debe empezar con MODEL_USED: <provider/model> y luego un resumen + decisiones + próximos pasos.
• Cuando todos terminen, integra todo en un único plan y lista de tareas y dime qué archivos se generaron.

4) Para que realmente paralelicen

Si quieres que corran más de uno a la vez, sube:

• agents.defaults.subagents.maxConcurrent (por ejemplo 2–3)

Si no, van uno por uno.

Si me dices si estás usando un solo agent (coding) o varios (main, coding, etc.) y si comparten workspace, te digo cuál es la forma más limpia de montar ese “equipo” sin que se pisen ni pierdan contexto.

[autumn ginkgo]

Cuando en el browser ui se pone a ratos la consola de mensajes como en verde con un triangulo negro que quiere decir?

[silk heath]

En el Control UI eso es (casi seguro) el indicador de “compaction” del contexto.

Cuando una sesión se acerca al límite de contexto, OpenClaw hace una auto‑compaction: resume/compacta parte del historial para poder seguir trabajando sin pasarse de la ventana de contexto. El UI lo muestra así:

• Banner/“console” azul: Compacting context… (está compactando)
• Banner verde: Context compacted (compactación terminada, estado “success”)
• El “triangulito” negro que ves suele ser simplemente el icono/marker que acompaña ese estado en tu navegador/UI (no es un warning).

No es un error; es “housekeeping”. Si notas que justo después el agente “olvida” algo, es porque esa compactación reemplaza parte del historial por un resumen.

Si puedes, pega una captura de esa zona (dónde exactamente aparece el triángulo) y te confirmo al 100% si es el banner de compaction u otro elemento (por ejemplo un <details> colapsable en otra parte del UI).

[autumn ginkgo]

Estos son todos mis subagents : ceo, coding, data analysis, frontend, main, marketing, navigation, ops, social, triage, vision.

[silk heath]

Perfecto — lo que listaste (ceo, coding, data analysis, frontend, main, marketing, navigation, ops, social, triage, vision) no son “sub‑agents” en sí, sino agentIds (multi‑agent). Los sub‑agents son las ejecuciones aisladas que se lanzan con sessions_spawn, y pueden correr “bajo” cualquiera de esos agentId si lo permites.

1) Para que el orquestador pueda “spawnear” bajo otros agentIds

Por defecto, sessions_spawn(agentId=...) sólo permite spawnear bajo el mismo agentId. En el agent orquestador (el que recibe Discord/WhatsApp) añade:

agents: {
  list: [
    {
      id: "triage", // o "main"/"ceo", el que uses de orquestador
      subagents: {
        allowAgents: ["*"], // permite spawnear bajo cualquiera de tus agentIds
      },
    },
  ],
}

(Doc: agents.list[].subagents.allowAgents)

2) “handoff/<area>.md” y el tema del workspace (esto decide si se pisan o no)

Cada sub-agent escribe archivos en el workspace del agentId bajo el que corre.

Tienes dos estrategias limpias:

A) Workspace compartido (recomendado si quieres handoff por archivos en un único sitio)

• Configuras todos esos agentes con el mismo workspace.
• Entonces todos escriben a handoff/*.md en el mismo árbol, sin líos.
• Para no pisarse: archivo por agente (handoff/frontend.md, handoff/marketing.md, etc.) como ya propusiste.

B) Workspaces separados (más aislamiento)

• Cada agentId tiene su workspace (por defecto suele ser ~/.openclaw/workspace-<agentId>).
• Cada uno tendría su propio handoff/… en su workspace, y el orquestador no “ve” esos archivos directamente.
• En ese caso, lo robusto es que el sub-agent anuncie el contenido (announce), y el orquestador sea el que escriba el “handoff final” consolidado en su workspace.

Si me dices cuál prefieres (A o B), te doy el snippet exacto para tu caso.

3) Para paralelizar “de verdad” (concurrencia)

Hay dos límites a vigilar:

• Sub-agents: agents.defaults.subagents.maxConcurrent (lane subagent)
• Concurrencia global de runs: agents.defaults.maxConcurrent (default 1)

Ejemplo típico:

agents: {
  defaults: {
    maxConcurrent: 3,
    subagents: {
      maxConcurrent: 3,

    },
  },
}

Luego pruebas desde Discord con 2–3 spawns y miras /subagents list para confirmar que están “running” a la vez.

4) Pregunta rápida para darte “la forma más limpia” sin pisarse

¿Ahora mismo tus agentes comparten workspace o cada uno tiene el suyo por defecto?

Si no lo tienes claro, pégame tu bloque agents: { ... } (o al menos agents.defaults.workspace y agents.list[] con id/workspace) y te digo exactamente cómo dejarlo “equipo” con handoffs + paralelismo.

[autumn ginkgo]

Quiero el A, cada uno tiene un workspace con el nombre del agent en cuestion ahora mismo

[silk heath]

Vale — entonces quieres A (workspace compartido).

Ahora mismo cada agentId tiene su workspace propio (tipo workspace-frontend, workspace-marketing, etc.). Para pasar a A, la idea es: todos los agents apuntan al mismo workspace, así cualquier sub‑agent (corra bajo el agentId que sea) puede escribir en handoff/*.md en el mismo sitio.

1) Config: un único workspace para todos

Elige una ruta común (ej: ~/.openclaw/workspace-team) y ponla:

• En agents.defaults.workspace
• Y quita (o iguala) cualquier agents.list[].workspace que tengas hoy distinto

Ejemplo (JSON5):

{
  agents: {
    defaults: {

      workspace: "~/.openclaw/workspace-team",

      // (opcional) para paralelismo
      maxConcurrent: 3,
      subagents: { maxConcurrent: 3 },
    },

    list: [
      { id: "ceo" },
      { id: "coding" },
      { id: "data analysis" },
      { id: "frontend" },
      { id: "main" },
      { id: "marketing" },
      { id: "navigation" },

      { id: "ops" },
      { id: "social" },
      { id: "triage",
        subagents: { allowAgents: ["*"] } // para poder spawn a otros agentIds
      },
      { id: "vision" },
    ],
  },
}

Notas:

• Si ya tienes workspace dentro de cada entry, también vale hacer “search/replace” y poner la misma ruta en todos.
• allowAgents: ["*"] ponlo en el agent que orquesta (el que recibe el chat donde lanzas sessions_spawn). Si tu orquestador no es triage, muévelo a ese.

2) Importante: sandbox y escritura de archivos

Si tienes sandbox activado con workspaceAccess: "none" o "ro", los write/edit no van a caer en el workspace real como esperas (o ni siquiera podrán escribir).

Para el flujo de “handoff por archivos” necesitas:

• sandbox off, o
• workspaceAccess: "rw" para esos agents/subagents.

Si me pegas tu bloque agents.defaults.sandbox (o me dices si lo tienes en non-main/all), te digo el ajuste mínimo sin abrir demasiado.

3) Reinicia y verifica

Tras cambiar config: reinicia el gateway y prueba:

• lanzar 2 sub‑agents en paralelo y que escriban handoff/frontend.md / handoff/marketing.md
• luego comprueba que ambos archivos aparecen dentro de ~/.openclaw/workspace-team/handoff/

Si me dices qué agentId estás usando como “orquestador” en Discord (por ejemplo si el sessionKey empieza por agent:coding:discord:...), te dejo el snippet exacto (incluyendo allowAgents en el sitio correcto).

[autumn ginkgo]

Y como hago para que agent:main:main vaya a través de la guild de discord donde ests mi openclaw

[silk heath]

No se puede “hacer que un canal de guild use el sessionKey agent:main:main”.

En OpenClaw el sessionKey se decide por el tipo de chat:

• DMs ⇒ colapsan al “main session” del agente: agent:<agentId>:main (por defecto agent:main:main)
• Guild channels ⇒ siempre quedan aislados: agent:<agentId>:discord:channel:<channelId>
  (esto está así por diseño para no mezclar contexto de un servidor/canal con tus DMs).
  Fuente: docs Discord + Channel Routing (“Direct chats collapse…; guild channels stay isolated…”).

Lo más cercano a lo que quieres (práctico)

Ruta todo ese canal (o toda la guild) al agentId: "main", para que use el mismo agente/config/workspace, pero aceptar que el sessionKey seguirá siendo agent:main:discord:channel:....

Ejemplos con bindings:

Solo 1 canal → agent main

{
  bindings: [
    { match: { channel: "discord", peer: { kind: "channel", id: "1469912067946451089" } }, agentId: "main" },
  ],
}

Toda la guild → agent main

{
  bindings: [
    { match: { channel: "discord", guildId: "TU_GUILD_ID" }, agentId: "main" },
  ],
}

Si lo que quieres es literalmente “usar agent:main:main desde Discord”

Entonces la única forma es hablar por DM al bot (eso sí cae en agent:main:main). En un canal de servidor no.

Si me pasas tu guildId y el channelId donde lo quieres, te digo cuál de los dos bindings te conviene (canal vs guild) y dónde ponerlo junto con tu allowlist.

[sturdy dove]

@silk heath
How to stop openclaw bot?

[silk heath]

If you mean stop the bot completely (stop the Gateway):

• If you started it in a terminal (foreground): press Ctrl+C in that terminal.
• If you installed it as a background service/daemon:

  openclaw gateway status
  openclaw gateway stop
  

  (then openclaw gateway status again to confirm)

If you only mean stop it from replying on Discord (but keep OpenClaw running), set in config:

{ channels: { discord: { enabled: false } } }

…and restart the gateway.

If you tell me how you launched it (foreground terminal vs openclaw gateway start service vs Docker/PM2), I’ll give the exact command for your setup.

[sturdy dove]

@silk heath how to start then?

[silk heath]

To start OpenClaw again (the Gateway):

If you run it in the foreground (good for debugging)

openclaw gateway

Leave that terminal open.

If you installed it as a background service

openclaw gateway start
openclaw gateway status

Restart (common when you changed config)

openclaw gateway restart

If you paste:

openclaw --version
openclaw gateway status

I can tell which mode you’re in and what command is the right one for your machine.

[autumn ginkgo]

realmente haciendo opneclaw config y seleccionando los modelos de ollama, teniendo ollama instalado (los de la nube y uno local) ya estan configurados y en funcionamiento?

[silk heath]

Depende de 2 cosas. “Seleccionarlos en openclaw config” deja la config lista, pero no garantiza que Ollama esté accesible desde el Gateway ni que los modelos estén realmente disponibles.

Qué sí hace openclaw config

• Registra el provider ollama (apiKey/baseUrl si aplica) y/o la lista de modelos/aliases.
• O sea: OpenClaw “sabe” que existen.

Qué tiene que ser cierto para que estén “en funcionamiento”

A) Ollama accesible desde donde corre el Gateway

• Si OpenClaw (Gateway) y Ollama están en la misma máquina, normalmente OK.
• Si uno está en WSL y el otro en Windows, o en otra máquina, entonces necesitas que el Gateway pueda llegar a Ollama por red y quizá configurar models.providers.ollama.baseUrl.

B) El modelo realmente disponible en Ollama

• Para modelos locales: tienes que haber hecho ollama pull ... y tener ollama serve corriendo.
• Para modelos cloud: mientras tu Ollama los liste y puedas usarlos con ollama run ..., para OpenClaw es “uno más” (OpenClaw sólo habla con el servidor Ollama).

Cómo verificarlo rápido (sin adivinar)

En la máquina donde corre el Gateway:

1. Ver Ollama:

ollama list

2. Ver OpenClaw detectando/probando Ollama:

openclaw models status --probe --probe-provider ollama
openclaw models list | rg '^ollama/'

3. Prueba real en chat:

• En Discord, haz /model ollama/<tu-modelo> y pregúntale algo simple, o lanza un sub-agent con ese modelo.

Nota importante

Si al “seleccionar modelos” creaste un models.providers.ollama explícito, se suele desactivar el auto-discovery: si luego añades modelos nuevos en Ollama, no aparecen solos en OpenClaw (tienes que agregarlos también en config).

Si me dices dónde corre el Gateway (Windows nativo / WSL / Linux) y dónde corre Ollama, te digo el baseUrl exacto que deberías poner (cuando no es el default).

[autumn ginkgo]

parece que esto da error, puedes ayudarme a "despertar" ollama, ya que en openclaw ya lo tenemos preconfigurado? tenia abierto el programa de ollama como tal, no en el terminal sino el programa, igual no deberia,

[silk heath]

Sí, tener la app de Ollama abierta puede ser suficiente… pero sólo si el Gateway de OpenClaw puede llegar al servidor HTTP de Ollama (puerto 11434) desde la misma máquina/red donde corre OpenClaw.

“Despertar Ollama” = asegurarte de que Ollama está sirviendo la API.

1) Primero: comprueba si Ollama responde (EN LA MÁQUINA DONDE CORRE EL GATEWAY)

Ejecuta esto en la misma terminal/host donde corre openclaw gateway:

curl http://127.0.0.1:11434/api/tags

• Si responde con JSON → Ollama está “despierto”.
• Si da connection refused / timeout → Ollama no está corriendo ahí (o no escucha en ese IP/puerto).

2) Si falla: arráncalo explícitamente

En esa misma máquina:

ollama serve

(En algunos setups la app GUI lo hace “por detrás”, pero si OpenClaw no conecta, ollama serve es la forma directa de levantar el daemon.)

Luego repite el curl.

3) Confirma que OpenClaw lo ve

openclaw models status --probe --probe-provider ollama

Pega aquí el error exacto que te salga si falla.

4) Caso típico que rompe todo (muy probable en tu setup): Ollama en Windows/macOS, Gateway en WSL/Linux/VPS

Si Ollama está en Windows (app) pero OpenClaw Gateway está en WSL2 o en un VPS, entonces 127.0.0.1:11434 NO es el mismo “localhost”.

Dime esto y te doy el baseUrl correcto:

• ¿Dónde corre el Gateway? (Windows / WSL2 / Linux / VPS)
• ¿Dónde corre Ollama? (Windows app / WSL2 / Linux)

Con esos 2 datos te digo exactamente qué URL poner en models.providers.ollama.baseUrl (y cómo probarla con curl).

[autumn ginkgo]

esta todo en windows, el daemon parece hacer algo cuando meto ese script pero sigue sin estar "despierto"

[silk heath]

Si todo está en Windows, la app de Ollama “debería” levantar el server… pero cuando OpenClaw dice que “no está despierto” casi siempre es una de estas 3:

1. El server de Ollama no está escuchando en 11434
2. OpenClaw no tiene habilitado el provider (falta apiKey aunque sea dummy)
3. Config de Ollama en OpenClaw apunta al endpoint equivocado (especialmente /v1)

Vamos a aislarlo en 2 minutos.

Paso 1 — ¿Ollama API responde? (PowerShell)

En Windows, usa curl.exe (no el alias de PowerShell):

curl.exe -sS http://127.0.0.1:11434/api/tags

• Si NO responde / da error → Ollama no está sirviendo API. Prueba:

  ollama serve

y deja esa ventana abierta, luego repite el curl.exe.

• Si SÍ responde con JSON → Ollama está “despierto” y el problema es OpenClaw/config.

Paso 2 — ¿OpenClaw puede “probar” Ollama?

En la misma máquina donde corre el gateway:

openclaw models status --probe --probe-provider ollama

Pega aquí el output exacto si falla.

Dos fixes típicos (según lo que salga)

A) Falta habilitar Ollama en OpenClaw (apiKey dummy)

Aunque sea local, necesitas apiKey (cualquier string vale):

openclaw config set models.providers.ollama.apiKey "ollama-local"
openclaw gateway restart

B) Tienes models.providers.ollama explícito y el baseUrl está mal

Si en tu config tienes algo como models.providers.ollama.models: [...], entonces estás en modo manual y el baseUrl debería ser el OpenAI-compatible:

• Debe terminar en /v1 (ej: http://127.0.0.1:11434/v1)

Compruébalo con:

openclaw config get models.providers.ollama

---

En tu próximo mensaje, pégame:

1. salida de curl.exe .../api/tags
2. salida de openclaw models status --probe --probe-provider ollama
   y te digo exactamente cuál de los 2 fixes aplica.

[autumn ginkgo]

Config path not found: models.providers.ollama

[silk heath]

Ese mensaje (“Config path not found: models.providers.ollama”) no es grave: sólo significa que en tu config NO existe aún el bloque de Ollama (aunque tú “lo tengas preconfigurado” en el wizard/UI).

En Windows, haz esto:

1) Asegura que Ollama realmente está escuchando

En PowerShell:

curl.exe -sS http://127.0.0.1:11434/api/tags

• Si esto falla (connection refused/timeout) ⇒ Ollama no está sirviendo. Prueba:

  ollama serve
  

  y vuelve a intentar el curl.exe.

2) “Habilita” Ollama para OpenClaw (crea el bloque en config)

Como el path no existe, créalo con un apiKey dummy (cualquier string vale):

openclaw config set models.providers.ollama.apiKey "ollama-local"

Luego reinicia el gateway:

openclaw gateway restart

3) Verifica que OpenClaw ya lo detecta/probea

openclaw models status --probe --probe-provider ollama

openclaw models list | Select-String '^ollama/'

---

Si curl.exe /api/tags funciona pero OpenClaw sigue diciendo que no

Dime cómo estás corriendo OpenClaw:

• ¿openclaw gateway en terminal?
• ¿openclaw gateway start como servicio?
• ¿Docker / sandbox?

Porque si OpenClaw está dentro de Docker/sandbox, 127.0.0.1 ya no es tu Windows host y hay que usar host.docker.internal + habilitar red.

Pégame el output de:

1. curl.exe http://127.0.0.1:11434/api/tags

2. openclaw models status --probe --probe-provider ollama

y te digo el fix exacto.

[autumn ginkgo]

Missing auth

• ollama-local Run openclaw configure or set an API key env var.

[silk heath]

Ese “Missing auth – ollama-local” significa que OpenClaw no está viendo NINGÚN apiKey para Ollama (aunque Ollama no lo necesite “de verdad”, OpenClaw lo usa como flag para habilitar el provider / discovery).

Opción recomendada (no depende de variables de entorno)

En Windows (PowerShell/CMD):

openclaw config set models.providers.ollama.apiKey "ollama-local"
openclaw config get models.providers.ollama.apiKey
openclaw gateway restart

Si el get NO devuelve "ollama-local", entonces el set no se está aplicando al config que está usando tu gateway.

Opción alternativa (env var)

Solo sirve si el Gateway corre en la misma consola (o si configuras la env var a nivel sistema):

setx OLLAMA_API_KEY "ollama-local"
# cierra y reabre la terminal
openclaw gateway restart

Verificación rápida (pégame el output)

1. ¿Ollama responde?

curl.exe -sS http://127.0.0.1:11434/api/tags

2. ¿OpenClaw ya lo acepta?

openclaw models status --probe --probe-provider ollama

Si sigues viendo “Missing auth” después de que openclaw config get models.providers.ollama.apiKey muestre el valor, casi seguro estás corriendo el Gateway bajo otro usuario/otra instalación (config distinto). En ese caso dime si lo lanzas con openclaw gateway (foreground) o openclaw gateway start (servicio).

[autumn ginkgo]

openclaw config

[silk heath]

Ese mensaje (“Missing auth – ollama-local”) se arregla dándole a OpenClaw cualquier “API key” para Ollama (es sólo un flag; Ollama no valida nada).

Como tú ya estás en Windows y me dices “openclaw config”, tienes 2 caminos:

Opción A (CLI, la más directa)

En PowerShell:

openclaw config set models.providers.ollama.apiKey "ollama-local"
openclaw config get models.providers.ollama.apiKey
openclaw gateway restart

Luego verifica:

openclaw models status --probe --probe-provider ollama

Opción B (Wizard interactivo: openclaw config)

Si openclaw config te abre el wizard, busca la sección Models / Providers / Ollama y pon:

• API Key: ollama-local (o cualquier texto)
• Base URL: déjalo default si está en la misma PC (normalmente http://127.0.0.1:11434)

Guarda, y reinicia el gateway.

---

Importante (para no perseguir fantasmas)

Antes/después de esto, confirma que Ollama está realmente sirviendo:

curl.exe -sS http://127.0.0.1:11434/api/tags

Si eso falla, el problema no es OpenClaw: es que Ollama no está “sirviendo” (ahí toca ollama serve).

Si haces el Opción A y aún sale “Missing auth”, pégame el output de:

• openclaw config get models.providers.ollama
• openclaw models status --probe --probe-provider ollama

[autumn ginkgo]

Config path not found: models.providers.ollama.apiKey

[silk heath]

Ese error (“Config path not found…”) normalmente significa una de estas dos:

1. Estás en una versión de OpenClaw donde la ruta de config no coincide (muy típico si hay mismatch de versión), o
2. Estás usando openclaw config set contra un config “viejo”/incompleto y el helper no te deja crear ese árbol así.

0) Confirma versión (importante)

En Windows (PowerShell/CMD), pega el output de:

openclaw --version

1) Forma más segura: wizard de models

En vez de config set, usa el configurador interactivo (esto crea las claves correctas):

openclaw configure --section models

Ahí activa Ollama y pon cualquier API key (ej ollama-local). Luego:

openclaw gateway restart

2) Workaround rápido (sin tocar config): env var

Si quieres desbloquearlo YA, pon la env var (cualquier valor vale) y reinicia el gateway:

En la misma terminal donde arrancas OpenClaw (foreground):

$env:OLLAMA_API_KEY="ollama-local"
openclaw gateway

Si lo corres como servicio/daemon:

setx OLLAMA_API_KEY "ollama-local"

# cierra y abre terminal (o reinicia sesión) y luego:
openclaw gateway restart

3) Verificación

curl.exe -sS http://127.0.0.1:11434/api/tags
openclaw models status --probe --probe-provider ollama

Pásame el openclaw --version + el resultado de openclaw models status --probe --probe-provider ollama y te digo exactamente cuál camino aplicar (y si necesitas actualizar).

[autumn ginkgo]

https://github.com/openclaw/openclaw/pull/12452 is this OK?

[silk heath]

Directionally: yes, the idea is good — adding a “self‑hosted OpenAI‑compatible API” option to openclaw onboard / openclaw configure is exactly the UX gap people hit with LM Studio / Open WebUI / custom gateways.

But from the diff of PR #12452 (1 commit, 9 files, +264/‑1) I’d leave a couple review notes before calling it “OK to merge”:

1) Validate providerName harder (and avoid collisions)

Right now providerName only checks “non-empty”. Since it becomes a key under models.providers[providerName], it should probably enforce something like:

• no /
• no spaces
• ideally a slug regex: ^[a-z0-9][a-z0-9-_]*$
• and warn if it would overwrite an existing provider config

2) Base URL /v1 handling

You set a good default (http://localhost:1234/v1), but lots of people will paste http://localhost:11434 (Ollama) or http://localhost:3000 (Open WebUI).
Either:

• validate “must end with /v1” (and explain why), or
• auto-append /v1 when missing.

3) Alias collision risk

applySelfHostedOpenAIProviderConfig() sets:

alias: models[modelKey]?.alias ?? params.providerName

If a user configures multiple models under the same provider, that alias will collide (same alias for multiple model refs). Might be better to:

• not set an alias by default, or
• ask for an alias explicitly, or
• only set it if it’s not already used elsewhere.

4) The applySelfHostedOpenAIConfig + placeholder constants file

applySelfHostedOpenAIConfig() is a no-op placeholder, and onboard-auth.self-hosted-openai.ts is also basically placeholder constants. Maintainers might ask to either:

• wire them in meaningfully, or
• remove them to keep the surface clean.

If you address those 3–4 points, I’d personally say it’s in good shape. Ultimately though: it’s a maintainer call — I’d drop these notes as a PR comment so CI + reviewer can validate quickly.

[autumn ginkgo]

necesito un prompt que en caso de que algun modelo de mis agentes y subagentes realmente este dando problema y no funcionando mi openclaw no me diga que si que esta configurado y corriendp con ese modelo, que sea exacto y no alucine

[silk heath]

Pega esto tal cual en tu prompt base del agente orquestador (y si quieres también en cada agentId). Está diseñado para que no pueda decir “sí, funciona” sin evidencia:

---

Prompt “anti‑alucinación” (modelos / auth / providers)

REGLA DE VERACIDAD (MODELOS):
Nunca afirmes que un modelo/proveedor “está configurado”, “está funcionando”, “está disponible” o “se está usando” a menos que tengas evidencia observable en esta sesión.

EVIDENCIA VÁLIDA (elige al menos una):

1. Salida textual pegada por el usuario de:
   • openclaw models status --probe --probe-provider <provider>
   • openclaw models list
   • /model status (en el chat)
2. Una prueba real que acabas de ejecutar y fue exitosa (un “test call” corto) usando ese modelo.
3. Un log/snapshot que indique éxito/OK del provider (si el usuario lo pega).

PROHIBIDO:

• No digas “debería funcionar”, “parece configurado”, “seguro está bien” como si fuera un hecho.
• Si no hay evidencia, responde con NO_CONFIRMADO y pide datos.

FORMATO OBLIGATORIO al responder sobre estado de modelos:

• Estado: CONFIRMADO | NO_CONFIRMADO | FALLA
• Modelo(s) implicado(s): (refs exactas tipo provider/model)
• Evidencia: (pega la(s) línea(s) exacta(s) o di “(sin evidencia)”)
• Diagnóstico: (1–3 bullets, sólo hechos)
• Siguientes pasos: (comandos exactos)

PROTOCOLO DE DIAGNÓSTICO (cuando hay problemas):
Antes de opinar, pide SIEMPRE (o ejecuta si tienes permiso) estas 3 cosas:

1. openclaw --version
2. openclaw models status --probe --probe-provider <provider>
3. Un “health check” del endpoint (ej. curl al baseUrl/puerto del provider)

SUBAGENTES (sessions_spawn):

• Si un subagente reporta un modelo, debe decir:
  • MODEL_REQUESTED: <provider/model>
  • MODEL_CONFIRMED: yes/no
• Si no puede confirmarlo, debe decir no confirmado (no inventar).
• El orquestador debe confirmar modelos de subagentes con /subagents info cuando sea posible.

---

Bonus (recomendación práctica)

En Discord, cuando alguien te pregunte “¿está funcionando X?”, tu respuesta por defecto debe empezar con:

Estado: NO_CONFIRMADO (necesito evidencia)
y luego listar 2–3 comandos para pegar.

Si quieres, te lo adapto a tu setup exacto (Ollama/GLM/Antigravity/etc.) y lo convierto en un “bloque checklist” con los providers que usas, para que el agente pida siempre los comandos correctos según el provider.

[autumn ginkgo]

https://wiki.seeedstudio.com/es/local_openclaw_on_recomputer_jetson/ debería arreglar esto mi problema de que los modelos de ollama no cargan? Teniendo como default o princimal glm 4.7 zai

[silk heath]

No necesariamente.

Ese tutorial de Seeed no “arregla” un bug de OpenClaw/Ollama; lo que hace es montarte un entorno Linux en Jetson donde OpenClaw + Ollama viven en la misma máquina y con un baseUrl correcto (http://127.0.0.1:11434/v1). Eso sí suele evitar el problema típico de “Ollama no carga” cuando en realidad el Gateway no puede alcanzarlo, o no tiene el “auth flag” (OLLAMA_API_KEY / models.providers.ollama.apiKey).

Cuándo SÍ te ayudaría

• Si tu plan es mover el Gateway a la Jetson y correr Ollama también ahí → entonces es muy probable que “los modelos de Ollama carguen” porque todo queda local y consistente.
• Tu modelo principal Z.AI GLM 4.7 no es un impedimento: aunque el Gateway esté en Jetson, puedes seguir teniendo:
  • agents.defaults.model.primary = "zai/glm-4.7" (main/orchestrator)
  • y Ollama como modelos secundarios/subagents.

Cuándo NO te va a ayudar (tu caso probable)

Si ahora mismo estás en Windows y tu problema es que:

• Ollama no está sirviendo en 127.0.0.1:11434, o
• OpenClaw no está leyendo la env var / config correcta, o
• estás editando otro profile/config distinto al que usa tu gateway,

entonces cambiarte a Jetson es matar moscas a cañonazos: primero hay que diagnosticar por qué no carga en tu setup actual.

Checklist exacto (sin alucinar)

En tu Windows, pega outputs de:

1. Ollama “despierto”:

curl.exe -sS http://127.0.0.1:11434/api/tags

2. OpenClaw viendo/probando Ollama:

openclaw models status --probe --probe-provider ollama

3. Version:

openclaw --version

Con eso te digo CONFIRMADO / FALLA / NO_CONFIRMADO y el fix exacto. Si (1) funciona y (2) no, entonces el problema es 100% de auth/config/profile (no de Ollama).

[autumn ginkgo]

necesito un prompt para que pongas de verdad a prubea que modelo se esta usando en cada prueba y se pruebem todos los agentes/subagentes disponibles, tienes que asegurarte de que es certero diciendonis el modelo que uso porque hace nada me decia que no funcionaba glm y si ollama y resulta que nunca dejo de usar glm

[silk heath]

Aquí tienes un prompt “auditor” para pegar en tu agente orquestador. Está escrito para que NO pueda alucinar sobre qué modelo se usó: sólo puede “confirmar” si obtiene evidencia del Gateway (config + sesiones + resultados reales de subagents).

Cópialo tal cual:

Eres “Model Auditor” para OpenClaw. Tu trabajo es VERIFICAR (no suponer) qué modelos se usan realmente en cada agente y en cada sub-agent run.

REGLA #1 (NO ALUCINAR):
- Nunca digas “X está funcionando / está usando Y” sin evidencia.
- Si falta evidencia, di: ESTADO: NO_CONFIRMADO y pide el dato exacto.

EVIDENCIA VÁLIDA (solo estas cuentan):
A) gateway.config.get (config efectiva) para ver:
   - agents.list, agents.defaults.model, agents.list[].model
   - agents.defaults.models (aliases)
   - models.providers (ollama/baseUrl/apiKey etc.)

B) sessions_list (estado real por sessionKey) para ver el modelo resuelto/override (no inferir).
C) Resultado real de ejecución:
   - subagents que anuncien “Status: success” (o error/timeout) y su sessionKey/sessionId
   - y corroboración en sessions_list del childSessionKey creado

OBJETIVO:
1) Enumerar TODOS los agentIds configurados.
2) Para cada agentId, determinar su “modelo esperado” (según config).
3) Ejecutar una prueba REAL por agente (y por cada alias/modelo que el usuario pida), creando sub-agents bajo ese agentId.
4) En cada prueba, registrar:
   - MODEL_REQUESTED (lo que intentamos usar)
   - MODEL_RESOLVED (lo que el Gateway realmente resolvió para ese childSessionKey según sessions_list)
   - OUTCOME (success/error/timeout según el announce)
   - EVIDENCIA (copiar campos y sessionKey)
5) Entregar un reporte final en tabla.

PROCEDIMIENTO OBLIGATORIO (en este orden):
(1) Llama gateway.config.get y extrae:
    - agents.list[].id
    - agents.defaults.model + agents.list[].model
    - agents.defaults.models (map de alias)
    - models.providers (en especial ollama)
(2) Llama sessions_list (limit alto) y guarda un snapshot “ANTES”.
(3) Construye un plan de pruebas:
    - Smoke test mínimo: 1 subagent por agentId usando su modelo esperado.
    - Tests extra: 1 subagent por cada alias del usuario (ej: ollama/*, zai/*, etc.).
(4) Para cada prueba:
    - sessions_spawn con:
        agentId = el agentId bajo prueba
        model = MODEL_REQUESTED (explícito; no confiar en defaults)

        label = "<agentId> :: <model>"
        cleanup = keep
        task = "Responde 'OK' + una línea 'TEST_ID: <uuid>' y nada más."
    - Luego vuelve a llamar sessions_list y encuentra el childSessionKey nuevo (agent:<agentId>:subagent:<uuid>).
    - Lee de sessions_list el modelo resuelto/override/ provider para ese childSessionKey. Si no aparece, reintenta sessions_list 2-3 veces con espera corta.
    - Espera al announce del subagent. Si llega error/timeout, regístralo.
(5) Reporte final:
    - Tabla con columnas: agentId | requestedModel | resolvedModel | outcome | evidence(sessionKey/sessionId)
    - “Conclusión”: lista de modelos que NO se pudieron usar (y por qué, con evidencia).
    - “Acciones”: comandos/config exactos para corregir, pero solo si el fallo está confirmado.

RESTRICCIONES:
- Si no puedes acceder a gateway.config.get o sessions_list por política de herramientas, debes pedir al usuario que pegue:
  - `openclaw models status --probe --probe-provider ollama`
  - `openclaw models status --probe` (general)

  - y/o `/model status` en la sesión afectada.
- No inventes nombres de claves de config: si no puedes leer config, dilo.

Requisitos para que ese “auditor” pueda probar todos los agentes/subagentes

Antes de correrlo, asegúrate de tener:

• En el agente orquestador: agents.list[].subagents.allowAgents: ["*"] (si vas a spawnear bajo otros agentId).
• Concurrencia si quieres paralelo: agents.defaults.subagents.maxConcurrent (y si vas a disparar muchas pruebas, también agents.defaults.maxConcurrent).

Importante (por qué te pasó lo de “nunca dejó de usar GLM”)

A menudo cuando pides un modelo “no permitido / sin auth / no accesible”, el Gateway se queda en el modelo actual (ej. GLM) o usa fallback. El auditor de arriba fuerza a:

• pedir un modelo explícito en sessions_spawn, y
• verificar el modelo resuelto en sessions_list (evidencia del Gateway), no por “sensación”.

Si quieres, dime cuántos agentes/modelos quieres testear (puede ser caro), y te hago una versión “rápida” (solo 1 test por agentId + 1 test de Ollama) vs “exhaustiva” (todos los aliases).

[autumn ginkgo]

a ver....o estoy alucinando o aunque le pide a openclaw que cambia a agent:main:discord , no lo hace , porque en el browser UI yo siempre lo veo en agent:navigation discord, como cambio eso de verdad

[silk heath]

No estás alucinando: no se puede “cambiar de agente” en Discord sólo pidiéndoselo al bot.

En OpenClaw, el agentId que ves en el Control UI (ej. agent:navigation:discord:channel:...) lo decide el enrutado (routing):

• Discord guild channels siempre crean sesiones tipo agent:<agentId>:discord:channel:<channelId> (no existe un agent:main:discord “genérico”).
• El agentId (navigation, main, etc.) se elige por bindings (o, si no hay bindings que matcheen, por el agente default).

Cómo cambiarlo “de verdad” (routing)

Tienes que ajustar el config para que ese canal/guild de Discord rutee a agentId: "main" (o el que quieras).

Opción 1: Rutear TODO el guild a main

{
  bindings: [
    { match: { channel: "discord", guildId: "TU_GUILD_ID" }, agentId: "main" },
  ],

}

Opción 2: Rutear SÓLO un canal a main

{
  bindings: [
    {
      match: { channel: "discord", peer: { kind: "channel", id: "TU_CHANNEL_ID" } },
      agentId: "main"
    },
  ],
}

Importante: el orden importa. El primer binding que matchee gana. Si tienes un binding anterior que manda Discord a navigation, tu nuevo binding tiene que ir antes o tienes que quitar el viejo.

Asegura también cuál es el agente “default”

Si no tienes bindings (o no matchean), se usa el agente default. Pon explícitamente:

{
  agents: {
    list: [
      { id: "main", default: true },
      { id: "navigation" },
      // ...
    ]
  }
}

Después del cambio

• Reinicia el gateway (o aplica desde el Control UI si lo estás usando).

• No migra la sesión vieja: el histórico agent:navigation:discord:channel:... se queda ahí, pero los mensajes nuevos deberían caer en agent:main:discord:channel:<id>.

Para que te lo deje fino

Pégame tu bloque actual de bindings (si existe) y dime:

• tu guildId
• el channelId donde escribes
• qué agentId quieres que lo maneje (¿main o coding?)

y te digo exactamente qué línea agregar/mover para que deje de irse a navigation.

[autumn ginkgo]

@silk heath como puede ser que de repente mi openclaw me diga que no puede descargar d eun github ni ejecutar un exe... no tiene sentifo

[silk heath]

Eso sí tiene sentido y casi siempre es por una de estas causas (y puede “pasar de repente” si cambiaste de sesión/canal o tocaste sandbox/tool policy):

Causa más común: estás en “sandbox jail” (Discord guild channel = non‑main)

Si tienes agents.defaults.sandbox.mode: "non-main" (muy típico), entonces:

• Un DM cae en agent:<id>:main ⇒ NO sandbox (host).
• Un canal de Discord (guild) cae en agent:<id>:discord:channel:<id> ⇒ SÍ sandbox.

Y el sandbox por defecto:

• corre en Linux (Docker) → un .exe de Windows no va a ejecutar
• corre con network: "none" → no puede descargar de GitHub (curl/git/wget fallan)

Confírmalo (comando “verdad”)

En la máquina donde corre el gateway:

openclaw sandbox explain

(Si quieres afinar por agente: openclaw sandbox explain --agent navigation)

Eso te dice explícitamente si tu sesión está sandboxed y qué política aplica.

Otras 2 causas posibles (también “de repente”)

1. Tool policy: exec o web_fetch están denegados para ese agente/sandbox.
2. Elevated deshabilitado: aunque estés sandboxed, “salir al host” para exec requiere /elevated y que esté habilitado.

---

Cómo arreglarlo (elige según tu objetivo)

Opción A (recomendada): usa DM para tareas “peligrosas” (descargas/exec)

Deja el sandbox ON para guilds, y haz descargas/ejecución desde DM con el bot.

Opción B: permitir descargas en sandbox (solo si entiendes el riesgo)

Habilita red dentro del sandbox:

openclaw config set agents.defaults.sandbox.docker.network "bridge"
openclaw gateway restart

(Con eso, curl/git clone dentro del sandbox ya deberían poder salir.)

Opción C: ejecutar .exe en Windows host (no dentro del sandbox)

Necesitas ejecutar en host, no en Linux container. Eso se hace con elevated exec (si lo tienes permitido) o desactivando sandbox para ese agente:

• Desactivar sandbox globalmente (simple pero menos seguro):

openclaw config set agents.defaults.sandbox.mode "off"
openclaw gateway restart

• O desactivar sandbox solo para un agentId concreto (mejor):

agents: {
  list: [
    { id: "navigation", sandbox: { mode: "off" } }
  ]
}

---

Para no adivinar: pégame 2 salidas y te digo EXACTO cuál es tu caso

openclaw sandbox explain --json

2. el error exacto que te muestra cuando intenta descargar de GitHub / ejecutar el .exe (una línea vale).

Con eso te digo “CONFIRMADO: sandbox/network/tool policy/elevated” y el fix mínimo.

[autumn ginkgo]

@silk heath if I was going to test subagents what is a reasonable amount of max concurrent? can it fail if they are too many and they trigger all at the same time? is it a good way to test agent subagents and their models setting up one discord channel in the guild you use for test prompting each manually?

[silk heath]

A reasonable maxConcurrent depends on what you’re testing and how “heavy” the models/tools are, but yes: too many at once can absolutely fail (rate limits, RAM/CPU saturation, Ollama queueing, tool collisions, timeouts, gateway queue pressure).

1) What numbers are “reasonable”?

I’d use these as a baseline:

• 2–3: safest default for real work (keeps things stable)
• 4–6: OK for testing + bursty work if you’re on a decent machine and mostly cloud models
• 8: already aggressive (often fine for light subagents, but more failures if any are heavy)
• >8: usually “load testing”; expect more timeouts/429s/slowdowns

Config knobs (two different limits):

• Subagents lane: agents.defaults.subagents.maxConcurrent
• Global runs across sessions: agents.defaults.maxConcurrent (default 1, can bottleneck you even if subagents is high)

If you set subagents.maxConcurrent=6 but leave agents.defaults.maxConcurrent=1, you may still see “not really parallel” behavior because overall concurrency is capped.

2) What failures happen when you crank it too high?

Common failure modes:

• Provider rate limits (429) on cloud APIs
• Ollama: requests pile up → long latency → OpenClaw run timeouts
• CPU/RAM pressure: everything slows down → timeouts, browser/tools become flaky
• Network limits in sandboxed sessions (if sandbox has network:none)
• Best-effort announce can get lost if the gateway restarts under load

So yes, it can “fail” in the sense that some runs error/timeout even though config is fine.

3) Is a dedicated Discord test channel a good way to test subagents + model settings?

Yes—it’s a good idea, with two caveats:

1. A guild channel will have its own session key (agent:<id>:discord:channel:<id>), so if your sandbox mode is "non-main", that channel may be sandboxed and behave differently than DMs. That can affect tool tests and even networking.
2. Subagents are best tested with a repeatable harness (same prompt, explicit model per spawn, and then verify what model actually resolved).

Practical workflow:

• Make a #bot-lab channel.

• Route it via bindings to your orchestrator agentId (e.g. main or triage) so behavior is consistent.
• From there, spawn subagents with explicit model= each time and keep concurrency moderate (3–6).
• Use /subagents info and /subagents log to verify outcomes, and (best) also confirm the resolved model via session metadata if you have it available.

My recommendation for your case

Start with:

• agents.defaults.maxConcurrent: 3
• agents.defaults.subagents.maxConcurrent: 3 (or 4)
  Then do a burst test (spawn 3–4 at once). If stable, go to 6.

If you tell me:

• are you mostly testing Ollama models, or mostly cloud?
• is your gateway on Windows and are you using sandboxing?
  I’ll give a tighter number and the “least flaky” test setup.

[autumn ginkgo]

it seems the last little fix for us to make ollama work in openclaw, take a look

Ollama está corriendo correctamente en el puerto xxxxx. Los procesos están activos y escuchando.

Diagnóstico:

✅ Ollama procesos corriendo (PID: xxxxx, xxxx)
✅ Puerto xxxxx en LISTENING
❌ Curl desde PowerShell falla conectarse
Posible causa:
Firewall de Windows bloqueando el localhost. Configuración de red o proxy.

Recomendación:
Ollama está funcionando. Los subagentes pueden usar los modelos cloud directamente:

qwen3-next:80b-cloud
qwen3-coder:480b-cloud
glm-4.7:cloud

[silk heath]

Eso diagnóstico está internamente contradictorio:

• Si el puerto está en LISTENING y el proceso es Ollama, entonces un curl a 127.0.0.1:<puerto> no debería fallar “connect”.
• Por lo tanto, NO podemos concluir “Ollama está funcionando” hasta ver por qué falla el curl. Lo demás (firewall/proxy) es una hipótesis, pero en loopback suele ser raro.

La causa #1 que veo en Windows es esta:

1) En PowerShell, curl NO siempre es curl

En PowerShell, curl suele ser alias de Invoke-WebRequest (IWR), y eso puede liar el diagnóstico.

Prueba exactamente esto (importante: curl.exe):

curl.exe -v http://127.0.0.1:11434/api/tags

(usa tu puerto real si no es 11434)

Si te falla, prueba también (por si hay proxy raro configurado):

curl.exe -v --noproxy "*" http://127.0.0.1:11434/api/tags

Y prueba IPv6 vs IPv4:

curl.exe -v http://localhost:11434/api/tags
curl.exe -v http://[::1]:11434/api/tags

2) Confirma que el LISTENING es realmente en loopback

Pega el output de:

netstat -ano | findstr :11434
Get-NetTCPConnection -LocalPort 11434 | Format-List

Quiero ver si está escuchando en 127.0.0.1, 0.0.0.0 o ::1, y el PID real.

3) Si curl.exe funciona, entonces el “fix” de OpenClaw es sólo auth/baseUrl

Una vez que curl.exe http://127.0.0.1:11434/api/tags funcione, OpenClaw debería poder usarlo con:

• OLLAMA_API_KEY (cualquier string) o
• config models.providers.ollama.apiKey = "ollama-local"
  y (si es explícito) baseUrl: "http://127.0.0.1:11434/v1"

4) Importante: “pueden usar modelos cloud directamente” ≠ arreglar Ollama local

Eso solo evita Ollama, pero no soluciona el problema de conectividad local.

---

Pásame:

1. el error exacto de curl.exe -v .../api/tags (las primeras líneas)
2. el netstat -ano | findstr :<puerto>

y te digo CONFIRMADO: qué está pasando (alias de PowerShell / IPv6 vs IPv4 / puerto equivocado / proceso que no es Ollama / proxy), y el ajuste mínimo para OpenClaw.

[autumn ginkgo]

why is nano banana antigravity skill blocked in browser ui, how can I unblock?

[silk heath]

“Blocked” in the Control UI Skills list almost always means the skill is not eligible (fails its load-time gates), not that OpenClaw is “buggy”.

For nano-banana-pro specifically, the usual reasons are:

1. Missing GEMINI_API_KEY
   Nano Banana Pro is a Gemini Image API skill. Google Antigravity OAuth is NOT the same thing and does not satisfy GEMINI_API_KEY, so the skill stays blocked.

2. Bundled skill allowlist is restricting it
   If you set skills.allowBundled, only skills in that list are eligible.

3. Sandboxed session with no env/network (even if you enable it)
   If your Discord channel is sandboxed (common with sandbox.mode: "non-main"), then:

   • sandbox does not inherit host env, so skills.entries.*.env may not reach it
   • sandbox network may be none, so the skill can’t call Gemini

How to unblock (reliable way)

Run the wizard for skills (it writes the right keys):

openclaw configure --section skills

Then ensure:

• nano-banana-pro is enabled
• set the API key (GEMINI_API_KEY)

Or do it manually in ~/.openclaw/openclaw.json:

{
  skills: {
    entries: {
      "nano-banana-pro": {
        enabled: true,

        apiKey: "YOUR_GEMINI_API_KEY",
        env: { GEMINI_API_KEY: "YOUR_GEMINI_API_KEY" }
      }
    }
  }
}

If you have skills.allowBundled, add it there too:

skills: { allowBundled: ["nano-banana-pro", "..."] }

Verify why it’s blocked (no guessing)

openclaw skills list --eligible
openclaw skills check
openclaw skills info nano-banana-pro

One more gotcha: skills snapshot per session

After enabling, do /new (or restart the gateway) so the session reloads the eligible skills.

If you paste the exact “blocked” reason shown in the UI (or the output of openclaw skills check), I’ll tell you which of the 3 causes it is and the minimal fix.

[autumn ginkgo]

hola @silk heath tengo error 404 no body a que se puede deber, ademas si monto otro modelo carga muy lento no termina de contestar nunca

[autumn ginkgo]

Health check failed: gateway closed (1006 abnormal closure (no close frame)): no close reason

[silk heath]

Ese gateway closed (1006 abnormal closure (no close frame)) es un error genérico de WebSocket que significa: la conexión se cortó “a lo bruto” (el Gateway se cayó/reinició, el proceso fue matado, o hay un corte de red/proxy) antes de poder enviar un “close frame” normal.

Para saber cuál de esos es tu caso, hace falta evidencia del Gateway (sin adivinar).

3 comandos para diagnosticar (pégalos aquí)

En la misma máquina donde corre OpenClaw:

1. Versión:

openclaw --version

2. Estado del servicio/proceso y a qué puerto/config está apuntando:

openclaw gateway status

3. Reporte completo (redacta tokens) + tail de logs:

openclaw status --all

Con esos 3, normalmente ya se ve si:

• el Gateway está crashando/reiniciando,
• el CLI está probando otro profile/otro puerto,
• hay auth/bind mal configurado,
• o el puerto no está escuchando.

Si quieres la señal más clara (cuando 1006 aparece)

Corre logs en vivo y repite el health check:

openclaw logs --follow

y mientras tanto en otra terminal:

openclaw status --deep

Si el Gateway se cae, en logs --follow debería aparecer el motivo real (stack trace / “port in use” / “config invalid”, etc.)

Nota importante (muy común)

Si estás usando múltiples profiles/instancias, puede pasar que:

• tú editas un config,
• pero el servicio está corriendo con otro (Config (cli) ≠ Config (service) en openclaw gateway status).

Eso explica muchos “de repente” y también health checks que se desconectan.

Pégame el output de openclaw gateway status + openclaw status --all y te digo exactamente qué está pasando y el fix mínimo.

[autumn ginkgo]

@silk heath cual es la mejor manera de montar algo así como un entorno seguro controlando multiples openclaws de la mejor manera para que yo les diga cosas y ellos se gestionen entre openclaws y a su vez entre agentes y subagentes suyos propios? Todos los openclaws estsrian bajo mi control( yo seris el unico admin)

[silk heath]

Ese JSON no está en el formato correcto para OpenClaw actual (aunque la idea “muchos modelos/proveedores en un solo gateway” sí se puede).

Los puntos grandes que están fuera de schema / no funcionan como lo planteaste:

1. No existe providers (como lo pusiste).

   • Los proveedores “built-in” (OpenAI, OpenRouter, Z.AI, OpenAI Codex OAuth, Google Antigravity, Ollama, etc.) se usan por id tipo zai/glm-4.7, openai-codex/gpt-5.3-codex, google-antigravity/..., etc.
   • Para endpoints custom / proxies OpenAI-compatibles, eso va en models.providers, no en providers.
     Docs: https://docs.openclaw.ai/concepts/model-providers

2. Heartbeat no va en gateway.heartbeat. Va en agents.defaults.heartbeat (o por-agent).
   Docs: https://docs.openclaw.ai/gateway/heartbeat

3. gateway.security.credentials / vault como lo escribiste no es una cosa “oficial” de config.
   OpenClaw resuelve creds por: env vars (~/.openclaw/.env), auth profiles (~/.openclaw/agents/<agentId>/agent/auth-profiles.json), y logins OAuth via CLI.
   Docs env: https://docs.openclaw.ai/help/environment

4. Tu bloque channels lo estás usando como “routing de modelos”, pero en OpenClaw:

• channels = configuración del canal de mensajería (Discord/Telegram/WhatsApp/…).
  • El ruteo a distintos “brains” se hace con agents.list + bindings (multi-agent routing), no con channels.default/coding/secure_local.
    Docs: https://docs.openclaw.ai/concepts/multi-agent y https://docs.openclaw.ai/channels/channel-routing

5. fallback se llama fallbacks dentro de agents.defaults.model. (Y es para fallos/errores, no para “tareas difíciles”).
   Ver en FAQ: https://docs.openclaw.ai/help/faq (sección “Model failover…”)

---

Cómo montarlo bien (patrón recomendado)

A) Un solo Gateway, muchos modelos, cambiar en la misma sesión

Config mínimo (ejemplo):

{

  "$schema": "https://docs.openclaw.ai/schema/openclaw.schema.json",

  gateway: { name: "Pi_v5.1_Hybrid", port: 3456 },

  // claves mejor en ~/.openclaw/.env, pero esto también vale
  env: {
    ZAI_API_KEY: "${ZAI_API_KEY}",
    OPENROUTER_API_KEY: "${OPENROUTER_API_KEY}",
    OLLAMA_API_KEY: "ollama-local"
  },

  agents: {
    defaults: {
      model: {
        primary: "zai/glm-4.7",

        fallbacks: ["openai-codex/gpt-5.3-codex", "ollama/qwen2.5-coder:32b"]
      },

      // allowlist + aliases para /model
      models: {
        "zai/glm-4.7": { alias: "main" },
        "openai-codex/gpt-5.3-codex": { alias: "codex" },
        "ollama/qwen2.5-coder:32b": { alias: "qwen-local" }
      },

      heartbeat: {
        every: "30m",
        // activeHours: { start: "08:00", end: "23:00" }
      }
    }

  }
}

Y luego en chat:

• /model codex para coding
• /model main para volver

Para ver los IDs reales disponibles en tu instalación:

• openclaw models list
• openclaw models status

B) “Coding” y “secure local” como agentes aislados (más seguro)

En vez de “canales = modelos”, haz agentes distintos, y rutea con bindings.

Ejemplo de idea (tú me dices qué Discord channel IDs quieres para cada uno):

{
  agents: {
    list: [
      { id: "main", default: true, model: "zai/glm-4.7" },

      { id: "coding", model: "openai-codex/gpt-5.3-codex" },

      {
        id: "secure_local",
        model: "ollama/ministral-3:14b",
        models: {
          // allowlist SOLO local (para evitar cambiar a nube por accidente)
          "ollama/ministral-3:14b": { alias: "fast" }
        }
      }

    ]
  },

  bindings: [
    // ejemplo: un canal de Discord específico va al agente coding
    { agentId: "coding", match: { channel: "discord", peer: { kind: "channel", id: "1234567890" } } },

    // otro canal va al agente secure_local
    { agentId: "secure_local", match: { channel: "discord", peer: { kind: "channel", id: "2222222222" } } }
  ]
}

---

OAuth / “cosas extra” que SÍ tienes que hacer

Tu config por sí sola no crea tokens OAuth. Para estos:

• OpenAI Codex (OAuth):
  openclaw models auth login --provider openai-codex

• Google Antigravity (OAuth): primero habilita el plugin y luego login:
  openclaw plugins enable google-antigravity-auth
openclaw models auth login --provider google-antigravity --set-default
  (Docs: https://docs.openclaw.ai/concepts/model-providers)

• Ollama local: lo más simple es setear OLLAMA_API_KEY (cualquier valor) y dejar que descubra modelos.
  Docs: https://docs.openclaw.ai/providers/ollama

---

Sobre “TimesFM / Chronos / Flux” en models[]

Eso no va a funcionar como “model provider de chat” solo listándolo ahí. OpenClaw espera LLMs tipo chat/completions.

Si quieres usar TimesFM/Chronos/Flux como capacidades, normalmente van como tools/plugins/MCP/HTTP tool, no como modelos LLM.

---

Entorno “seguro” controlando muchos OpenClaws

Recomendación práctica:

1. Empieza con 1 Gateway + múltiples agents (aislamiento por workspace + auth + sesiones).
2. Si de verdad necesitas múltiples Gateways (aislamiento duro / redundancia), usa profiles:
   • openclaw --profile <name> ...
   • cada uno con su gateway.port y su state dir separado
     Docs: https://docs.openclaw.ai/gateway/multiple-gateways
3. Pasa el “security sanity check”:
   openclaw security audit --fix
   Docs: https://docs.openclaw.ai/gateway/security

---

Si me dices:

1. qué canal es (Discord) y
2. los IDs de los canales donde quieres coding vs secure_local,
   te dejo un bindings exacto para tu caso.

[autumn ginkgo]

necesito que adaptes mi ponclaw json para que los modelos funcionen correctamente como estan, con estra estructura, pero que el modelo default o principal sea gemini 3 flash

ademas ten esto en cuenta para solucionar unos inconvenientes que tenia con el sessionspawn , los permisos etc, desactiva el modo safeguard y actualiza los fallbacks y flujos para que ademas de gemini 3 flash ser el principal, estos son estos

Configuración de Agentes: Equilibrio de Calidad TotalDirectorio / Skill1º (Líder Primario)2º (Fallback 1)3º (Fallback 2)ceo claude-opus-4-5-thinkinggemini-3-pro-highqwen3-80bmaingemini-3-flashministral-3zai/glm-4.7frontendclaude-sonnet-4-5gpt-5.3-codexqwen3-coder:nextcodinggpt-5.3-codexclaude-opus-4-5-thinkingqwen3-coder:nextvisionqwen3-vl:32b-cloudgemini-3-pro-highclaude-sonnet-4-5archive-researchgemini-3-pro-highclaude-opus-4-5-thinkingqwen3-80bnavigationkimi-2.5gemini-3-flashclaude-sonnet-4-5data-analysisminimax-m2.1gemini-3-pro-highclaude-sonnet-4-5ops / triagegemini-3-flashministral-3zai/glm-4.7

este es el openclaw json

{
"meta": {
"lastTouchedVersion": "2026.2.6-3",
"lastTouchedAt": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
},
"wizard": {
"lastRunAt": xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"lastRunVersion": "2026.2.6-3",
"lastRunCommand": "doctor",
"lastRunMode": "local"
},
"auth": {
"profiles": {
"zai:default": {
"provider": "zai",
"mode": "api_key"
}
}
},
"models": {
"providers": {
"antigravity-proxy": {
"baseUrl": "xxxxxxxxxxxxxxxxxxxxxxxx",
"apiKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxx",
"api": "openai-completions",
"models": [
{
"id": "gemini-3-flash",
"name": "Gemini 3 Flash",
"reasoning": false,
"input": [
"text",
"image"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 200000,
"maxTokens": 8192
},
{
"id": "gemini-3-pro-high",
"name": "Gemini 3 Pro High",
"reasoning": true,
"input": [
"text",
"image"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 200000,
"maxTokens": 32768
},
{
"id": "claude-opus-4-5-20251101",
"name": "Claude Opus 4.5",
"reasoning": false,
"input": [
"text",
"image"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 200000,
"maxTokens": 32768
},
{
"id": "claude-opus-4-5-thinking",
"name": "Claude Opus 4.5 (Thinking)",
"reasoning": true,
"input": [
"text",
"image"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 200000,
"maxTokens": 32768
},
{
"id": "claude-sonnet-4-5",
"name": "Claude Sonnet 4.5",
"reasoning": false,
"input": [
"text",
"image"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 200000,
"maxTokens": 8192
},
{
"id": "claude-sonnet-4-5-thinking",
"name": "Claude Sonnet 4.5 (Thinking)",
"reasoning": true,
"input": [
"text",
"image"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 200000,
"maxTokens": 32768
}
]
},
"openai": {
"baseUrl": "https://api.openai.com/v1",
"api": "openai-completions",
"models": [

[silk heath]

Perfecto — te pasé una configuración lista para usar. Cambios claves que hice:

• Puse Gemini‑3 Flash como modelo por defecto (agents.defaults.model.primary = google/gemini-3-flash-preview).
• Moví/normalicé los modelos a la forma provider/model y añadí un allowlist (agents.defaults.models) con alias para que /model funcione sin sorpresas.
• Desactivé el modo "safeguard" de compaction (agents.defaults.compaction.mode = "default").
• Actualicé los fallbacks por agente según la tabla que enviaste.
• Para resolver problemas con sessions_spawn: añadí subagents.allowAgents:["*"] (permite spawn entre agentes). Nota: sub-agentes NO pueden invocar sessions_spawn ni herramientas de sesiones por diseño (eso está en la deny por defecto en el runtime). Si quieres permitir eso habría que cambiar código o pedirlo a quien mantenga el gateway.
• Hice tools.profile = "full" y relajé permisos para sub-agentes (allow list). Atención: la deny por defecto para subagents incluye tools de sesión; la config no puede quitar esa deny sin cambiar el código.

Aquí tienes el JSON5 (cópialo a ~/.openclaw/openclaw.json o úsalo con tu flujo de deploy). Ajusta los model IDs si prefieres variantes concretas (p. ej. si tienes claude-opus-4-5-thinking en vez de la versión 4.6):

{
  "$schema": "https://docs.openclaw.ai/schema/openclaw.schema.json",

  gateway: {

    name: "Pi_v5.1_Hybrid",
    port: 3456
  },

  // Put real keys in ~/.openclaw/.env or export them before starting the gateway
  env: {
    GEMINI_API_KEY: "${GEMINI_API_KEY}",
    ANTHROPIC_API_KEY: "${ANTHROPIC_API_KEY}",
    OPENAI_API_KEY: "${OPENAI_API_KEY}",
    OLLAMA_API_KEY: "ollama-local",
    ZAI_API_KEY: "${ZAI_API_KEY}",
    MINIMAX_API_KEY: "${MINIMAX_API_KEY}"
  },

  // Tools surface: full by default; tweak if you want tighter controls

  tools: {
    profile: "full",
    subagents: {
      tools: {
        // Allow common tool groups for spawned sub-agents (deny-list still applies)
        allow: ["group:fs", "group:runtime", "group:web", "group:memory", "image", "group:messaging"],
        deny: []
      }
    }
  },

  // Keep models.mode merge to allow builtin + custom providers
  models: { mode: "merge" },

  agents: {

    defaults: {
      // DEFAULT MODEL = Gemini Flash
      model: {
        primary: "google/gemini-3-flash-preview",
        fallbacks: ["google/gemini-3-pro-preview", "ollama/qwen3:80b"]
      },

      // Allowlist + aliases (usadas por /model)
      models: {
        "google/gemini-3-flash-preview": { alias: "gemini-flash" },
        "google/gemini-3-pro-preview": { alias: "gemini-pro" },
        "anthropic/claude-opus-4-6": { alias: "claude-opus-thinking" },
        "anthropic/claude-sonnet-4-5": { alias: "claude-sonnet" },
        "openai-codex/gpt-5.3-codex": { alias: "codex" },
        "zai/glm-4.7": { alias: "glm-4.7" },

        "minimax/MiniMax-M2.1": { alias: "minimax-m2.1" },
        "ollama/ministral-3:14b": { alias: "ministral-3" },
        "ollama/qwen3:80b": { alias: "qwen3-80b" },
        "ollama/qwen3-coder:next": { alias: "qwen3-coder-next" },
        "ollama/qwen3-vl:32b-cloud": { alias: "qwen-vl-32b-cloud" },
        "moonshot/kimi-k2.5": { alias: "kimi-2.5" }
      },

      // DESACTIVAR 'safeguard'
      compaction: { mode: "default" },

      // Sub-agent defaults
      subagents: {
        maxConcurrent: 4,
        archiveAfterMinutes: 60,

        model: "google/gemini-3-flash-preview",
        thinking: "low"
      },

      heartbeat: { every: "30m" }
    },

    // AGENTES por carpeta/skill — según tu tabla
    list: [
      {
        id: "main",
        default: true,
        workspace: "~/.openclaw/workspace-main",
        model: { primary: "google/gemini-3-flash-preview", fallbacks: ["ollama/ministral-3:14b", "zai/glm-4.7"] },
        subagents: { allowAgents: ["*"], model: "google/gemini-3-flash-preview" }

      },

      {
        id: "ceo",
        workspace: "~/.openclaw/workspace-ceo",
        model: { primary: "anthropic/claude-opus-4-6", fallbacks: ["google/gemini-3-pro-preview", "ollama/qwen3:80b"] },
        subagents: { allowAgents: ["*"], model: "google/gemini-3-pro-preview" },
        thinkingDefault: "high"
      },

      {
        id: "frontend",
        workspace: "~/.openclaw/workspace-frontend",
        model: { primary: "anthropic/claude-sonnet-4-5", fallbacks: ["openai-codex/gpt-5.3-codex", "ollama/qwen3-coder:next"] },
        subagents: { allowAgents: ["*"] }

      },

      {
        id: "coding",
        workspace: "~/.openclaw/workspace-coding",
        model: { primary: "openai-codex/gpt-5.3-codex", fallbacks: ["anthropic/claude-opus-4-6", "ollama/qwen3-coder:next"] },
        subagents: { allowAgents: ["*"] }
      },

      {
        id: "vision",
        workspace: "~/.openclaw/workspace-vision",
        model: { primary: "ollama/qwen3-vl:32b-cloud", fallbacks: ["google/gemini-3-pro-preview", "anthropic/claude-sonnet-4-5"] },
        subagents: { allowAgents: ["*"] }
      },

      {
        id: "archive-research",
        workspace: "~/.openclaw/workspace-archive",
        model: { primary: "google/gemini-3-pro-preview", fallbacks: ["anthropic/claude-opus-4-6", "ollama/qwen3:80b"] },
        subagents: { allowAgents: ["*"] }
      },

      {
        id: "navigation",
        workspace: "~/.openclaw/workspace-navigation",
        model: { primary: "moonshot/kimi-k2.5", fallbacks: ["google/gemini-3-flash-preview", "anthropic/claude-sonnet-4-5"] },
        subagents: { allowAgents: ["*"] }
      },

      {
        id: "data-analysis",
        workspace: "~/.openclaw/workspace-data",
        model: { primary: "minimax/MiniMax-M2.1", fallbacks: ["google/gemini-3-pro-preview", "anthropic/claude-sonnet-4-5"] },
        subagents: { allowAgents: ["*"] }
      },

      {
        id: "ops",
        workspace: "~/.openclaw/workspace-ops",
        model: { primary: "google/gemini-3-flash-preview", fallbacks: ["ollama/ministral-3:14b", "zai/glm-4.7"] },
        subagents: { allowAgents: ["*"] }
      }
    ]
  }

}

Pasos recomendados para aplicar y verificar

1. Guardar el archivo en el host gateway: ~/.openclaw/openclaw.json (haz backup antes).
2. Poner las claves en ~/.openclaw/.env o exportar las vars (GEMINI_API_KEY, ANTHROPIC_API_KEY, OPENAI_API_KEY, OLLAMA_API_KEY, ZAI_API_KEY, MINIMAX_API_KEY).
3. Reiniciar gateway: openclaw gateway restart (o si usas service: reinicia el servicio correspondiente).
4. Verificar modelos y auth:
   • openclaw models status
   • openclaw models list --all
   • openclaw status --all
5. (Si usas Ollama local) confirmar con: ollama list y asegúrate OLLAMA_API_KEY=ollama-local (o ajusta baseUrl en models.providers).
6. Para OpenAI Codex (OAuth): openclaw models auth login --provider openai-codex
   Para Anthropic: openclaw models auth paste-token --provider anthropic (o exporta ANTHROPIC_API_KEY).
   Para Gemini: pon GEMINI_API_KEY en ~/.openclaw/.env o usa el plugin indicado según tu método de autenticación.

Notas importantes / Seguridad

• Puse allowAgents: [""] para facilitar sessions_spawn entre agentes (soluciona permisos cross-agent). Esto es poderoso: si quieres más seguridad, reemplaza "" por la lista concreta de agentIds permitidos.
• Por seguridad, sub-agentes siguen sin poder usar herramientas de sesión (sessions_list/history/send/spawn etc.) — eso está bloqueado en el runtime por diseño (deny por defecto). Si necesitas cambiarlo, dime qué comportamiento exacto quieres y lo documentamos/implementamos con más cuidado.
• Cambiar compaction a "default" reduce protecciones de resumen; revisa memoryFlush/backup si dependes de historiales largos.
• Revisa con openclaw security audit después de arrancar.

¿Quieres que:

• escriba esto directamente en ~/.openclaw/openclaw.json y reinicie el Gateway por ti, o
• prefieres que te lo devuelva como archivo para que lo pegues tú?

Si quieres que lo aplique yo, dime y lo escribo y reinicio (o dime dónde quieres cambiar aliases/model IDs exactos si usas nombres distintos — p. ej. si realmente tienes "anthropic/claude-opus-4-5-thinking" y no la 4.6, lo cambio).

Vale — como tu Gemini 3 Flash está definido dentro de tu provider custom models.providers.antigravity-proxy (con id: "gemini-3-flash"), entonces el model ref correcto para usarlo como default es:

• antigravity-proxy/gemini-3-flash (no google/...)

Abajo te dejo EXACTAMENTE lo que tienes que añadir o reemplazar en tu openclaw.json (mantén tu meta, wizard, auth, models.providers... tal cual).

---

1) Añade/Reemplaza tu bloque tools (para evitar bloqueos raros de permisos)

"tools": {
  "profile": "coding"
}

coding incluye sessions_spawn (y el resto de tools típicos). Si ya usas full, déjalo como está.

---

2) Añade/Reemplaza tu bloque agents (DEFAULT = Gemini Flash + fallbacks por agente + desactivar safeguard)

Este bloque cumple tu tabla:

"agents": {
  "defaults": {
    "model": {
      "primary": "antigravity-proxy/gemini-3-flash",
      "fallbacks": [
        "ollama/ministral-3:14b",
        "zai/glm-4.7"
      ]
    },

    "compaction": {
      "mode": "default"
    },

    "subagents": {
      "maxConcurrent": 4,
      "archiveAfterMinutes": 60,
      "model": "antigravity-proxy/gemini-3-flash",
      "thinking": "low"
    },

    "models": {
      "antigravity-proxy/gemini-3-flash": { "alias": "flash" },
      "antigravity-proxy/gemini-3-pro-high": { "alias": "pro" },

      "antigravity-proxy/claude-opus-4-5-thinking": { "alias": "opus_thinking" },
      "antigravity-proxy/claude-sonnet-4-5": { "alias": "sonnet" },

      "openai-codex/gpt-5.3-codex": { "alias": "codex" },

      "zai/glm-4.7": { "alias": "glm" },
      "minimax/MiniMax-M2.1": { "alias": "minimax" },
      "moonshot/kimi-k2.5": { "alias": "kimi" },

      "ollama/ministral-3:14b": { "alias": "ministral" },
      "ollama/qwen3:80b": { "alias": "qwen80b" },
      "ollama/qwen3-coder:next": { "alias": "qwen_coder" },
      "ollama/qwen3-vl:32b-cloud": { "alias": "qwen_vl" }
    }
  },

  "list": [
    {
      "id": "main",
      "default": true,
      "model": {
        "primary": "antigravity-proxy/gemini-3-flash",
        "fallbacks": ["ollama/ministral-3:14b", "zai/glm-4.7"]
      },
      "subagents": { "allowAgents": ["*"] }
    },

    {
      "id": "ceo",
      "model": {

        "primary": "antigravity-proxy/claude-opus-4-5-thinking",
        "fallbacks": ["antigravity-proxy/gemini-3-pro-high", "ollama/qwen3:80b"]
      },
      "subagents": { "allowAgents": ["*"] }
    },

    {
      "id": "frontend",
      "model": {
        "primary": "antigravity-proxy/claude-sonnet-4-5",
        "fallbacks": ["openai-codex/gpt-5.3-codex", "ollama/qwen3-coder:next"]
      },
      "subagents": { "allowAgents": ["*"] }
    },

    {
      "id": "coding",
      "model": {
        "primary": "openai-codex/gpt-5.3-codex",
        "fallbacks": ["antigravity-proxy/claude-opus-4-5-thinking", "ollama/qwen3-coder:next"]
      },
      "subagents": { "allowAgents": ["*"] }
    },

    {
      "id": "vision",
      "model": {
        "primary": "ollama/qwen3-vl:32b-cloud",
        "fallbacks": ["antigravity-proxy/gemini-3-pro-high", "antigravity-proxy/claude-sonnet-4-5"]
      },

      "subagents": { "allowAgents": ["*"] }
    },

    {
      "id": "archive-research",
      "model": {
        "primary": "antigravity-proxy/gemini-3-pro-high",
        "fallbacks": ["antigravity-proxy/claude-opus-4-5-thinking", "ollama/qwen3:80b"]
      },
      "subagents": { "allowAgents": ["*"] }
    },

    {
      "id": "navigation",
      "model": {

        "primary": "moonshot/kimi-k2.5",
        "fallbacks": ["antigravity-proxy/gemini-3-flash", "antigravity-proxy/claude-sonnet-4-5"]
      },
      "subagents": { "allowAgents": ["*"] }
    },

    {
      "id": "data-analysis",
      "model": {
        "primary": "minimax/MiniMax-M2.1",
        "fallbacks": ["antigravity-proxy/gemini-3-pro-high", "antigravity-proxy/claude-sonnet-4-5"]
      },
      "subagents": { "allowAgents": ["*"] }
    },

    {
      "id": "ops",
      "model": {
        "primary": "antigravity-proxy/gemini-3-flash",
        "fallbacks": ["ollama/ministral-3:14b", "zai/glm-4.7"]
      },
      "subagents": { "allowAgents": ["*"] }
    }
  ]
}

Importante sobre sessions_spawn (para tus “permisos”)

• Lo que te estaba frenando casi seguro era spawn cross-agent: por defecto no deja.
  Con subagents.allowAgents: ["*"] ya queda habilitado.
• Ojo: sub-agentes no pueden usar tools de sesión (sessions_*) ni spawn de subagentes desde subagentes. Eso está bloqueado por diseño en runtime (no es “modo safeguard”).

---

3) Cosas que debes verificar SÍ o SÍ (para que “funcionen correctamente como están”)

Como tu config que pegaste está cortada, no puedo garantizar que existan estos providers/models:

• ollama/ministral-3:14b, ollama/qwen3:80b, ollama/qwen3-coder:next, ollama/qwen3-vl:32b-cloud
• moonshot/kimi-k2.5
• minimax/MiniMax-M2.1
• openai-codex/gpt-5.3-codex

Para confirmar en tu host:

openclaw models list --plain
openclaw models status

Y si usas Ollama:

ollama list

Si algún ID no existe, dime qué te sale en openclaw models list --plain (pega solo las líneas relevantes) y te ajusto los refs exactos.

---

Si puedes, pega el resto del openai provider (y si tienes ollama, moonshot, minimax en models.providers) y te lo dejo 100% “copy/paste” sin suposiciones.

[autumn ginkgo]

genera el openclaw json entero para asi lo copie y lo pegue

[silk heath]

Aquí tienes un openclaw.json completo (JSON5 válido) ya adaptado a lo que dijimos:

• Default/global = antigravity-proxy/gemini-3-flash
• Compaction safeguard OFF → agents.defaults.compaction.mode: "default"
• Fallbacks por agente según tu tabla
• sessions_spawn permisos cross-agent → en cada agente: subagents.allowAgents: ["*"]
• Incluye un Discord “solo admin” (solo tú puedes usar comandos/directivas y activar al bot). Si tu bot ya tiene un bloque channels.discord funcionando, puedes reemplazar el mío por el tuyo.

Copia y pega tal cual, y solo reemplaza los ${...} por tus valores (o ponlos en ~/.openclaw/.env).

{
  "$schema": "https://docs.openclaw.ai/schema/openclaw.schema.json",

  "meta": {
    "lastTouchedVersion": "2026.2.6-3",

    "lastTouchedAt": "REPLACE_ME_ISO_TIMESTAMP"
  },

  "wizard": {
    "lastRunAt": "REPLACE_ME_ISO_TIMESTAMP",
    "lastRunVersion": "2026.2.6-3",
    "lastRunCommand": "doctor",
    "lastRunMode": "local"
  },

  "gateway": {
    "name": "Pi_v5.1_Hybrid",
    "port": 3456
  },

  "env": {
    "OPENAI_API_KEY": "${OPENAI_API_KEY}",
    "ANTHROPIC_API_KEY": "${ANTHROPIC_API_KEY}",
    "ZAI_API_KEY": "${ZAI_API_KEY}",
    "MINIMAX_API_KEY": "${MINIMAX_API_KEY}",
    "MOONSHOT_API_KEY": "${MOONSHOT_API_KEY}",

    // Ollama: cualquier valor sirve (Ollama no requiere key real)
    "OLLAMA_API_KEY": "ollama-local",

    // Tu proxy antigravity (OpenAI-compatible)
    "ANTIGRAVITY_PROXY_BASE_URL": "${ANTIGRAVITY_PROXY_BASE_URL}",
    "ANTIGRAVITY_PROXY_API_KEY": "${ANTIGRAVITY_PROXY_API_KEY}",

    // Discord

    "DISCORD_BOT_TOKEN": "${DISCORD_BOT_TOKEN}"
  },

  "auth": {
    "profiles": {
      "zai:default": { "provider": "zai", "mode": "api_key" }
    }
  },

  "tools": {
    "profile": "coding"
  },

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

[autumn ginkgo]

el que debe usar sessionspawn es el default

[silk heath]

    "providers": {
      "antigravity-proxy": {
        "baseUrl": "${ANTIGRAVITY_PROXY_BASE_URL}",
        "apiKey": "${ANTIGRAVITY_PROXY_API_KEY}",
        "api": "openai-completions",
        "models": [
          {
            "id": "gemini-3-flash",
            "name": "Gemini 3 Flash",
            "reasoning": false,
            "input": ["text", "image"],
            "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
            "contextWindow": 200000,
            "maxTokens": 8192
          },

          {
            "id": "gemini-3-pro-high",
            "name": "Gemini 3 Pro High",
            "reasoning": true,
            "input": ["text", "image"],
            "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
            "contextWindow": 200000,
            "maxTokens": 32768
          },
          {
            "id": "claude-opus-4-5-20251101",
            "name": "Claude Opus 4.5",
            "reasoning": false,
            "input": ["text", "image"],
            "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },

            "contextWindow": 200000,
            "maxTokens": 32768
          },
          {
            "id": "claude-opus-4-5-thinking",
            "name": "Claude Opus 4.5 (Thinking)",
            "reasoning": true,
            "input": ["text", "image"],
            "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
            "contextWindow": 200000,
            "maxTokens": 32768
          },
          {
            "id": "claude-sonnet-4-5",
            "name": "Claude Sonnet 4.5",

            "reasoning": false,
            "input": ["text", "image"],
            "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
            "contextWindow": 200000,
            "maxTokens": 8192
          },
          {
            "id": "claude-sonnet-4-5-thinking",
            "name": "Claude Sonnet 4.5 (Thinking)",
            "reasoning": true,
            "input": ["text", "image"],
            "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
            "contextWindow": 200000,
            "maxTokens": 32768
          }

[silk heath]

Listo — si lo que quieres es:

• que cuando el agente decida usar sessions_spawn, el sub‑agente siempre corra con el modelo “default” (Gemini 3 Flash),
• y que no tengas que pasar agentId,

entonces la regla es esta:

1) sessions_spawn (sin agentId) ya usa el agente que lo llamó

Eso es el comportamiento por defecto del tool: si no especificas agentId, el spawn queda en el mismo agentId que está activo en esa conversación.

2) El modelo que usará el sub‑agente lo controlas con:

agents.defaults.subagents.model

En tu caso debe quedar así (y sin overrides por agente):

        ]
      }
    }
  },

  "agents": {
    "defaults": {
      "model": {
        "primary": "antigravity-proxy/gemini-3-flash",
        "fallbacks": [
          "ollama/ministral-3:14b",
          "zai/glm-4.7"
        ]
      },

agents: {
  defaults: {
    subagents: {
      model: "antigravity-proxy/gemini-3-flash"
    }
  }
}

En el JSON completo que te pasé ya está correcto.

---

Lo único que te pido revisar en tu config final

Asegúrate de que NO exista en ningún agente algo como:

      "heartbeat": {
        "every": "30m",
        "activeHours": { "start": "08:00", "end": "23:00" }
      },

      // SAFEGUARD OFF
      "compaction": { "mode": "default" },

      "subagents": {
        "maxConcurrent": 4,
        "archiveAfterMinutes": 60,
        "model": "antigravity-proxy/gemini-3-flash",
        "thinking": "low"
      },

agents: {
  list: [
    { id: "ceo", subagents: { model: "..." } }
  ]
}

Porque si pones subagents.model a nivel de agente, ese pisará el default para spawns hechos hacia ese agente.

Si quieres, pégame tu agents final (solo esa sección) y te digo si hay algún override que esté rompiendo que “sessionspawn use el default”.

      // allowlist + aliases para /model
      "models": {
        "antigravity-proxy/gemini-3-flash": { "alias": "flash" },
        "antigravity-proxy/gemini-3-pro-high": { "alias": "pro" },
        "antigravity-proxy/claude-opus-4-5-thinking": { "alias": "opus_thinking" },
        "antigravity-proxy/claude-sonnet-4-5": { "alias": "sonnet" },

        "openai-codex/gpt-5.3-codex": { "alias": "codex" },

        "zai/glm-4.7": { "alias": "glm" },
        "minimax/MiniMax-M2.1": { "alias": "minimax" },
        "moonshot/kimi-k2.5": { "alias": "kimi" },

        "ollama/ministral-3:14b": { "alias": "ministral" },
        "ollama/qwen3:80b": { "alias": "qwen80b" },

        "ollama/qwen3-coder:next": { "alias": "qwen_coder" },
        "ollama/qwen3-vl:32b-cloud": { "alias": "qwen_vl" }
      }
    },

    "list": [
      {
        "id": "main",
        "default": true,
        "workspace": "~/.openclaw/workspace-main",
        "model": {
          "primary": "antigravity-proxy/gemini-3-flash",
          "fallbacks": ["ollama/ministral-3:14b", "zai/glm-4.7"]
        },
        "subagents": { "allowAgents": ["*"] }

      },

      {
        "id": "ceo",
        "workspace": "~/.openclaw/workspace-ceo",
        "model": {
          "primary": "antigravity-proxy/claude-opus-4-5-thinking",
          "fallbacks": ["antigravity-proxy/gemini-3-pro-high", "ollama/qwen3:80b"]
        },
        "subagents": { "allowAgents": ["*"] }
      },

      {
        "id": "frontend",
        "workspace": "~/.openclaw/workspace-frontend",

        "model": {
          "primary": "antigravity-proxy/claude-sonnet-4-5",
          "fallbacks": ["openai-codex/gpt-5.3-codex", "ollama/qwen3-coder:next"]
        },
        "subagents": { "allowAgents": ["*"] }
      },

      {
        "id": "coding",
        "workspace": "~/.openclaw/workspace-coding",
        "model": {
          "primary": "openai-codex/gpt-5.3-codex",
          "fallbacks": ["antigravity-proxy/claude-opus-4-5-thinking", "ollama/qwen3-coder:next"]
        },
        "subagents": { "allowAgents": ["*"] }

      },

      {
        "id": "vision",
        "workspace": "~/.openclaw/workspace-vision",
        "model": {
          "primary": "ollama/qwen3-vl:32b-cloud",
          "fallbacks": ["antigravity-proxy/gemini-3-pro-high", "antigravity-proxy/claude-sonnet-4-5"]
        },
        "subagents": { "allowAgents": ["*"] }
      },

      {
        "id": "archive-research",
        "workspace": "~/.openclaw/workspace-archive-research",

        "model": {
          "primary": "antigravity-proxy/gemini-3-pro-high",
          "fallbacks": ["antigravity-proxy/claude-opus-4-5-thinking", "ollama/qwen3:80b"]
        },
        "subagents": { "allowAgents": ["*"] }
      },

      {
        "id": "navigation",
        "workspace": "~/.openclaw/workspace-navigation",
        "model": {
          "primary": "moonshot/kimi-k2.5",
          "fallbacks": ["antigravity-proxy/gemini-3-flash", "antigravity-proxy/claude-sonnet-4-5"]
        },
        "subagents": { "allowAgents": ["*"] }

      },

      {
        "id": "data-analysis",
        "workspace": "~/.openclaw/workspace-data-analysis",
        "model": {
          "primary": "minimax/MiniMax-M2.1",
          "fallbacks": ["antigravity-proxy/gemini-3-pro-high", "antigravity-proxy/claude-sonnet-4-5"]
        },
        "subagents": { "allowAgents": ["*"] }
      },

      {
        "id": "ops",
        "workspace": "~/.openclaw/workspace-ops",

        "model": {
          "primary": "antigravity-proxy/gemini-3-flash",
          "fallbacks": ["ollama/ministral-3:14b", "zai/glm-4.7"]
        },
        "subagents": { "allowAgents": ["*"] }
      }
    ]
  },

  "channels": {
    "discord": {
      "enabled": true,
      "token": "${DISCORD_BOT_TOKEN}",

      // “solo admin”: en DMs solo tú; en servers solo tú (y con mention)

      "dm": {
        "enabled": true,
        "policy": "allowlist",
        "allowFrom": ["447695592286584832"]
      },

      "groupPolicy": "open",
      "guilds": {
        "*": {
          "requireMention": true,
          "users": ["447695592286584832"]
        }
      }
    }
  }

}

Dos notas rápidas (para que no te vuelva a fallar “models not allowed” / “invalid model”)

1. Si no tienes exactamente esos modelos en Ollama (ministral/qwen), cambia los IDs en:

• agents.defaults.models (allowlist)
• y en los fallbacks / primary donde los usas.

2. Para Codex OAuth (gpt-5.3-codex) necesitas el login en el host del gateway:

openclaw models auth login --provider openai-codex

Si quieres, pégame el output de:

openclaw models list --plain

y te lo ajusto para que los IDs de Ollama/quwen coincidan 1:1 con lo que tienes instalado.

[autumn ginkgo]

Health check failed: gateway closed (1006 abnormal closure (no close frame)): no close reason

[silk heath]

Ese error (WS 1006 “abnormal closure / no close frame”) casi siempre significa: el CLI sí llegó a abrir WebSocket, pero el proceso del Gateway se cayó / reinició / cerró el socket antes de responder (o hay “algo” en ese puerto que no es el Gateway real).

Para saber cuál de los dos es, necesito 4 salidas (en este orden):

1. Versión

openclaw --version

2. Estado del gateway (lo más importante: Probe target / Listening / Last gateway error / Config cli vs Config service)

openclaw gateway status

3. Logs mientras intentas el health check

openclaw logs --follow

(espera a que falle otra vez y pega ~30-80 líneas alrededor del fallo)

4. Doctor (detecta config inválida, service mismatch, etc.)

openclaw doctor

Cosas típicas que causan 1006 en tu situación

• El servicio está usando OTRO config (mismatch de profile/state dir): en openclaw gateway status mira si sale Config (cli) distinto a Config (service).
• Config inválido JSON5/JSON (comillas faltantes, trailing commas raras, placeholders mal pegados). Si el gateway crashea al arrancar, lo verás en openclaw logs o openclaw doctor.
• Puerto equivocado: tú pusiste gateway.port: 3456. En gateway status revisa el Probe target para confirmar que el CLI está probando ws://127.0.0.1:3456 y no el default 18789.
• Hay otra cosa escuchando en 3456 (proxy/http server): abre WS y lo cierra (1006).

Pégame aquí el output de esos 4 comandos (puedes censurar tokens), y con eso te digo exactamente qué está cerrando el socket y qué línea de config lo provocó.

[sturdy dove]

Hello @silk heath
I setup several agents and I added heartbeats file for each agents.
But when run, only one - main agent's heartbeat is working.
othewr agent's heartbeat is not working

[silk heath]

Having a HEARTBEAT.md file in each agent’s workspace is not enough by itself.

Two common reasons you’ll only see the main agent heartbeat:

1) Heartbeats are only scheduled for agents that have a heartbeat config

Heartbeats are controlled by config (agents.defaults.heartbeat and/or agents.list[].heartbeat), not by the file existing.

Also important rule:

• If any agent in agents.list[] has a heartbeat block, then only the agents that have a heartbeat block will run heartbeats.

So either:

Option A (easy): one heartbeat setting for all agents

Put heartbeat only in defaults, and do not set per-agent heartbeat blocks anywhere:

{
  agents: {
    defaults: {
      heartbeat: { every: "30m", target: "last" }
    }
  }
}

Option B: explicitly enable heartbeat on every agent

Add a heartbeat block to each agent entry:

{
  agents: {

    list: [
      { id: "main", heartbeat: { every: "30m", target: "last" } },
      { id: "agent2", heartbeat: { every: "30m", target: "last" } }
    ]
  }
}

2) target: "last" needs the agent to have a “last chat destination”

By default heartbeats deliver to target: "last". If you never actually chatted with that agent (or nothing is routed/bound to it), there may be no “last” place to send the heartbeat → so you won’t see anything.

Fix: either message each agent once, or set a specific delivery target (channel/to).

---

If you paste your agents section (and whether you have any agents.list[].heartbeat blocks), I can tell you exactly which of the two issues you’re hitting.

[sturdy dove]

@silk heath
Which file should I change ?
Or is there any cli?

[silk heath]

Change your OpenClaw config file (the one your Gateway service is actually using), not the HEARTBEAT.md files.

1) Find the exact config path the service is using

Run:

openclaw gateway status

Look for the lines like Config (service): ... (that’s the file you must edit).

2) Fix it (two ways)

Option A (recommended): enable heartbeats for all agents globally

Edit that config file and set:

agents: {
  defaults: {
    heartbeat: { every: "30m", target: "last" }
  }
}

And make sure you do not have heartbeat: { ... } only on one agent in agents.list[], otherwise only that agent may run.

Option B: per-agent heartbeats

Add a heartbeat block to each agent in agents.list[].

3) Apply changes

Restart the gateway:

openclaw gateway restart

CLI?

There isn’t a “turn on heartbeat for all agents” single CLI command I can guarantee across versions; the reliable path is editing the config file the service uses (step 1) and restarting.

If you paste the agents part of your config (or just tell me if you have any agents.list[].heartbeat), I’ll tell you exactly what to change.

[sturdy dove]

Hello @silk heath
it still run only one agent

[silk heath]

In current OpenClaw versions, this is expected behavior unless you explicitly opt-in other agents:

Why only 1 agent runs heartbeats

If you only set agents.defaults.heartbeat, OpenClaw will run heartbeats only for the default agent.

To run heartbeats for multiple agents, you must add a heartbeat block under each agent in agents.list[] (even an empty {} is enough). Once any agent has a heartbeat block, heartbeats run only for the agents that have that block.

---

Fix (edit your openclaw.json)

Example:

{
  agents: {
    defaults: {

      heartbeat: { every: "30m", target: "last" }
    },
    list: [
      { id: "main", default: true, heartbeat: {} },
      { id: "agent2", heartbeat: {} },
      { id: "agent3", heartbeat: {} }
    ]
  }
}

Then:

openclaw gateway restart

---

Two more gotchas that make it look “not working”

1) HEARTBEAT.md “empty” = heartbeat skipped

If your HEARTBEAT.md is basically just a title/header, OpenClaw skips the run to save cost.
Make sure it has at least one real checklist line, e.g.:

# Heartbeat
- Check pending tasks

2) HEARTBEAT_OK is hidden by default

If the model replies HEARTBEAT_OK, OpenClaw suppresses it (so you won’t see messages even if it’s running).

For debugging, temporarily enable “show OK”:

{
  channels: {
    defaults: {
      heartbeat: { showOk: true, showAlerts: true, useIndicator: true }
    }
  }
}

---

If you paste your agents block (just that part), I’ll point out exactly which agents currently have heartbeat enabled and what to add.

[autumn ginkgo]

hello @silk heath if you dont open powershell as an admin openclaw then wont have admmin rights?

[silk heath]

OpenClaw only has the OS permissions of the process that launched it.

So:

• If you run openclaw ... from a normal PowerShell/Terminal, it runs as your regular user (no admin).
• If you run it from PowerShell “Run as Administrator”, then it runs with admin privileges on Windows — but OpenClaw generally doesn’t need that, and it’s usually not recommended (least privilege).

When you do need Admin on Windows

Mostly for Windows networking / firewall / portproxy type tasks, e.g. exposing a WSL service to LAN:

• netsh interface portproxy ...
• New-NetFirewallRule ...

Those specifically require PowerShell as Administrator. (Docs: https://docs.openclaw.ai/platforms/windows)

If you’re running OpenClaw inside WSL2 (recommended)

Windows “Admin PowerShell” does not magically give admin rights inside Linux/WSL.

• OpenClaw runs with your Linux user permissions in WSL.
• If a Linux action needs root, you use sudo inside WSL, not Windows admin.

About OpenClaw “/elevated”

That’s an OpenClaw tool policy/approval mode, not Windows “Administrator”. It controls how permissive exec/tool calling is — it doesn’t grant OS admin rights by itself.

If you tell me whether you’re on native Windows or WSL2, I can tell you exactly what should/shouldn’t require admin for your setup.

[autumn ginkgo]

krill why do I get this error on fresh install of openclaw Install failed: songsee — brew not installed
Tip: run openclaw doctor to review skills + requirements.
Docs: https://docs.openclaw.ai/skills

[silk heath]

That error is not a core OpenClaw install failure — it’s the skill installer trying to install the bundled skill songsee, and that skill’s only auto-install method is Homebrew.

From the skill metadata, songsee requires the songsee binary and installs via brew formula steipete/tap/songsee. So if brew isn’t installed, OpenClaw can’t auto-install that skill and prints:

Install failed: songsee — brew not installed

You’ve got 3 options:

Option A (recommended on macOS): install Homebrew + songsee

1. Install Homebrew (from the official site): https://brew.sh
2. Then install the formula:

brew install steipete/tap/songsee

3. Re-run:

openclaw doctor

Option B (if you don’t care about that skill): disable the skill

In your openclaw.json add:

{
  skills: {
    entries: {
      songsee: { enabled: false }
    }
  }
}

Then restart the gateway.

Option C (skip skill setup during onboarding)

If this happened during onboarding/configure, re-run with:

openclaw onboard --skip-skills

If you tell me your OS (macOS vs WSL/Linux), I’ll tell you which option is best. On WSL/Linux, Option B is usually the quickest unless you specifically want songsee.

[autumn ginkgo]

I´m not on linux and before I did not have this issue

[silk heath]

That message is coming from the skills installer, not from OpenClaw “core”.

What changed is: your current OpenClaw version ships (or enabled) a bundled skill called songsee, and that skill’s only auto-install method is Homebrew. If Homebrew isn’t present, it prints:

Install failed: songsee — brew not installed

So OpenClaw itself can still run — it just can’t auto-install that optional skill.

Why you didn’t see it before

Most likely one of these:

• you were on an older OpenClaw version that didn’t try to install songsee (or didn’t include it)
• you previously had Homebrew installed
• you previously ran onboarding with --skip-skills

Fix options (pick one)

Option 1 (macOS): install Homebrew (then songsee)

If you’re on macOS and want that skill:

1. Install brew: https://brew.sh
2. Then:

brew install steipete/tap/songsee

Option 2 (recommended if you don’t care about spectrograms): disable the skill

Add this to your openclaw.json:

skills: {
  entries: {
    songsee: { enabled: false }
  }
}

Then restart the gateway.

Option 3: skip skill setup in the wizard

If you’re hitting this during onboarding/configure:

openclaw onboard --skip-skills
# or
openclaw configure --skip-skills

Quick question (so I tell you the best path)

Are you on macOS or Windows? And what does:

openclaw --version

print?

[autumn ginkgo]

none of them, something must be wrong with my files even uninstalling reinstalling, would uninstalling git and node maybe fix it?

on the other side I get this errror on health check gateway closed (1006 abnormal closure (no close frame)): no close reason

[silk heath]

Uninstalling git or node won’t fix either of those issues (and uninstalling Node will usually make OpenClaw stop working entirely, since the Gateway runs on Node).

You’re seeing two separate things:

1) Install failed: songsee — brew not installed

That’s the skills installer trying to set up the bundled skill songsee, which only has a Homebrew install recipe. It’s optional and not required for OpenClaw to run.

If you don’t want that skill, disable it (no brew needed):

Disable via CLI (easy)

openclaw config set skills.entries.songsee.enabled false
openclaw gateway restart

(or edit openclaw.json and add:)

skills: { entries: { songsee: { enabled: false } } }

2) Health check ... gateway closed (1006 abnormal closure...)

1006 means the CLI opened a WebSocket, then the connection got dropped without a clean close — most commonly because the Gateway process is crashing/restarting, you’re probing the wrong port, or the service is using a different config than the CLI.

Please run these and paste the output (you can redact tokens):

openclaw --version
openclaw status --all
openclaw gateway status
openclaw logs --follow

While openclaw logs --follow is running, trigger the health check again so we catch the crash reason in the logs.

Also: check one common footgun

If you changed gateway.port (e.g. to 3456), make sure openclaw gateway status shows the Probe target using that same port. If it’s probing 18789 but your gateway listens on 3456, you’ll get weird “closed”/probe failures.

Once you paste those outputs, I’ll tell you exactly whether it’s:

• config mismatch (Config (cli) vs Config (service)),
• a startup crash due to invalid config,
• a port conflict,
• or something else causing the WS to drop.

[autumn ginkgo]

@silk heath what is the command if I am in default model zai glm-4.7 to proxy-antigravity/gemini-3-flash ?

[silk heath]

Use the /model command with the full provider/model ref:

/model antigravity-proxy/gemini-3-flash

If you added the alias I suggested (e.g. "alias": "flash" under agents.defaults.models["antigravity-proxy/gemini-3-flash"]), then you can also do:

/model flash

To see what OpenClaw thinks is available right now:

/model list

[autumn ginkgo]

Yes but how to change it to flash?

[autumn ginkgo]

@silk heath if setup properly, all agents must have each their subfolder in agents? Or no?m

[silk heath]

Yes — in a proper multi‑agent setup, each agent gets its own directory under the state dir.

By default (OPENCLAW_STATE_DIR=~/.openclaw) you’ll end up with:

• ~/.openclaw/agents/<agentId>/agent/
  (per‑agent auth + models registry, e.g. auth-profiles.json, models.json, etc.)
• ~/.openclaw/agents/<agentId>/sessions/
  (that agent’s session store + transcripts)

Two details that confuse people:

1. Those folders are often created lazily — if an agent never gets used / never receives routed messages, you might not see its folder yet.

2. You can override with agents.list[].agentDir, but you should not reuse the same agentDir across agents (causes auth/session collisions).

Quick checks:

ls ~/.openclaw/agents
openclaw agents list --bindings

Docs: https://docs.openclaw.ai/concepts/multi-agent

[autumn ginkgo]

@silk heath what is the best discord guild setuo for multiple personalities organized? All in one chat? Each one in one channel? If each of them go on each guild channel specific for them.... how should I set it up? "GuildID , channelID " ? Is it not possible such a setup ? Is it better other way?

[silk heath]

Best practice on Discord for multiple personalities is: one personality = one isolated agent, and route each agent to a dedicated Discord channel (or thread). That keeps context clean and avoids “persona bleeding”.

You have 2 good patterns:

Option A (recommended): 1 agent per personality + 1 Discord channel per agent

Pros: clean separation (workspace, sessions, auth), easy mental model.
Cons: you manage more channels.

How to set it up

1. Create channels like #ceo, #coding, #vision, etc.
2. Enable Discord Developer Mode → right‑click channel → Copy Channel ID (and copy the Guild ID too).
3. In openclaw.json, set:

• agents.list[] for each persona
• bindings[] to map each Discord channel ID → agentId
• channels.discord.guilds.<guildId>.channels.<channelId>.allow: true so the bot is allowed to read that channel

Example:

{
  agents: {
    list: [
      { id: "main", default: true, workspace: "~/.openclaw/workspace-main" },
      { id: "ceo", workspace: "~/.openclaw/workspace-ceo" },
      { id: "coding", workspace: "~/.openclaw/workspace-coding" }
    ]
  },

  bindings: [
    {
      agentId: "ceo",
      match: {
        channel: "discord",
        guildId: "YOUR_GUILD_ID",

        peer: { kind: "channel", id: "CEO_CHANNEL_ID" }
      }
    },
    {
      agentId: "coding",
      match: {
        channel: "discord",
        guildId: "YOUR_GUILD_ID",
        peer: { kind: "channel", id: "CODING_CHANNEL_ID" }
      }
    }
  ],

  channels: {
    discord: {

      groupPolicy: "allowlist",
      guilds: {
        "YOUR_GUILD_ID": {
          users: ["YOUR_USER_ID"],

          channels: {
            "CEO_CHANNEL_ID": { allow: true, requireMention: false },
            "CODING_CHANNEL_ID": { allow: true, requireMention: false }
          }
        }
      }
    }
  }
}

Notes:

• peer.kind: "channel" + peer.id: "<channelId>" is the key thing.
• You can include guildId (recommended) to make matching more specific.

Docs:

• Multi-agent routing: https://docs.openclaw.ai/concepts/multi-agent
• Discord config: https://docs.openclaw.ai/channels/discord
• Routing/session keys: https://docs.openclaw.ai/channels/channel-routing

Option B (lighter): one agent only, different personalities via per-channel systemPrompt

If you don’t need separate workspaces/auth, you can keep one agent and set different “personality prompts” per Discord channel:

channels: {
  discord: {
    guilds: {

      "YOUR_GUILD_ID": {
        channels: {
          "CEO_CHANNEL_ID": {
            allow: true,
            systemPrompt: "You are the CEO persona. Be strategic and concise."
          },
          "CODING_CHANNEL_ID": {
            allow: true,
            systemPrompt: "You are the coding persona. Be technical."
          }
        }
      }
    }
  }
}

Pros: fewer moving parts.
Cons: still shares the same agent workspace + auth; separation is “soft”.

---

“All in one chat?” (single channel)

I wouldn’t, unless you’re okay with mixed context. If you really want a single place, better: use threads per persona (each thread has its own session key), but you still need routing rules if you want different agents.

If you tell me:

• your Guild ID
• the Channel IDs you want for each persona
• your target agent IDs (ceo, coding, etc.)

…I’ll paste you a ready-to-copy bindings[] + channels.discord.guilds[...] block for your exact layout.

[autumn ginkgo]

can I do both all my agents as agent "main" subagents" and also differnt workspace personas for that option A discord setup? @silk heath

lmk

@silk heath Entendido el contexto adicional sobre el enrutamiento de Discord y la necesidad de que los agentes funcionen como subagentes para el agente main. Agradezco la claridad.

Sin embargo, el problema principal que estoy enfrentando y que me impide avanzar con la configuración de subagentes es el persistente error de permisos al intentar usar la herramienta sessions_spawn. El mensaje de error constante es: "agentId is not allowed for sessions_spawn (allowed: none)".

He intentado habilitar esto a través de varias configuraciones en openclaw.json (incluyendo tools.allow para el agente main, tools.agentToAgent.allow y posibles configuraciones globales de sessions_spawn), así como a través de tools-policy.json para el agente main. Lamentablemente, todas estas tentativas han resultado en claves no reconocidas o no han tenido ningún efecto en la resolución del error de permisos.

Parece que existe una restricción de seguridad implícita o un método de configuración muy específico para sessions_spawn que no estoy logrando identificar con la información actual.

¿Tienes alguna indicación o conoces el método exacto para permitir que el agente main (o cualquier agente) utilice sessions_spawn para iniciar otros agentes, superando específicamente el error "agentId is not allowed for sessions_spawn (allowed: none)"?

[silk heath]

Ese error viene de una allowlist específica de sessions_spawn, y no se controla con tools.allow, ni con tools.agentToAgent, ni con tools-policy.json.

Qué significa exactamente el error

"agentId is not allowed for sessions_spawn (allowed: none)" aparece cuando el agente que está intentando hacer sessions_spawn quiere spawnear en otro agentId, pero su allowlist subagents.allowAgents está vacía.

En el código, la allowlist sale de:

• agents.list[].subagents.allowAgents del agente que hace la llamada (el “requester agent”).

Si no la defines, por defecto es [] → o sea allowed: none para cross-agent.

---

Fix (config exacta)

En tu openclaw.json, dentro de agents.list, en el agent que inicia los subagentes (normalmente main), añade:

Permitir spawnear a cualquier agente

{
  agents: {
    list: [
      {
        id: "main",
        default: true,
        subagents: {
          allowAgents: ["*"]
        }
      },

      { id: "ceo" },
      { id: "coding" },
      { id: "vision" }

    ]
  }
}

O más seguro: permitir solo algunos

{
  agents: {
    list: [
      {
        id: "main",
        default: true,
        subagents: {
          allowAgents: ["ceo", "coding", "vision"]

        }
      }
    ]
  }
}

Después:

openclaw gateway restart

---

2 gotchas comunes