NullClaw под лупой: зачем AI-агенту Zig, маленький бинарь и быстрый запуск

Когда смотришь на современные AI-агенты, быстро замечаешь одну общую черту: почти все они живут на тяжелом стеке. Где-то это Node.js, где-то Python, где-то длинная цепочка зависимостей, сервисов и фоновых процессов. На этом фоне nullClaw выглядит почти инородно: один бинарный файл, Zig, быстрый запуск, мало занимаемой памяти и минимум лишнего.

Для этой статьи я смотрел nullClaw в состоянии v2026.3.13-1-g78366e9. Для сравнения я отдельно прогнал те же сценарии на свежем npm-релизе OpenClaw 2026.3.12.

Сразу оговорюсь: это не сравнение полноты платформ. nullClaw я смотрю как маленький single-binary runtime на Zig, а OpenClaw — как более широкий self-hosted gateway/agent stack с Node-зависимостью, daemon/gateway-режимами и Control UI. Поэтому ниже я сравниваю не кто «лучше вообще», а цену локального запуска в одинаковых коротких сценариях: служебные команды, один agent-run, маленькая coding-задача и пачка параллельных небольших coding-задач.

Коротко по цифрам

На моем стенде Mac mini M4, 16 GB RAM, 256 GB SSD получилось так:

Это не значит, что nullClaw «лучше вообще во всём». Но как локальный runtime по цене запуска и по памяти он действительно выглядит очень легким.

Что такое nullClaw

Если коротко, nullClaw — это AI agent runtime, написанный на Zig. Здесь важно слово runtime. Это не просто «обёртка над API модели», а движок, который умеет работать с моделями, каналами связи, инструментами, памятью и агентной логикой.

Интерес в проекте не только в том, что он написан на Zig. Интерес в том, что он делает ставку на другой инженерный компромисс:

• маленький бинарь;

• мало потребляемой памяти;

• быстрый запуск;

• как можно меньше лишнего рантайма вокруг.

Это заметно уже на уровне установки. В простом случае у тебя есть готовый бинарь из GitHub Releases или установка через Homebrew:

brew install nullclaw

nullclaw --help

Для self-hosted и edge-сценариев это важно не меньше, чем архитектура. Когда у тебя один бинарь без обязательного тяжелого внешнего рантайма, попробовать проект и перенести его на другую машину становится намного проще.

Почему Zig здесь вообще имеет смысл

Zig здесь важен не как «модный язык», а как удобный способ держать runtime прямолинейным:

• один бинарь;

• явное управление памятью;

• отсутствие тяжелого managed runtime;

• понятный контроль над тем, что попадает в сборку.

Отдельно важен build.zig. В нем действительно видны compile-time переключатели как минимум для каналов и memory engine’ов. Уже этого достаточно, чтобы обсуждать не только размер бинаря, но и более узкую функциональную поверхность сборки.

И это уже не только про скорость и память, но и про безопасность. Чем меньше реально включенных подсистем, тем меньше лишней поверхности для ошибок, неожиданных сценариев и уязвимостей.

Где это особенно наглядно: ClawWatch

Хороший supporting example — проект ClawWatch. Это AI-агент для smartwatch, который использует NullClaw как статический ARM-бинарь вместе с офлайн-распознаванием речи на Vosk и встроенным TTS на устройстве.

В README ClawWatch прямо сказано:

• внутри bundled NullClaw v2026.3.7;

• используется офлайн STT через Vosk;

• есть доступ к pulse, vitals, movement, acceleration, pressure, light и altitude;

• часть запросов вообще может обрабатываться без ухода в модель.

ClawWatch интересен не как полностью замкнутый on-device LLM-стек, а как демонстрация того, зачем вообще нужен компактный агентный runtime на устройстве с жестким бюджетом памяти. На часах разница между «несколько мегабайт» и «сотни мегабайт» — это уже не приятная оптимизация, а вопрос «встраивается ли это вообще».

Что и как я измерял

Чтобы не опираться только на README, я собрал nullClaw локально:

zig build -Doptimize=ReleaseSmall

Стенд был такой:

• Mac mini M4

• 16 GB RAM

• 256 GB SSD

• macOS arm64

Для LLM-path я использовал одну и ту же модель через OpenRouter у обоих проектов:

• nullClaw: anthropic/claude-sonnet-4.6

• OpenClaw: openrouter/anthropic/claude-sonnet-4-6

Отдельно важно, как я считал метрики:

• для служебных команд я разделял свежие независимые запуски и повторные warm-запуски;

• под «свежим» запуском я имею в виду новый процесс, а не жесткий flush системных кэшей macOS;

• основной показатель памяти — maximum resident set size;

• для macOS я иногда смотрел и peak memory footprint, но это дополнительная метрика;

• для параллельного теста я считал пик суммы RSS одновременно живых процессов, а не сумму индивидуальных максимумов уже завершившихся прогонов.

Для коротких команд я сделал серию из 5 свежих и 10 warm-запусков. Для LLM-run и маленьких coding-задач — серию из 5 запусков. Для параллельных coding-задач — 3 полных прогона по 10 агентов.

Важная оговорка про размер бинаря

README nullClaw заявляет 678 KB для ReleaseSmall. Но опубликованные release-asset’ы v2026.3.13 заметно больше. Например:

• nullclaw-macos-aarch64.bin — 3,941,016 байт;

• nullclaw-linux-aarch64.bin — 3,118,432 байта.

Моя локальная сборка на macOS arm64 дала около 2.6 MB.

То есть размер бинаря действительно маленький, но ниже я смотрю прежде всего на профиль запуска и памяти, а не на одно “магическое” число из README.

Служебные команды

Для --help я делал серию прогонов и считал median/p95.

nullClaw --help

• свежие запуски: median 0.002 s, p95 0.005 s

• warm-запуски: median 0.0018 s, p95 0.0019 s

• RSS: median ~1.9 MB

OpenClaw --help

• свежие запуски: median 0.621 s, p95 1.389 s

• warm-запуски: median 0.619 s, p95 0.630 s

• RSS: median ~308 MB, p95 ~315 MB

Уже на этом шаге хорошо видно, что nullClaw живет в другом классе накладных расходов.

Один короткий agent-run

Для простого smoke-теста я использовал одинаковую идею у обеих систем:

Reply with exactly: smoke ok

Результат по серии из 5 запусков:

nullClaw

• wall time: median 2.55 s, p95 4.03 s

• RSS: median ~7.7 MB

OpenClaw

• wall time: median 3.37 s, p95 4.33 s

• RSS: median ~567 MB, p95 ~590 MB

Здесь уже полезно отделять два разных эффекта.

По времени разница есть, но она не драматическая: оба проекта упираются в сетевой round-trip до модели. А вот по памяти разрыв огромный.

Один маленький coding-run

Дальше я попросил агента сделать совсем простую вещь: создать slugify.py и README.md в рабочей папке.

Формулировка была одинаковая по смыслу:

Create a Python file named slugify.py in the workspace. It must define a function slugify(text: str) -> str that lowercases text, converts spaces and underscores to hyphens, removes non-alphanumeric characters except hyphens, collapses repeated hyphens, and trims leading/trailing hyphens. Also create a small README.md with a one-line usage example. Reply with exactly: coding-single-ok

Файлы у обеих систем реально появились на диске. По серии из 5 запусков получилось так:

nullClaw

• wall time: median 4.86 s, p95 38.01 s

• RSS: median ~7.7 MB, p95 ~7.8 MB

OpenClaw

• wall time: median 6.64 s, p95 7.26 s

• RSS: median ~572 MB, p95 ~590 MB

Здесь есть важная оговорка: у nullClaw p95 по времени получился шумным из-за одного сильно более медленного прогона. Это еще один пример того, почему сетевой LLM-path нельзя смешивать с чистым runtime overhead.

Но даже с этой оговоркой картина по памяти не меняется.

10 параллельных coding-задач

Самый интересный сценарий был таким:

• 10 независимых агентов;

• 10 отдельных workspace;

• 10 параллельных процессов;

• 10 маленьких Python-задач: clamp.py, chunk_list.py, is_palindrome.py, rgb_to_hex.py, normalize_ws.py, parse_bool.py, unique_items.py, snake_to_camel.py, word_count.py, format_duration.py;

• в каждом workspace дополнительно создавался README.md.

Я прогнал этот сценарий по 3 раза для каждой системы.

nullClaw

• wall time: median 9.30 s, p95 10.61 s

• пик суммарной RSS: median 54,928 KB, p95 55,984 KB

То есть примерно:

• median ~54 MB

• p95 ~55 MB

OpenClaw

• wall time: median 13.14 s, p95 13.27 s

• пик суммарной RSS: median 535,296 KB, p95 535,504 KB

То есть примерно:

• median ~523 MB

• p95 ~523 MB

Во всех проверочных прогонах нужные файлы в workspace действительно создавались.

Что дает сравнение на практике

Если свести только параллельный coding-сценарий к одной строке, получается так:

• nullClaw: ~54 MB суммарной RSS и 9.30 s

• OpenClaw: ~523 MB суммарной RSS и 13.14 s

Иными словами, в этом локальном тесте OpenClaw получился примерно:

• в 9.7x тяжелее по суммарной памяти;

• примерно в 1.4x медленнее по wall time.

Это не означает, что OpenClaw «хуже вообще во всём». У него другой инженерный профиль и более широкая платформа вокруг runtime. Но если смотреть именно на цену локального запуска в одинаковых коротких сценариях, nullClaw действительно выигрывает очень заметно.

Что из этого следует

На мой взгляд, главное в nullClaw не в том, что он «ещё один AI-агент», и даже не в том, что он написан на Zig.

Главное в том, что он возвращает разговор к очень базовому инженерному вопросу: сколько вообще должен стоить агент как процесс?

Судя по архитектуре, по published release-артефактам и по локальным замерам, nullClaw отвечает на этот вопрос довольно радикально. Агентный runtime может быть не платформой на полсервера, а маленькой, быстрой и достаточно предсказуемой программой.

И даже если не использовать именно его, сама идея полезная. В мире AI слишком легко думать только о моделях. nullClaw заставляет снова думать о цене рантайма: сколько памяти он занимает, как быстро стартует, сколько зависимостей тащит и сколько реально стоит запуск не одного, а сразу нескольких агентов.

И, возможно, это одна из самых недооценённых тем во всей агентной инфраструктуре.