Claude Fable 5 обошла нехватку /dev/kvm и протестировала smolvm в GitHub Actions

Ключевые факты

• Саймон Уиллисон поставил ИИ-агенту Claude Fable 5 (в Claude Code for web) задачу: протестировать smolmachines.com/smolvm как быструю защищённую песочницу для чужого Python и JavaScript, с лимитом CPU и RAM, без доступа в сеть и с доступом только к заданным файлам; цель, выполнять на ней пользовательские задачи вроде трансформации данных.
• Контейнер Claude Code for web (Linux 6.18.5-fc-v20, сам являющийся гостевой виртуальной машиной на Firecracker, 4 vCPU, 15 ГБ RAM) не имеет /dev/kvm и флагов виртуализации vmx/svm, вложенная виртуализация в нём невозможна, и команда smolvm machine run ожидаемо упала с ошибкой «kvm not available».
• Агент Fable сам нашёл план Б: раннеры GitHub Actions на Ubuntu дают доступ к /dev/kvm, поэтому Fable установил smolvm и прогнал тесты прямо там, через временную конфигурацию (workflow) в рабочей ветке, с логами и последующим удалением конфигурации в финальном коммите.
• Уиллисон назвал это «творческим решением» ограничений среды Claude Code for web и ещё одним примером того, что Fable неизменно действует на опережение.
• Итоги самого прогона тестов, какие сценарии песочницы прошли и с какой производительностью, а также были ли подтверждены запрет сети и ограничение доступа к файлам из исходной задачи, в материале не приводятся.

Почему это важно

История в компактном виде показывает практическую проблему любого сервиса или ИИ-агента, которому нужно выполнять чужой, непроверенный код: сначала нужна изолированная песочница с лимитами CPU и RAM, без сети и с доступом только к нужным файлам, именно это Уиллисон и поручил проверить на smolmachines/smolvm. Но не менее показателен второй слой сюжета: сама среда, где работает агент, Claude Code for web, оказалась контейнером без доступа к /dev/kvm и без вложенной виртуализации, то есть технически не способным напрямую проверить VM-песочницу изнутри себя. История ценна тем, как именно агент повёл себя дальше: не остановился на ошибке виртуализации, а сам, по собственной инициативе, нашёл среду (GitHub Actions), где нужное железо доступно, и довёл задачу до конца.

Кому это важно

Инженерам, которые строят или выбирают песочницы для выполнения кода, сгенерированного ИИ или загруженного пользователями, агентным системам, сервисам трансформации данных, code-interpreter-функциям. Тем, кто использует Claude Code for web или похожие облачные среды разработки и рискует упереться в то же ограничение, контейнер без вложенной виртуализации. И тем, кто следит за поведением автономных ИИ-агентов при столкновении с техническим препятствием, которое не было предусмотрено в исходной постановке задачи.

Как это применить

Если CI- или dev-среда не даёт /dev/kvm и флаги vmx/svm, частый случай для облачных контейнеров, которые сами являются виртуальными машинами, не пытайтесь форсировать вложенную виртуализацию внутри неё: перенесите VM-зависимый тест туда, где нужное железо доступно. Стандартные Ubuntu-раннеры GitHub Actions такой доступ дают, поэтому набор тестов smolvm можно прогнать через временную конфигурацию (workflow), снять логи и удалить конфигурацию последним коммитом, не оставляя её в репозитории навсегда. Для проверки локальной поддержки виртуализации команда, smolvm machine run; ошибка «kvm not available», верный признак того, что нужен именно такой обходной путь.

Можно ли доверять

Источник, личный блог Саймона Уиллисона, написанный от первого лица: он сам ставил задачу агенту и сам приводит её результат. Цитаты в материале, это рабочие заметки самого Fable, процитированные напрямую, а не пересказанные своими словами автора. При этом всё техническое содержание, характеристики контейнера, ошибка kvm, сам факт прогона на раннере GitHub Actions, это самоотчёт агента: независимой проверки, ссылки на конкретную ветку, workflow или коммит в материале нет, а результаты самого тестового прогона не опубликованы.

Риски и подводные камни

Главный пробел, неизвестен исход самого теста: прошли ли сценарии песочницы, с какой производительностью, и главное, были ли действительно подтверждены исходные требования задачи (запрет сети, доступ только к заданным файлам, лимиты CPU и RAM), а не только то, что smolvm machine run отработал без ошибки виртуализации. Использованная конфигурация GitHub Actions была временной и удалена последним коммитом, поэтому воспроизвести или сверить её настройки по материалу нельзя. Наконец, весь ход эксперимента и диагностика среды, это пересказ действий и заметок ИИ-агента, а не независимо проверенный отчёт о результатах.

«План Б: раннеры GitHub Actions на Ubuntu действительно дают доступ к /dev/kvm, запустить реальный набор тестов через временную конфигурацию (workflow) в этой же ветке, собрать логи и удалить её в финальном коммите.»

— Claude Fable 5, из рабочих заметок (в блоге Саймона Уиллисона)