У разработчиков, которые уже присматривались к автоматизации через новые Foundation Models, появился неприятный нюанс: облачные модели Apple в macOS 27 нельзя запускать из скриптов через утилиту fm. Иными словами, в терминале всё выглядит почти как обещанная AI-автоматизация, а в cron, launchd, CI или Python-процессе магия заканчивается ошибкой. Для тех, кто строит внутренние инструменты, прототипы ассистентов и пайплайны генерации текста на Mac, это уже не мелкая шероховатость, а вполне прикладное ограничение.
О находке разработчика Пита Голдсмита сообщает Habr / Новости. По его наблюдениям, команда fm respond --model pcc отрабатывает нормально, если запускать её из обычной интерактивной сессии терминала, но ломается в сценариях автоматизации. Вместо ответа от модели система возвращает прямолинейное сообщение: PCC inference is not available in this context. Если убрать облачную модель и перейти на локальную, сценарий работает штатно. Практический вывод простой: из скриптов в macOS 27 сейчас доступны только локальные нейросети, которые выполняются прямо на устройстве.
Проблема выглядит тем более заметной на фоне июньского анонса Apple. В июне 2026 года компания представила CLI-утилиту fm и Python SDK для работы с моделями машинного обучения из набора Foundation Models. Идея выглядела весьма здраво: разработчик может отправлять промпты из терминала, подключать генерацию текста к служебным скриптам и тестировать инференс без отдельной обвязки вокруг приложений. Причём Apple показывала не только компактные локальные модели, но и более мощные варианты, работающие в облаке Private Cloud Compute. На бумаге это выглядело как аккуратный мост между экосистемным AI и привычной разработческой автоматизацией.
Но реальность, как это часто бывает, оказалась с пометкой мелким шрифтом. Голдсмит выяснил, что внутри бинарника fm есть проверка ParentProcessGate. Перед отправкой запроса в Private Cloud Compute утилита смотрит на контекст запуска и требует, чтобы процесс работал именно в терминальной сессии. Более того, родительский процесс, связанный с терминалом, должен быть подписан Apple. Ключевой момент здесь в том, что ограничение находится именно в бинарнике fm, а не в самих Foundation Models или связанных системных компонентах. То есть речь не о фундаментальном техническом барьере платформы, а о довольно конкретном ограничителе на уровне инструмента.
Почему Apple могла так сделать
Самое правдоподобное объяснение связано не с архитектурой моделей, а с контролем доступа и пользовательской квотой. У fm нет отдельной авторизации для разработчика, нет API-ключа и вообще нет привычного механизма, который можно было бы явно привязать к конкретному приложению, сервису или учётке команды. Если бы облачный режим можно было бесшумно вызывать из любого фонового процесса, сторонняя программа или агент могли бы без ведома пользователя расходовать лимиты Private Cloud Compute. С точки зрения Apple это выглядит как очевидная дыра в модели контроля: счёт идёт не на деньги разработчика и не на ключ проекта, а, по сути, на доверие к пользовательской сессии.
Логика понятна, но для инженерной практики она неудобна. Разработчик ожидает, что CLI-инструмент либо пригоден для автоматизации, либо честно позиционируется как интерактивная утилита. Когда команда работает в терминале, но отказывается работать в cron или CI, это ломает ожидания сильнее, чем прямой запрет в документации. Особенно если речь идёт о сценариях, ради которых CLI вообще обычно и ставят: пакетная обработка текста, локальные агенты, тестирование промптов, вспомогательные инструменты для редакторов и IDE, интеграция с внутренними сервисами.
При этом ограничение касается только Private Cloud Compute. Локальная модель system продолжает работать стабильно, но компромисс здесь довольно очевиден: она компактнее и умеет держать меньше контекста. Для простых задач вроде коротких саммари, классификации, черновых преобразований текста или внутренних подсказок этого может хватить. Но как только команда пытается использовать более длинные входы, сложные цепочки инструкций или просто рассчитывает на более сильное качество ответа, становится ясно, почему разработчики вообще смотрели в сторону облачного режима. Получается знакомая для Apple история: базовый сценарий есть, красивый демо-путь тоже есть, а вот путь к полноценной продовой автоматизации проходит через рамки, о которые можно неприятно споткнуться.
Что это значит для разработчиков и команд
Для русскоязычной IT-аудитории здесь несколько практических выводов. Во-первых, новые инструменты Apple для Foundation Models пока нельзя воспринимать как полноценную замену API-подходу в стиле облачных AI-сервисов. Если ваш процесс строится вокруг фоновых задач, ночных джобов, CI-проверок или служебных Python-скриптов, облачные модели Apple через fm в текущем виде не закрывают этот сценарий. Во-вторых, ставка на экосистемные AI-функции Apple по-прежнему сильнее работает в продуктовых и пользовательских сценариях, чем в свободной серверной автоматизации, к которой привыкли разработчики. И, наконец, командам, которые уже планировали быстро собрать на macOS 27 внутренние AI-утилиты с опорой на Private Cloud Compute, стоит заранее проверить, не упрётся ли их архитектура в простой факт: интерактивный запуск доступен, а фоновый нет.
Это не делает fm бесполезной утилитой. Для локального тестирования, экспериментов с промптами, проверки поведения моделей и ручной работы в терминале она всё ещё выглядит полезным инструментом. Но для более серьёзной автоматизации Apple пока предлагает довольно жёсткую развилку: либо использовать локальные модели со всеми ограничениями по размеру и контексту, либо оставаться в терминале и не притворяться, что это уже готовый механизм для фоновых пайплайнов. Если компания не предложит отдельную модель авторизации или контролируемый доступ к Private Cloud Compute для скриптов, разработчикам придётся либо жить в рамках локального инференса, либо искать обходные пути вне экосистемного комфорта Apple. И вот это уже хороший маркер того, как далеко Apple готова пускать сторонних разработчиков к своим AI-возможностям: до терминала можно, до автономной автоматизации пока нет.