Release performance sweep

This page captures the evidence behind the May 2026 OmeniaClaw 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.28 back through stable v2026.4.23, using the OmeniaClaw 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 OmeniaClaw@<version> --dry-run --json for published releases, recording compressed tarball size, unpacked size, and file count.

Snapshot

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

Install Footprint Timeline

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.

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 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 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 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 and the latest 2026.5.28 release.

Shrinkwrap boundary

Published tarball inspection verifies the boundary:

The important distinction: shrinkwrap itself is not the problem. v2026.5.28 still ships root shrinkwrap. The problem was the package shape that made npm materialize a large nested OmeniaClaw dependency tree and all 12 @napi-rs/canvas platform packages. The nested tree is smaller in v2026.5.28, and the canvas platform fanout no longer lands 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 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