We've been conducting a long-term performance evaluation of Claw's autonomous agent framework within our production-like staging environment, and we've identified a significant, systematic issue with uncontrolled resident memory growth (RSS) in agents operating for more than 72 hours. This behavior directly contradicts the stability claims in their documentation regarding garbage collection and memory isolation.
Our testbed consists of a Kubernetes cluster (v1.28) with node autoscaling disabled to ensure consistent resource baselines. We deployed ten agent instances, each configured with a standard workflow for document processing and API orchestration as per Claw's "High-Performance Guide." Monitoring was implemented via a dedicated APM stack (Prometheus, Grafana) with granular container-level metrics, supplemented by `pprof` sampling.
The observed behavior follows a predictable pattern:
* **Baseline:** Agents initialize at ~450MB RSS.
* **Phase 1 (0-24h):** Steady-state operation with minor fluctuations (~±50MB) correlated with batch sizes.
* **Phase 2 (24-72h):** Gradual, monotonic increase in RSS, averaging 10-15MB per hour, unrelated to load.
* **Phase 3 (72h+):** RSS plateaus between 2.1GB and 2.4GB per agent, at which point Kubernetes `OOMKilled` events begin due to our configured memory limits, despite no functional errors in the agent logs.
We engaged Claw support (Ticket #CS-8812) and their initial response was that this was "expected caching behavior" and that we should "increase memory limits to accommodate working sets." This is a non-answer for a long-running service. Upon providing our `pprof` heap profiles, their engineering team acknowledged an "internal reference leak in the WebSocket connection pool for third-party integrations," stating it would be patched in Q3.
The workaround they proposed—implementing a cron-based pod restart every 48 hours—is architecturally unsound for stateful agents and introduces unnecessary operational complexity and scheduling jitter. Our own mitigation, forcing a full garbage collection via debug endpoint every 12 hours, only temporarily reduces RSS, which immediately resumes its climb.
```go
// Excerpt from our pprof heap output showing the culprit
// flat flat% sum% cum cum%
// 1.21GB 52.43% 52.43% 1.21GB 52.43% claw/internal/comms.(*Pool).maintainConnection
// 0.65GB 28.15% 80.58% 0.65GB 28.15% claw/vendor/gorilla/websocket.(*Conn).writeBuffer
```
**Benchmark Comparison:** We ran identical workloads on a competing framework (Kestrel v4.2) for a 168-hour control test. Kestrel's agents exhibited a sawtooth memory pattern with effective garbage collection, maintaining RSS between 400MB and 550MB for the entire duration, with no upward trend.
Given the severity of this leak, the vendor's delayed diagnosis, and the proposed "solution" being a scheduled restart, we cannot recommend Claw for any production workload requiring stability beyond a few days. This forces a fundamental re-architecture of deployment patterns to accommodate a platform deficiency. We are currently evaluating alternatives and will not be renewing our enterprise license unless a genuine fix is proven in our environment.
Has anyone else performed longitudinal load testing on Claw and observed similar trajectories? I am particularly interested in whether the memory growth is linear or step-function in different deployment models (e.g., bare metal vs. containerized).
— Isabella G.
Measure everything, trust only data