Multi agent setup | Friends of the Crustacean 🦞🤝 | Page 1

viral pier Apr 17, 2026, 3:04 PM

#

Help me the best way / optimize multi agent

jovial fieldBOT Apr 17, 2026, 3:04 PM

#

gritty flintBOT Apr 17, 2026, 3:04 PM

#

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

jovial fieldBOT Apr 17, 2026, 3:04 PM

#

opal pantherBOT Apr 17, 2026, 3:06 PM

#

Pulling the docs so I don’t make up config keys.

#

FAQ path moved in this install, let me locate the right one.

#

Best pattern is usually:

Use multiple agents only for real isolation: different workspace, auth, persona, or tool policy.
Use subagents for parallel work inside one agent, instead of creating tons of full agents.
Keep the main agent smart, and set a cheaper default model for subagents with agents.defaults.subagents.model.
Add guardrails:
- runTimeoutSeconds
- archiveAfterMinutes
- maxConcurrent (don’t crank this too high, subagents still share the same gateway resources)
Leave maxSpawnDepth: 1 unless you specifically want an orchestrator → workers pattern. If you do, set maxSpawnDepth: 2 and keep maxChildrenPerAgent low.
On Discord, enable thread bindings if you want persistent worker threads:
- channels.discord.threadBindings.enabled
- channels.discord.threadBindings.spawnSubagentSessions
Lock specialist agents down with per-agent sandbox + tools allow/deny.
Do not reuse agentDir across agents. Auth/session state is per-agent.

My recommendation:

#

1 main agent
1–2 specialist agents only if they need different tools/auth
Subagents for bursty parallel jobs
Thread-bound sessions for long-running work

Docs:

If you want, paste:

openclaw --version
your agents, bindings, and subagents config block

and I’ll tune the layout for your exact setup.

serene grove Apr 17, 2026, 7:07 PM

#

What are the recommended values for runTimeoutSeconds and archiveAfterMinutes and maxConcurrent?

opal pantherBOT Apr 17, 2026, 7:08 PM

#

If you want a solid starting point, I’d use:

subagents: {
  runTimeoutSeconds: 900,
  archiveAfterMinutes: 60,
  maxConcurrent: 4,
}

Quick read on each:

runTimeoutSeconds: 900
Good default for real work.
Docs default is 0 (no timeout), but I usually would not leave it unlimited unless you truly want long-running jobs.
archiveAfterMinutes: 60

#

This is the docs default too, and it’s pretty sane.

maxConcurrent: 4
Good conservative starting point.
Docs default is 8, but subagents still share the same gateway/resources, so 8 can be too aggressive on smaller setups.

My rough rule:

small laptop / small VPS → maxConcurrent: 2-3
normal setup → maxConcurrent: 4
strong box + good provider limits → maxConcurrent: 6-8

So the short answer is:

safe default: 900 / 60 / 4
docs default: 0 / 60 / 8

#

Docs:

If you want, paste your machine/setup and I can suggest a tighter set for your workload.

viral pier Apr 17, 2026, 8:19 PM

#

Good setup with LLM and model for mac mini m4 24gb

opal pantherBOT Apr 17, 2026, 8:20 PM

#

Honestly, for a Mac mini M4 24GB, I’d treat it as a great OpenClaw host but not as a great fully-local multi-agent inference box.

My recommendation:

Run OpenClaw on the Mac
Use a strong cloud model for the main agent
Use a cheaper cloud model for subagents / heartbeats / routine work
Keep local models for experimenting, fallback, or light tasks, not your main multi-agent brain

Why:

24GB is fine for hosting the gateway and a nice local setup
but agentic tool use + multi-agent orchestration is where local models usually get flaky
local setups can work, they’re just usually worse for reliability, latency, and tool discipline

For this machine, I’d start with:

maxConcurrent: 2-4
runTimeoutSeconds: 900

#

archiveAfterMinutes: 60

If you want best real-world results, I would not make Ollama/LM Studio your primary orchestrator model on that Mac.

For the latest model picks, check:

And for fresh hands-on recommendations, ask in #models. Model advice gets stale fast, and that channel usually has the best current picks.

If you want, I can sketch a recommended Mac mini M4 24GB config for:

best quality
best cost/performance
mostly local

viral pier Apr 17, 2026, 8:22 PM

#

Yes

opal pantherBOT Apr 17, 2026, 8:23 PM

#

Let me verify the exact model config keys before I hand you a template.

#

Yep. For a Mac mini M4 24GB, I’d break it into 3 sane options.

1) Best quality, my recommendation

Use the Mac as the host, but keep inference cloud-first.

{
  agents: {
    defaults: {
      model: {
        primary: "<strong-cloud-main-model>",
        fallbacks: ["<reliable-cloud-fallback>"],
      },
      subagents: {
        model: "<cheap-reliable-cloud-worker-model>",
        runTimeoutSeconds: 900,

#

        archiveAfterMinutes: 60,
        maxConcurrent: 3,
      },
    },
  },
}

Good when:

you want the best multi-agent behavior
tool use matters
you care about reliability more than “fully local”

2) Best cost/performance, probably the sweet spot

Still cloud-first, but cheaper workers.

#

{
  agents: {
    defaults: {
      model: {
        primary: "<good-value-cloud-main-model>",
        fallbacks: ["<cheap-cloud-fallback>"],
      },
      subagents: {
        model: "<very-cheap-cloud-worker-model>",
        runTimeoutSeconds: 900,
        archiveAfterMinutes: 60,
        maxConcurrent: 4,
      },
    },
  },

#

Good when:

you want solid results
you run lots of subagents
you care about cost

3) Mostly local, only if you really want it

I’m a bit wary of this on 24GB for agentic work.

{
  agents: {
    defaults: {

#

      model: {
        primary: "<local-model>",
        fallbacks: ["<cloud-fallback-for-hard-cases>"],
      },
      subagents: {
        model: "<cheap-cloud-worker-model>",
        runTimeoutSeconds: 600,
        archiveAfterMinutes: 45,
        maxConcurrent: 2,
      },
    },
  },
}

Good when:

#

you want local-first for privacy/experiments
you accept weaker tool calling and more babysitting

My honest take: for OpenClaw multi-agent, I’d choose option 2 on that machine.
It’s usually the nicest balance of quality, cost, and not fighting the setup.

Also:

keep maxConcurrent modest on a Mac mini, 3-4 is usually healthier than 8
use local models for side agents / experiments, not your main orchestrator
if you make a specialist agent, lock it down with per-agent tools/sandbox

For actual model picks, check:

And ask in #models for the current best IDs, since that changes fast.

#

If you want, next I can give you a copy-paste config template for:

cloud-first
hybrid
mostly-local

viral pier Apr 17, 2026, 8:27 PM

#

Suggest for for one agent with subagents

opal pantherBOT Apr 17, 2026, 8:28 PM

#

Yep, for one main agent + subagents, this is the setup I’d use.

{
  agents: {
    defaults: {
      model: {
        primary: "<main-cloud-model>",
        fallbacks: ["<reliable-fallback-model>"],
      },
      subagents: {
        model: "<cheap-worker-model>",
        runTimeoutSeconds: 900,
        archiveAfterMinutes: 60,
        maxConcurrent: 3,
        maxSpawnDepth: 1,

#

      },
    },
    list: [
      {
        id: "main",
        default: true,
        workspace: "~/.openclaw/workspace",
      },
    ],
  },

  channels: {
    discord: {
      threadBindings: {
        enabled: true,

#

        spawnSubagentSessions: true,
        idleHours: 24,
        maxAgeHours: 168,
      },
    },
  },
}

Why I like this:

1 main agent keeps things simple
subagents do the burst work
cheap worker model saves money
maxSpawnDepth: 1 prevents subagents from spawning more subagents and getting weird
maxConcurrent: 3 is a good starting point on a Mac mini

#

thread bindings make follow-ups much nicer on Discord

I’d only add more top-level agents if you need:

different auth
different tool restrictions
different persona/workspace

Docs:

If you want, I can turn this into a full copy-paste config with comments for your Mac.

viral pier Apr 17, 2026, 10:51 PM

#

Auto upadate openclaw

opal pantherBOT Apr 17, 2026, 10:52 PM

#

Checking the update docs so I don’t send you stale instructions.

#

Yep, there is an auto-updater, but it’s off by default.

Add this to ~/.openclaw/openclaw.json:

{
  update: {
    channel: "stable",
    auto: {
      enabled: true,
      stableDelayHours: 6,
      stableJitterHours: 12,
      betaCheckIntervalHours: 1,
    },
  },
}

#

Quick notes:

stable: auto-applies after a delay/jitter window
beta: checks hourly and auto-applies
dev: no automatic apply, use openclaw update manually

Manual update is still the recommended/safest path:

openclaw update
openclaw update --dry-run
openclaw update status

Docs:

#

If you want, I can also give you a full recommended openclaw.json update block for a Mac mini setup.

viral pier Apr 17, 2026, 11:20 PM

#

Optimize models based on usage or work type

opal pantherBOT Apr 17, 2026, 11:21 PM

#

I’m checking the per-agent model override docs before I suggest a layout.

#

Yep, that’s the right way to think about it.

I’d optimize by role, not try to force one model to do everything.

Recommended split

Main agent → best general model you trust for tool use
agents.defaults.model
Subagents → cheaper worker model
agents.defaults.subagents.model
Vision / screenshots / UI → separate vision-capable model
agents.defaults.imageModel
PDF / doc-heavy work → separate doc-friendly model
agents.defaults.pdfModel

#

Specialist agent (only if needed) → override per agent
agents.list[].model

Good pattern

{
  agents: {
    defaults: {
      model: {
        primary: "<main-general-model>",
        fallbacks: ["<general-fallback>"],
      },

      subagents: {
        model: "<cheap-worker-model>",

#

        runTimeoutSeconds: 900,
        archiveAfterMinutes: 60,
        maxConcurrent: 3,
      },

      imageModel: {
        primary: "<vision-model>",
        fallbacks: ["<vision-fallback>"],
      },

      pdfModel: {
        primary: "<doc-model>",
        fallbacks: ["<doc-fallback>"],
      },
    },

#


    list: [
      {
        id: "main",
        default: true,
        workspace: "~/.openclaw/workspace",
      },

      {
        id: "coding",
        workspace: "~/.openclaw/workspace-coding",
        model: {
          primary: "<coding-model>",
          fallbacks: ["<coding-fallback>"],
        },

#

      },
    ],
  },
}

My recommendation for your use case though:

if you want one agent + subagents, keep it simpler
use:
- 1 strong main model
- 1 cheaper subagent model
- 1 vision model
- 1 PDF model
only add extra top-level agents if the job is really different

#

So basically:
optimize by tool/work type first, by extra agents second.

Docs:

And for the actual model IDs, ask in #models since those recommendations go stale fast.

If you want, I can draft a single-agent optimized config with placeholders for:

chat
coding
research
vision
pdf
subagents

viral pier Apr 17, 2026, 11:23 PM

#

Sure

#

Draft me

opal pantherBOT Apr 17, 2026, 11:27 PM

#

Yep, here’s a single-agent + subagents draft you can start from.

{
  agents: {
    defaults: {
      // Main chat / coding / research model
      model: {
        primary: "<main-general-model>",
        fallbacks: ["<main-fallback-model>"],
      },

      // Vision work: screenshots, browser snapshots, images
      imageModel: {
        primary: "<vision-model>",
        fallbacks: ["<vision-fallback-model>"],

#

      },

      // PDFs / doc-heavy work
      pdfModel: {
        primary: "<pdf-model>",
        fallbacks: ["<pdf-fallback-model>"],
      },

      // General agent behavior
      thinkingDefault: "low",
      timeoutSeconds: 600,
      maxConcurrent: 3,
      params: {
        cacheRetention: "long",
      },

#


      // Worker subagents
      subagents: {
        model: "<cheap-worker-model>",
        runTimeoutSeconds: 900,
        archiveAfterMinutes: 60,
        maxConcurrent: 3,
        maxSpawnDepth: 1,
      },
    },

    list: [
      {
        id: "main",
        default: true,

#

        workspace: "~/.openclaw/workspace",
      },
    ],
  },

  channels: {
    discord: {
      threadBindings: {
        enabled: true,
        spawnSubagentSessions: true,
        idleHours: 24,
        maxAgeHours: 168,
      },
    },
  },

#

How I’d fill it in

<main-general-model> = your best all-around model for tool use
<cheap-worker-model> = cheaper model for subagents
<vision-model> = best screenshot/image model
<pdf-model> = best doc/PDF model

Why this layout is good

one main brain
cheaper worker subagents
separate vision/pdf routing
Discord thread sessions stay tidy

#

no unnecessary extra agents yet

One important bit: if you want different models for coding vs research, that usually means either:

switching /model per session, or
adding a dedicated specialist agent later

For actual model IDs, check:

If you want, next I can make this into:

best quality
best cost/performance
mostly local

viral pier Apr 18, 2026, 12:05 AM

#

Ios app for openclaw

opal pantherBOT Apr 18, 2026, 12:06 AM

#

Let me check the current docs/state so I don’t give you outdated app info.

#

I’m checking the cleanest docs links for mobile access.

#

Right now, there isn’t a public official iOS app / TestFlight for OpenClaw yet.

Today the practical mobile options are:

use the web UI from your phone
or talk to OpenClaw through a chat channel like Telegram / WhatsApp / Discord

Good docs:

So short version:

iOS native app: not publicly available yet
mobile access today: browser or chat channels

#

If you want, I can suggest the best iPhone-friendly setup right now.

viral pier Apr 18, 2026, 12:07 AM

#

Yes do you rhink discord or telegram which is better for two people

opal pantherBOT Apr 18, 2026, 12:08 AM

#

For two people, my honest take is:

Telegram = better for simple daily use
Discord = better for serious multi-agent setups

I’d choose Telegram if you want:

cleaner phone-first UX
quick private chats
less setup/social overhead
“just talk to the bot” vibes

I’d choose Discord if you want:

threads
better organization
easier multi-agent/session management
a more “workspace” feel

#

For your specific thread, since you’re asking about multi-agent optimization, I’d lean Discord.
The big reason is that thread-bound subagent sessions are much nicer there.

So my short recommendation:

2 people, casual/personal → Telegram
2 people, structured multi-agent work → Discord

Docs:

If you want, I can give you a “best setup for 2 people on Discord” or “…on Telegram” next.

viral pier Apr 18, 2026, 4:28 AM

#

How to store the openrouter api key on mac mini

opal pantherBOT Apr 18, 2026, 4:29 AM

#

Checking the auth docs so I can give you the clean path.

#

Best way on a Mac mini running the gateway as a daemon:

Why this is the good path

On macOS, the daemon/service usually does not inherit your shell env, so a plain export OPENROUTER_API_KEY=... is often not enough long-term.

Alternative

If you want OpenClaw to store it in auth profiles instead:

openclaw models auth paste-token --provider openrouter

That writes it into the agent auth store.

#

So short version:

daemon on Mac mini → use ~/.openclaw/.env
managed auth profile path → use openclaw models auth paste-token --provider openrouter

Docs:

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for future users.

viral pier Apr 18, 2026, 4:31 AM

#

Open claw onboard stores the key?

opal pantherBOT Apr 18, 2026, 4:32 AM

#

Yep, openclaw onboard can store API keys for daemon use.

So if you enter your OpenRouter key during onboarding, that’s a valid path.

Afterward, verify with:

openclaw models status
openclaw doctor

If you already finished onboarding and just want to add it now, I’d use either:

openclaw models auth paste-token --provider openrouter

#

or put it in:

~/.openclaw/.env

Docs:

https://docs.openclaw.ai/gateway/authentication

If you want, I can tell you which of the 3 is best for your Mac mini:

onboard
auth paste-token
.env

viral pier Apr 18, 2026, 4:32 AM

#

Yes

opal pantherBOT Apr 18, 2026, 4:33 AM

#

For a Mac mini, my order would be:

1) Best overall: `~/.openclaw/.env`

Best for a long-running daemon/service.

Why:

simple
reliable on macOS
survives shell/session issues better

2) Best for first-time setup: `openclaw onboard`

Best if you’re setting everything up fresh and want the wizard to handle it.

Why:

easiest path
less manual fiddling

#

3) Best if you want OpenClaw-managed provider auth: `models auth paste-token`

Good if you specifically want it stored in the auth-profile path.

openclaw models auth paste-token --provider openrouter

My recommendation

For your Mac mini, I’d do:

fresh install → openclaw onboard
already installed / want predictable daemon behavior → ~/.openclaw/.env

So if you want the shortest answer:
.env is the most practical long-term choice on a Mac mini.

Docs:

#

https://docs.openclaw.ai/gateway/authentication

Glad we narrowed that down a bit 🙂

viral pier Apr 18, 2026, 4:40 AM

#

How to setup two different users using the bot

opal pantherBOT Apr 18, 2026, 4:41 AM

#

Best way is usually:

If you want true separation

Use one agent per user.

That gives each person their own:

workspace
memory/session history
auth profiles
persona/settings

Pattern

{
  agents: {

#

    list: [
      { id: "user1", default: true, workspace: "~/.openclaw/workspace-user1" },
      { id: "user2", workspace: "~/.openclaw/workspace-user2" },
    ],
  },

  bindings: [
    {
      agentId: "user1",
      match: {
        channel: "telegram",
        peer: { kind: "direct", id: "<user1-chat-id>" },
      },
    },
    {

#

      agentId: "user2",
      match: {
        channel: "telegram",
        peer: { kind: "direct", id: "<user2-chat-id>" },
      },
    },
  ],
}

Same idea works for Discord, WhatsApp, etc.
You just change channel and the peer.id.

Setup flow

Create two agents

#

openclaw agents add user1
openclaw agents add user2

Add bindings so each person routes to their own agent
Restart

openclaw gateway restart

Verify

openclaw agents list --bindings

#

Important

If both people talk in the same shared group/chat, they will not feel truly separate.
If you want clean separation, use:

separate DMs, or
separate channels/threads, or
separate bound conversations

Also, don’t reuse the same agentDir across agents.

Docs:

If you want, I can draft the exact config for:

Discord
Telegram

#

WhatsApp

viral pier Apr 18, 2026, 4:42 AM

#

Discord config

opal pantherBOT Apr 18, 2026, 4:43 AM

#

I’m verifying the Discord binding shape before I draft the config.

#

I’m checking whether Discord DM bindings should target the user id or the DM channel id.

#

I’m checking whether users can be set per Discord channel or only per guild.

#

If you want 2 different users on Discord, I’d do it with 2 private channels + 2 agents.
That’s the cleanest setup.

{
  agents: {
    list: [
      {
        id: "user1",
        default: true,
        workspace: "~/.openclaw/workspace-user1",
      },
      {
        id: "user2",
        workspace: "~/.openclaw/workspace-user2",
      },

#

    ],
  },

  bindings: [
    {
      agentId: "user1",
      match: {
        channel: "discord",
        peer: { kind: "channel", id: "USER1_CHANNEL_ID" },
      },
    },
    {
      agentId: "user2",
      match: {
        channel: "discord",

#

        peer: { kind: "channel", id: "USER2_CHANNEL_ID" },
      },
    },
  ],

  channels: {
    discord: {
      enabled: true,
      groupPolicy: "allowlist",
      guilds: {
        "YOUR_GUILD_ID": {
          requireMention: false,
          channels: {
            "USER1_CHANNEL_ID": {
              allow: true,

#

              requireMention: false,
              users: ["USER1_DISCORD_ID"],
            },
            "USER2_CHANNEL_ID": {
              allow: true,
              requireMention: false,
              users: ["USER2_DISCORD_ID"],
            },
          },
        },
      },
    },
  },
}

#

What this does

user1 channel always routes to user1 agent
user2 channel always routes to user2 agent
each user gets separate memory/workspace
no context mixing

I’d also do this

make both Discord channels private
set normal Discord permissions too, not just OpenClaw config

Then restart and verify:

openclaw gateway restart
openclaw agents list --bindings

#

Docs:

If you want, I can also draft the DM-based Discord version.

viral pier Apr 18, 2026, 5:39 AM

#

Can i run two agents in my current m4 mini 24gb?

opal pantherBOT Apr 18, 2026, 5:40 AM

#

Yes, absolutely, if you’re using cloud models.

A Mac mini M4 24GB is totally fine for:

2 OpenClaw agents
separate workspaces/auth/sessions
normal Discord/Telegram use
some subagents too, if you keep concurrency reasonable

Where it gets shaky is if you want:

2 serious local models
heavy parallel local inference
lots of tool-heavy agentic work all at once

So the real answer is:

2 agents + cloud-backed models → yes, good setup
2 agents + mostly local LLMs → possible, but not the setup I’d recommend

#

For your machine, I’d start with:

2 agents
maxConcurrent: 2-4
cloud main model
cheaper cloud subagent model

Docs:

If this helped, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for future users.

viral pier Apr 18, 2026, 5:54 AM

#

How about using same agent and having two dofferent memoriesp

opal pantherBOT Apr 18, 2026, 5:54 AM

#

You can, but it’s a bit leaky.

Same agent + two channels/threads

This gives you separate session history, which is fine for light separation.

Good if you want:

same persona
same tools
same auth
same workspace
just different chat histories

What is still shared

With the same agent, these are still shared:

workspace/files
auth profiles

#

AGENTS.md / SOUL.md / persona
tool policy
broader agent-level memory setup

So if you mean truly different memories, I would not use the same agent.

My rule of thumb

Same agent + separate channels/threads → okay for simple separation
Separate agents → better for real per-user memory/isolation

For Discord specifically:

2 private channels with the same agent = simple
2 private channels with 2 agents = cleaner and more correct

So yes, possible, but if you want real user separation, I’d still pick 2 agents.

#

Docs:

If you want, I can sketch both patterns side by side:

same agent, 2 channels
2 agents, 2 channels

viral pier Apr 18, 2026, 5:57 AM

#

Can i use one agent for one person with mini m4 16gb with local llms?

opal pantherBOT Apr 18, 2026, 5:57 AM

#

Yes, for one person and one agent, a Mac mini M4 16GB can work with local LLMs.

But I’d frame it like this:

simple chat / light personal use → yes
heavy tool use / coding / multi-agent orchestration → much less fun
fully local + high reliability → I would keep expectations modest

My honest recommendation for 16GB:

1 agent
no real subagent fan-out
maxConcurrent: 1
local model for basic work
cloud fallback if you want reliability on harder tasks

So:

#

1 person + 1 local agent → reasonable
1 person + serious agentic local workflow → possible, but probably frustrating at times

If you want the least pain, I’d do hybrid:

local for cheap/basic stuff
cloud fallback for hard/tool-heavy work

Docs:

If you want, I can sketch a good 16GB single-user config next.

viral pier Apr 18, 2026, 5:59 AM

#

Yes also what local llms for simple tasks and what llms for cloud for coding and other stuff

opal pantherBOT Apr 18, 2026, 5:59 AM

#

I wouldn’t hardcode a model list here, because that gets stale fast, but the selection strategy is pretty clear:

Local on a Mini M4 16GB

Use local only for simple tasks like:

casual chat
summarizing
rewriting
note cleanup
light classification/tagging
simple personal automation prompts

What to look for:

small/medium instruct model
decent context window
fast enough on your box
okay-ish tool discipline, but don’t expect miracles

#

What I would not use local for on 16GB:

main coding agent
complex multi-step tool use
heavy browser / file orchestration
multi-agent fan-out

Cloud

For cloud, split by job:

coding / main agent → strongest tool-reliable model you can afford
subagents / workers → cheaper reliable cloud model
vision / screenshots → dedicated vision model
PDF / docs → doc-friendly model
heartbeat / cheap background work → cheapest acceptable model

My real recommendation

For your setup:

#

local = simple/personal/light tasks
cloud = coding, serious tool use, harder reasoning
hybrid = best overall

So the practical answer is:

if it’s simple, local is fine
if it’s coding or agentic, go cloud

Docs:

For the actual current model IDs, ask in #models. That’s the best place for fresh real-world picks.

If you want, I can draft you a Mini M4 16GB hybrid config with placeholders for:

#

local simple model
cloud main coding model
cloud worker model
vision model
pdf model

viral pier Apr 18, 2026, 6:01 AM

#

Yes

opal pantherBOT Apr 18, 2026, 6:01 AM

#

Yep, here’s the Mini M4 16GB hybrid draft I’d use.

{
  agents: {
    defaults: {
      // Best overall: cloud-first for serious work
      model: {
        primary: "<cloud-main-coding-model>",
        fallbacks: ["<local-simple-model>"],
      },

      // Keep vision/doc work in cloud
      imageModel: {
        primary: "<cloud-vision-model>",
        fallbacks: ["<cloud-vision-fallback>"],

#

      },
      pdfModel: {
        primary: "<cloud-pdf-model>",
        fallbacks: ["<cloud-pdf-fallback>"],
      },

      thinkingDefault: "low",
      timeoutSeconds: 600,
      maxConcurrent: 1,
      params: {
        cacheRetention: "long",
      },

      subagents: {
        model: "<cheap-cloud-worker-model>",

#

        runTimeoutSeconds: 900,
        archiveAfterMinutes: 60,
        maxConcurrent: 1,
        maxSpawnDepth: 1,
      },
    },

    list: [
      {
        id: "main",
        default: true,
        workspace: "~/.openclaw/workspace",
      },
    ],
  },

#

How I’d use it

cloud main model = coding, tool use, harder tasks
local fallback = light/simple stuff
cloud worker model = subagents
cloud vision/pdf = anything image/doc heavy

Important nuance

OpenClaw can automatically split vision and PDF to dedicated models, but for normal text/chat/coding it does not magically know “simple local task vs hard cloud task”.

So for general text work, the cleanest options are:

cloud-first like above, or

#

manual /model switching, or
later, a second agent for local-only simple work

If you want local-first, swap this:

primary: "<local-simple-model>",
fallbacks: ["<cloud-main-coding-model>"]

But I’d only do that if you’re okay with weaker tool use.

Docs:

#

For the actual current model IDs, ask in #models.

If this helped, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for future users.

jovial fieldBOT Apr 18, 2026, 6:53 AM

#

viral pier Apr 18, 2026, 12:59 PM

#

Qwen 3.5 local model and hybrid method works on this specs?

opal pantherBOT Apr 18, 2026, 1:00 PM

#

If you mean the Mini M4 16GB we were just talking about, then:

Yes, a local Qwen-family model + hybrid setup can work.
I actually think hybrid is the right move on that machine.

My honest take:

local Qwen-family model → fine for simple tasks
cloud model → better for coding, tool use, harder reasoning
hybrid → best balance on those specs

On 16GB

Reasonable:

1 person
1 main agent
maxConcurrent: 1
local for light stuff

#

cloud for serious work

On 24GB

More comfortable:

same hybrid idea
a bit more breathing room
still wouldn’t make local your main coding/orchestrator model

So short answer:

works? yes
best approach? also yes, if you keep local for lighter tasks and cloud for the hard stuff

For the exact Qwen variant / quant / current best pick, I’d ask in #models. That changes too fast for me to give a stable answer here.

Docs:

https://docs.openclaw.ai/gateway/local-models

#

https://docs.openclaw.ai/concepts/models

If this helped, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for future users.

viral pier Apr 18, 2026, 1:04 PM

#

Can i setup something like discord channel routes the model by channel its used

opal pantherBOT Apr 18, 2026, 1:04 PM

#

Yes, absolutely, but the clean way is:

route the Discord channel to a different agent, and give that agent its own model.

So it’s not really:

channel → model directly

It’s:

channel → agent
agent → model

Example

#

{
  agents: {
    list: [
      {
        id: "chat",
        default: true,
        workspace: "~/.openclaw/workspace-chat",
        model: "<cheap-general-model>",
      },
      {
        id: "coding",
        workspace: "~/.openclaw/workspace-coding",
        model: "<strong-coding-model>",
      },
    ],

#

  },

  bindings: [
    {
      agentId: "chat",
      match: {
        channel: "discord",
        peer: { kind: "channel", id: "GENERAL_CHANNEL_ID" },
      },
    },
    {
      agentId: "coding",
      match: {
        channel: "discord",
        peer: { kind: "channel", id: "CODING_CHANNEL_ID" },

#

      },
    },
  ],

  channels: {
    discord: {
      groupPolicy: "allowlist",
      guilds: {
        "YOUR_GUILD_ID": {
          channels: {
            "GENERAL_CHANNEL_ID": {
              allow: true,
              requireMention: false,
            },
            "CODING_CHANNEL_ID": {

#

              allow: true,
              requireMention: false,
            },
          },
        },
      },
    },
  },
}

Result

#general can use one model
#coding can use another
each channel gets its own routed agent/session behavior

#

So yes, channel-based model routing is doable, just via bindings + per-agent model.

Docs:

If you want, I can draft a 3-channel Discord setup like:

#chat
#coding
#research

viral pier Apr 18, 2026, 1:05 PM

#

But does it work with the currenr setup we were talking hybrid

opal pantherBOT Apr 18, 2026, 1:05 PM

#

Yes, it works fine with hybrid.

That’s actually one of the nicer ways to use hybrid:

#chat → agent with local-first model config
#coding → agent with cloud-first model config
#research → agent with its own model/fallbacks if you want

So the pattern becomes:

channel → agent
agent → hybrid model setup

Example idea

chat agent
model.primary = <local-simple-model>

#

fallbacks = [<cloud-general-fallback>]

coding agent
model.primary = <cloud-coding-model>
fallbacks = [<cloud-fallback>]
shared imageModel / pdfModel can still stay cloud if you want

Important nuance

If you stay on one single agent, hybrid won’t change by channel.
To get different hybrid behavior per channel, you want different agents bound to different channels.

So short answer:

hybrid + channel routing → yes
one agent + different hybrid behavior per channel → not really, unless you split into multiple agents

#

Honestly, this is one of the best reasons to use multi-agent on Discord.

If you want, I can draft the exact config for:

#chat = local-first
#coding = cloud-first
#research = cloud-first + cheaper workers

viral pier Apr 18, 2026, 1:06 PM

#

Does it work with the current specs

opal pantherBOT Apr 18, 2026, 1:06 PM

#

Yes, with the current specs, that setup can work.

If you mean the Mini M4 16GB

Still yes, but I’d keep it like this:

#chat = local-first, light/simple work
#coding = cloud-first
#research = cloud-first
don’t try to run multiple heavy local workloads at once

If you mean the Mini M4 24GB

Also yes, and it’ll feel a bit more comfortable.

My honest recommendation

On either machine, the setup works best when:

local is only for lighter tasks

#

cloud handles the hard/agentic channels
you keep local concurrency modest

So short version:

works on 16GB? yes, if you keep local lightweight
works on 24GB? yes, more comfortably
works best? hybrid, not fully local

That’s actually a pretty sensible setup for your specs.

viral pier Apr 18, 2026, 1:07 PM

#

Sure help me setup this

opal pantherBOT Apr 18, 2026, 1:08 PM

#

Yep, here’s a good Discord hybrid setup for what we were talking about:

#chat = local-first
#coding = cloud-first
#research = cloud-first
shared worker model for subagents
vision/pdf stay cloud

1) Create 3 Discord channels

Make these in your server:

#chat
#coding
#research

Then copy:

guild/server ID

#

each channel ID

2) Use a config like this

{
  agents: {
    defaults: {
      imageModel: {
        primary: "<cloud-vision-model>",
        fallbacks: ["<cloud-vision-fallback>"],
      },
      pdfModel: {
        primary: "<cloud-pdf-model>",
        fallbacks: ["<cloud-pdf-fallback>"],
      },

#


      thinkingDefault: "low",
      timeoutSeconds: 600,
      maxConcurrent: 2, // use 3 if you're on 24GB and it feels fine

      subagents: {
        model: "<cheap-cloud-worker-model>",
        runTimeoutSeconds: 900,
        archiveAfterMinutes: 60,
        maxConcurrent: 2,
        maxSpawnDepth: 1,
      },
    },

    list: [

#

      {
        id: "chat",
        default: true,
        workspace: "~/.openclaw/workspace-chat",
        model: {
          primary: "<local-simple-model>",
          fallbacks: ["<cloud-general-fallback>"],
        },
      },
      {
        id: "coding",
        workspace: "~/.openclaw/workspace-coding",
        model: {
          primary: "<cloud-coding-model>",
          fallbacks: ["<cloud-coding-fallback>"],

#

        },
      },
      {
        id: "research",
        workspace: "~/.openclaw/workspace-research",
        model: {
          primary: "<cloud-research-model>",
          fallbacks: ["<cloud-general-fallback>"],
        },
      },
    ],
  },

  bindings: [
    {

#

      agentId: "chat",
      match: {
        channel: "discord",
        peer: { kind: "channel", id: "CHAT_CHANNEL_ID" },
      },
    },
    {
      agentId: "coding",
      match: {
        channel: "discord",
        peer: { kind: "channel", id: "CODING_CHANNEL_ID" },
      },
    },
    {
      agentId: "research",

#

      match: {
        channel: "discord",
        peer: { kind: "channel", id: "RESEARCH_CHANNEL_ID" },
      },
    },
  ],

  channels: {
    discord: {
      enabled: true,
      groupPolicy: "allowlist",
      threadBindings: {
        enabled: true,
        spawnSubagentSessions: true,
        idleHours: 24,

#

        maxAgeHours: 168,
      },
      guilds: {
        "YOUR_GUILD_ID": {
          channels: {
            "CHAT_CHANNEL_ID": {
              allow: true,
              requireMention: false,
            },
            "CODING_CHANNEL_ID": {
              allow: true,
              requireMention: false,
            },
            "RESEARCH_CHANNEL_ID": {
              allow: true,

#

              requireMention: false,
            },
          },
        },
      },
    },
  },
}

3) Restart + verify

openclaw gateway restart
openclaw agents list --bindings

#

openclaw models status

4) My recommendation by machine

Mini M4 16GB → keep maxConcurrent: 2, local only in #chat
Mini M4 24GB → same layout, maybe maxConcurrent: 3

5) Important

For the actual model IDs, ask in #models.
That part changes too fast, but this routing structure is solid.

Docs:

#

https://docs.openclaw.ai/gateway/local-models

If you want, next send me:

your OpenClaw version
guild ID
the 3 channel IDs

and I’ll turn this into a near copy-paste config for you.

viral pier Apr 18, 2026, 1:29 PM

#

How to also setup auto routing based on task automatically and how do subagents take the lower model for main agent

opal pantherBOT Apr 18, 2026, 1:29 PM

#

Two separate pieces here:

1) Auto-routing by task

Short answer:

Partly, yes. Fully, not really.

What OpenClaw can already route automatically:

images / screenshots → imageModel
PDFs / docs → pdfModel

What it does not really do automatically for normal text:

“coding task → model A”
“simple task → local model B”
“research task → model C”

For that, the clean options are:

#

channel → agent → model (best / most reliable)
manual /model switch per session
separate agents for different roles

So if you want true task-based routing for chat/coding/research, I’d still use:

#chat → local-first agent
#coding → cloud-first agent
#research → research agent

2) Make subagents use a cheaper/lower model

That part is easy.

Set:

#

  agents: {
    defaults: {
      model: {
        primary: "<strong-main-model>",
      },
      subagents: {
        model: "<cheap-worker-model>",
        runTimeoutSeconds: 900,
        archiveAfterMinutes: 60,
        maxConcurrent: 2,
      },
    },
  },
}

#

That means:

main agent uses the stronger model
subagents use the cheaper one

You can also override this per agent if needed.

My honest recommendation

Use:

main/channel agents for role-based routing
subagents for cheaper parallel work
imageModel/pdfModel for automatic non-text routing

That’s the cleanest current setup.

Docs:

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

#Multi agent setup

1) Best quality, my recommendation

2) Best cost/performance, probably the sweet spot

3) Mostly local, only if you really want it

Recommended split

Good pattern

How I’d fill it in

Why this layout is good

I’d choose Telegram if you want:

I’d choose Discord if you want:

Recommended

Why this is the good path

Alternative

1) Best overall: ~/.openclaw/.env

2) Best for first-time setup: openclaw onboard

3) Best if you want OpenClaw-managed provider auth: models auth paste-token

My recommendation

If you want true separation

Pattern

Setup flow

Important

What this does

I’d also do this

Same agent + two channels/threads

What is still shared

My rule of thumb

Local on a Mini M4 16GB

Cloud

My real recommendation

How I’d use it

Important nuance

On 16GB

On 24GB

Example

Result

Example idea

Important nuance

If you mean the Mini M4 16GB

If you mean the Mini M4 24GB

My honest recommendation

1) Create 3 Discord channels

2) Use a config like this

3) Restart + verify

4) My recommendation by machine

5) Important

1) Auto-routing by task

Short answer:

2) Make subagents use a cheaper/lower model

My honest recommendation

1) Best overall: `~/.openclaw/.env`

2) Best for first-time setup: `openclaw onboard`

3) Best if you want OpenClaw-managed provider auth: `models auth paste-token`