#Multiple Agent Cost

1 messages · Page 1 of 1 (latest)

dusty bear
#

I have multiple run subagents but the tasks they are doing are supposed to be more consistent and automnous so I want to add them as a whole new agent to my openclaw setup alongside my main agent, but I want my main agent to be able to communcate with them. I don't need to be told how to setup another agent, I just want to know the costs I should expect when adding multiple agents in my openclaw system, if I add more will it effect my ram? even when they aren't doing anything within that current moment? will it cost in CPU or something else? even when they aren't currently doing any task? will my main agent be able to communicate with them? Let's say I have an extra 8gb ram/Vram on my mac mini that my openclaw is running on, how many agents should I be able to run on that without a problem

limber sleetBOT
misty bladeBOT
#

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

limber sleetBOT
valid orchidBOT
#

Let me verify the docs/source for this before I answer, so I don’t hand-wave the resource part.

#

Short answer, yes, that pattern is fine.

  • Adding agents does not create a standing API bill by itself.
  • Idle agents usually cost a little disk and a small amount of gateway memory/bookkeeping, not much CPU.
  • The big costs happen when they are actively running, especially model calls, browser/exec work, media, embeddings, or local-model inference.
  • Your main agent can communicate with them, but cross-agent access is not on by default. It is supported through the session tools, just gated by config.

A few important specifics:

  1. OpenClaw multi-agent is one gateway hosting multiple isolated agents

    • each agent gets its own workspace, auth store, and session store
    • it is not the same as spinning up a whole separate always-busy model process per agent

  2. Idle cost

    • RAM/CPU: usually low
    • Disk: grows with each agent’s workspace + transcripts
    • API cost: only when that agent actually does work, or if you enabled background stuff like heartbeats, crons, memory indexing/dreaming, etc.
#

  1. On a Mac mini, “RAM/VRAM” is basically one shared unified-memory pool

    • if you use cloud/API models, extra agents are usually cheap while idle
    • if you use local models through Ollama/LM Studio/llama.cpp, the model is the thing that really eats memory, not the agent definition itself

  2. How many with 8 GB extra headroom?

    • there is no clean agent-per-GB rule
    • with API-backed agents, I would worry much more about concurrent active runs than the number of idle configured agents
    • with local models, 8 GB extra can disappear fast, a single small-ish local model can eat a lot of that budget

So my practical answer is:

  • If these agents mostly use API models: several extra persistent agents should be fine, idle overhead is usually not the problem.
  • If they use local models: be conservative. The limit is likely the model runtime, not OpenClaw’s agent count.
  • If you want a safe starting point: start with 2 to 4 extra persistent agents, then watch real usage under load. You can usually go higher if they are mostly idle/API-based.

Relevant docs:

dusty bear
#

they all use API models, that being said how many "concurrent active runs" do you think would be a limit for me with the 8gb ram and CPU usage

valid orchidBOT
#

If they’re all API-model backed, the limit is mostly host-side concurrency, not model RAM.

My practical guess for a Mac mini with ~8 GB real headroom:

  • 1 to 3 concurrent active runs: very safe
  • 4 to 6: usually fine
  • 6 to 8: probably still okay if they are mostly text/API work
  • 8+: I’d only trust after stress testing

Why:

  • API models move the heavy inference off your Mac
  • so your Mac is mostly paying for:
    • Node/OpenClaw runtime
    • transcript/session handling
    • tool execution
    • JSON parsing/streaming
#
  • any browser/PDF/media/file work you trigger locally

So the real question is what each run does locally:

  • Light runs: reading files, planning, messaging, API calls → you can push higher
  • Heavy runs: browser, large PDFs, image/video, lots of exec, embeddings/indexing, ffmpeg, etc. → stay lower, more like 2 to 4

A good rule of thumb:

  • Many configured agents: fine
  • Active runs at once: start with 4
  • If stable, try 6
  • Treat 8 as a reasonable upper test target, not a guaranteed comfort zone

That lines up pretty well with OpenClaw’s default subagent concurrency safety cap of 8:
https://docs.openclaw.ai/tools/subagents