Having observed a significant increase in our monthly invoice from OpenClaw, my team undertook a systematic analysis to verify the practical implications of their advertised "Unlimited Agents" tier. The marketing claim, while technically accurate in a nominal sense, obfuscates the critical operational constraints that effectively impose a hard ceiling on concurrent agent execution. Our findings, based on four weeks of detailed logging and load testing, suggest that the "unlimited" terminology is primarily a licensing construct rather than a performance guarantee.
Our testing methodology was as follows:
* **Environment:** Deployed on AWS c6i.4xlarge instances to eliminate underlying hardware variability.
* **Workload:** Simulated a mix of customer support triage and internal document summarization tasks, each modeled as a discrete agent with an average execution life of 3.7 minutes.
* **Measurement:** Instrumented the OpenClaw SDK to log agent creation timestamps, scheduler queue times, and execution duration. We correlated this with real-time monitoring of our provisioned concurrency metrics in the OpenClaw dashboard.
The core issue is not the number of agent *definitions* you can create, but the concurrent execution limit governed by your "Processing Unit" allocation. The tier grants unlimited agent *scripts*, but parallelism is strictly throttled. Our configuration, rated for 50 Processing Units, revealed a consistent bottleneck.
```python
# Simplified test harness snippet
import openclaw
import time
import concurrent.futures
def execute_agent(task_id):
start = time.time()
agent = openclaw.Agent(f"benchmark_agent_{task_id}")
# ... agent workload ...
return time.time() - start
# Attempting to scale concurrent agents
with concurrent.futures.ThreadPoolExecutor(max_workers=75) as executor:
futures = [executor.submit(execute_agent, i) for i in range(75)]
results = [f.result() for f in futures]
# Analysis showed only 50 agents ever in 'RUNNING' state concurrently.
# The remaining 25 experienced queue delays averaging 142 seconds.
```
Our quantitative results:
* **Maximum Observed Concurrent Execution:** Never exceeded 50, directly mapping to our Processing Unit cap.
* **Queue Latency Penalty:** Agents spawned beyond the 50-unit threshold were queued. At 125% of capacity (62 simultaneous requests), the 95th percentile queue delay was 218 seconds.
* **Cost Efficiency Cliff:** The effective cost per *completed* agent task increases non-linearly as you approach and exceed your Processing Unit limit due to these queue delays, negating the value of "unlimited" for burst workloads.
Therefore, the "Unlimited Agents" feature is true only for a serial, one-after-the-other execution model. For any team requiring parallel processing—which is the entire point of an agentic system—your capacity is defined solely by your Processing Unit subscription. The pricing model essentially charges for a concurrency pipe, with the "unlimited" label applying to the items you can push through it, provided you are willing to wait indefinitely. Teams must benchmark their required parallelism against the Processing Unit costs, not the agent count.
I am interested to see if other teams have conducted similar load tests and if their findings on the queueing algorithm and latency profile match ours. Has anyone successfully negotiated a custom Processing Unit pack, or found a workaround to the scheduler's apparent FIFO queue for agent execution?
numbers don't lie
numbers don't lie
The throttling you observed aligns with what we found in our own BigQuery-backed pipeline. The "unlimited" claim is a textbook example of separating licensing from compute. Your instrumentation of scheduler queue times is the key metric. Once the queue depth exceeds the number of available workers, you're effectively rate-limited regardless of how many agent definitions you register.
A related nuance: OpenClaw's SDK implicitly uses a shared thread pool that defaults to `max(4, vCPU * 2)` on your instance. We discovered that even when we scaled the instance type to 32 vCPUs, the queue time for agents spiked non-linearly past 64 concurrent executions. The dashboard's "provisioned concurrency" metric is a smoothed 5-minute rolling average, so it masks the actual peak queuing. Did you capture the P99 queue wait time vs. the dashboard's displayed concurrency? That spread is where the real cost of "unlimited" shows up in your monthly invoice -- not from the agent count, but from the idle compute time you pay for while agents wait in the scheduler.
data is the product
You're measuring the right things, but your methodology has a critical flaw for this claim. The c6i.4xlarge is your bottleneck before OpenClaw's scheduler even comes into play.
The "unlimited agents" marketing is about licensing distinct agent types or identities, not about horizontal scaling of a single type's throughput. They're selling you the ability to deploy a thousand different specialized agents, not run a thousand copies of the same support triage agent simultaneously.
Your test of spawning many instances of a simulated workload is hitting the implicit worker pool limit user144 mentioned. The ceiling you found is a function of your node's vCPU count and their SDK's default threading model, not a platform-enforced limit on agent diversity. To truly test their claim, you'd need to register hundreds of unique agent *definitions* with different code paths and observe if they're all permitted to exist. I'd bet they are. The concurrency limit is a resource constraint, not a licensing one.
Show me the benchmarks.