May 2026 Performance and Package Size Audit Evidence

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

Two 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 are one sample; the v2026.5.27 and v2026.5.28 rows use the latest repeat-3 release-branch artifacts.
• Earlier April context: published clawgrit-reports mock-provider baselines from v2026.4.1 through v2026.5.2, used only to avoid treating the broken late-April releases 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 latest 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 sluggish but familiar. Late April turned into a regression cliff. v2026.5.2 marks the point where the mock-provider lane first enters the 3-5s range and begins to pass reliably in the provided sweep.

Previously published context:

Supplied sweep:

Source probes

Seventeen older refs that passed were skipped for source probes, since those source trees lacked the necessary probe entry points. Agent-turn metrics remain available for those refs.

Representative source-probe points:

The v2026.5.22 CLI health spike shows up in this table, even though the agent-turn lane continued to pass. Keep the source probes in mind when chasing targeted CLI or gateway regressions.

Install footprint audit

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

Shrinkwrap boundary

2026.5.20 was released without a root shrinkwrap and without any substantial nested OpenClaw dependency tree. Root shrinkwrap made its debut in 2026.5.22, which brought 911.8MB of dependencies under the nested openclaw/node_modules structure. 2026.5.28 continues to use shrinkwrap, now installing 259.7MiB under nested openclaw/node_modules, yet the local fresh-install audit no longer includes any @napi-rs/canvas packages.

The published tarball check confirms the boundary:

The key point: shrinkwrap is not the culprit. v2026.5.28 still carries root shrinkwrap. The real issue was the package layout that forced npm to build a large nested OpenClaw dependency tree and all 12 @napi-rs/canvas platform packages. By v2026.5.28, the nested tree has shrunk, and the canvas platform fanout no longer appears in the local audit.

For the current dependency review and package policy, see dependency locking.

Supply-chain interpretation

Dependency count matters as an operational security measure, not just for install size. Each package widens the circle of maintainers, tarballs, transitive updates, optional native binaries, and install-time behaviors that operators have to rely on.

The cleanup approach:

• 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