May 2026 OpenClaw Performance and Package Size Audit Evidence

This page documents the evidence underlying the May 2026 OpenClaw performance, package size, dependency, and shrinkwrap cleanup. It serves as the technical counterpart to the public blog post.

Two separate audits are combined here:

• Release performance sweep: GitHub Releases from v2026.5.28 back through stable v2026.4.23, using the OpenClaw Performance workflow, profile=smoke, mock-provider lane. Most tag rows contain a single sample; the v2026.5.27 and v2026.5.28 rows use the most recent repeat-3 release-branch artifacts.
• Earlier April context: published clawgrit-reports mock-provider baselines from v2026.4.1 through v2026.5.2, included only to prevent the broken late-April releases from being treated as the public performance baseline.
• Install footprint sweep: fresh npm install --ignore-scripts installs into temporary packages, with du -sk node_modules for size and a node_modules walk for package-instance counts.
• npm package size sweep: npm pack openclaw@<version> --dry-run --json for published releases, recording compressed tarball size, unpacked size, and file count.

Warning

The main performance sweep uses one smoke sample per tag, except the v2026.5.27 and v2026.5.28 rows, which use the most recent repeat-3 release-branch artifacts. Earlier April context uses published repeat-3 medians from clawgrit-reports. Treat the numbers as trend evidence and regression-hunting signal, not as release-gate statistics.

Snapshot

Performance coverage: 77 requested releases, 74 artifact-backed points, and 3 unavailable CI runs. Latest stable measured point: v2026.5.28.

• Stable agent turn, 5.1x faster cold turn - v2026.4.14: 9.8s - v2026.5.28: 1.9s

• Published package, 17.9MB tarball Latest stable package, down from the 43.3MB March package-size peak.

• Latest stable install, 361.7MiB fresh install Cuts the nested OpenClaw dependency tree sharply from the 2026.5.22 shrinkwrap-introduction peak, though a smaller 259.7MiB nested tree still remains in the local install audit.

• Dependency graph, 300 installed packages Measured as unique package name/version roots in a fresh install with scripts disabled; 71 fewer roots than the prior stable release.

What Changed In 5.28

The cleanup between v2026.5.27 and v2026.5.28 reduced the default-install graph instead of removing the capabilities themselves.

• Root default graph, Unique package name/version roots fell from 371 to 300. Package instances fell from 372 to 301.

• Nested tree, Nested openclaw/node_modules fell from 656.1MiB to 259.7MiB in the same local install audit.

• Native optional cones, The all-platform @napi-rs/canvas native package cone stopped landing in the default install.

• Supply-chain surface, Fewer default packages means fewer tarballs, maintainers, native binaries, install-time behaviors, and transitive update paths to trust by default.

Tip

Shrinkwrap was not the problem by itself. The bad package shape was. v2026.5.28 still ships shrinkwrap, but the nested dependency tree is much smaller and the all-platform canvas fanout is gone in the local audit.

Headline Numbers

Do not use the late-April broken rows as public performance baselines. v2026.4.23 and v2026.4.29 are useful regression evidence, but the large 14x-style deltas mostly describe the recovery from a bad release line.

For the blog narrative, use the earlier April published baseline as scale. The baseline is v2026.4.14 from the published clawgrit-reports mock-provider run (repeat 3; that run failed only because the diagnostic timeline was not emitted, so the cold, warm, and RSS medians are still useful as rough scale). Treat this as narrative context, not a release-gate statistic.

Within the May sweep, the latest release-branch row moved materially from v2026.5.2:

Compared with the previous stable release:

Install footprint

npm package size

2026.5.12 is the visible plugin-extraction milestone in the changelog: Amazon Bedrock, Bedrock Mantle, Slack, OpenShell sandbox, Anthropic Vertex, Matrix, and WhatsApp moved out of the core dependency path so their dependency cones install with those plugins instead of every core install.

Kova agent turn summary

The April stable line tells two distinct stories. Early April was slow but recognizable. Late April turned into a sharp regression drop. v2026.5.2 marks the point where the mock-provider lane first falls into the 3-5s range and begins passing reliably in the provided sweep.

Previously published context:

Supplied sweep:

Source probes

Source probes were not run for 17 successful older references because those source trees lacked the required probe entry points at the time. Agent-turn metrics are still available for those references.

Representative source-probe points:

The v2026.5.22 CLI health spike is visible in this table even though the agent-turn lane still passed. When investigating targeted CLI or gateway regressions, keep the source probes.

Install footprint audit

Dependency samples use one stable release per month, plus the 2026.5.22 shrinkwrap-introduction event and the latest 2026.5.28 release.

Shrinkwrap boundary

2026.5.20 was released without a root shrinkwrap and without a large nested OpenClaw dependency tree. Root shrinkwrap was introduced in 2026.5.22, which installed 911.8MB under nested openclaw/node_modules. 2026.5.28 continues to use shrinkwrap and installs 259.7MiB under nested openclaw/node_modules, though no @napi-rs/canvas packages are installed in the local fresh-install audit anymore.

The published tarball inspection confirms the boundary:

A key distinction: shrinkwrap itself is not the issue. Root shrinkwrap is still shipped with v2026.5.28. The real problem was the package shape that caused npm to materialize a large nested OpenClaw dependency tree and all 12 @napi-rs/canvas platform packages. In v2026.5.28, the nested tree is smaller, and the canvas platform fanout no longer appears in the local audit.

For a plain-English explanation of shrinkwrap and the maintainer-level package checks, see npm shrinkwrap.

Supply-chain interpretation

Dependency count is an operational security metric, not just an install-size metric. Each package expands the set of maintainers, tarballs, transitive updates, optional native binaries, and install-time behaviors that operators must trust.

The cleanup direction is:

• keep heavy and optional capabilities outside the default core install
• make plugin packages own their runtime dependency graph
• avoid runtime package-manager repair during Gateway startup
• preserve deterministic installs without causing all-platform native package materialization
• keep install scripts disabled in package acceptance and measurement paths
• catch nested dependency trees and native optional dependency explosions before publishing

Related docs:

• Plugin dependency resolution
• Plugin inventory
• Full release validation