Release performance sweep

This page captures the evidence behind the May 2026 OpenClaw performance, package-size, dependency, and shrinkwrap cleanup. It is the technical companion to the public blog post.

Two audits are combined here:

• Release performance sweep: GitHub Releases from v2026.5.27 back through stable v2026.4.23, using the OpenClaw Performance workflow, profile=smoke, repeat=1, mock-provider lane.
• 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.

Snapshot

Performance coverage: 76 requested releases, 73 artifact-backed points, and 3 unavailable CI runs. Latest stable measured point: v2026.5.27.

- `v2026.4.14`: 9.8s
- `v2026.5.27`: 3.4s

Latest stable package, down from the 43.3MB March package-size peak.

`v2026.5.27` still contains the nested OpenClaw dependency tree. The
next-release state on `main` is 407.4MB.

Latest stable release. Current `main` is down to 314 after the follow-up
dependency cleanup.

Install Footprint Timeline

`2026.2.26` was the monthly dependency-count high in this sample.

`2026.5.22` added root shrinkwrap and exposed a package-shape problem:
911.8MB landed under nested `openclaw/node_modules`.

`2026.5.27` reduced the peak but still installed a 675.9MB nested
OpenClaw tree.

Current `main` keeps shrinkwrap, removes the nested tree, and installs
314 packages.

What Changed After 5.27

The cleanup between v2026.5.27 and current main removed the duplicate default-install graph instead of removing the capabilities themselves.

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 earlier April baseline is v2026.4.14 from the published clawgrit-reports mock-provider run. That run used repeat 3 and failed only because the diagnostic timeline was not emitted; the cold, warm, and RSS medians are still useful as rough scale. Treat this as narrative context, not a release-gate statistic.

Within the single-sample stable May sweep, the line moved more modestly:

Best prerelease point in the single-sample sweep:

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 contains two different stories. Earlier April was slow but recognizable. Late April became a regression cliff. v2026.5.2 is where the mock-provider lane first drops into the 3-5s range and starts passing consistently in the supplied sweep.

Earlier published context:

Supplied single-sample sweep:

Source probes

Source probes were skipped for 17 successful older refs because those source trees did not yet have the required probe entry points. Agent-turn metrics still exist for those refs.

Representative source-probe points:

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

Install footprint audit

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

Shrinkwrap boundary

Published tarball inspection verifies the boundary:

The important distinction: shrinkwrap itself is not the problem. Current main still ships root shrinkwrap. The problem was the package shape that made npm materialize a large nested OpenClaw dependency tree and all 12 @napi-rs/canvas platform packages.

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 only an install-size metric. Every 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

Unavailable performance runs

Follow-up gates

Recommended release checks from this sweep:

1. Run the mock-provider performance smoke for release candidates and retain artifacts.
2. Track cold turn, warm turn, agent RSS, Gateway readyz, and CLI health.
3. Fresh-install the packed tarball with scripts disabled.
4. Record installed dependency count, install size, package size, nested openclaw/node_modules size, and native optional package shape.
5. Fail or hold release review when nested dependency trees or all-platform native packages appear unexpectedly.