Anthropic CLI (ant)

ant — официальный CLI Anthropic, который открывает каждый ресурс Claude API как shell-подкоманду: ant models list, ant messages create. Бета-ресурсы живут под префиксом beta: (ant beta:agents create), и CLI сам выставляет нужные бета-заголовки — вручную их передавать не нужно. Это делает ant естественным инструментом для отладки, скриптов и управления ресурсами Managed Agents из терминала и CI.

По сравнению с ручными curl-запросами разница ощутимая: тело запроса собирается из типизированных флагов или готового YAML-документа вместо рукописного JSON, ответы можно сразу фильтровать и упрощать без внешних утилит, а списки любой длины выгружаются целиком без ручной возни со страницами. Для команды из одного человека это означает, что вся административная работа с API — посмотреть, создать, обновить, заархивировать — делается парой коротких команд прямо из терминала, а повторяемые операции легко превращаются в шелл-скрипты и шаги пайплайна.

Как это работает

Установка: brew install anthropics/tap/ant на macOS, release-тарболы для Linux или сборка через go install. Аутентификация — двумя способами: переменной окружения ANTHROPIC_API_KEY или OAuth-профилями через ant auth login — тогда используются короткоживущие токены, а профили хранятся в ~/.config/anthropic/. Дальше начинаются возможности, ради которых CLI и существует: тела запросов можно передавать YAML-документом из stdin; синтаксис @file подставляет содержимое файла в любое строковое поле; флаг --transform извлекает поля из ответа GJSON-путями, избавляя от пайпов через jq; флаг -r печатает сырой вывод без кавычек для скриптов; list-эндпоинты пагинируются автоматически, отдавая полный результат.

Когда применять

Рабочее правило: «CLI — для control plane, SDK — для data plane». Агенты и окружения Managed Agents — относительно статичные ресурсы. Описывайте их версионируемым YAML в репозитории и применяйте через ant из CI, как манифесты инфраструктуры. Сессии же динамичны — их создаёт и ведёт код приложения через SDK: стриминг событий, реакция на вызовы инструментов, интеграция в продукт. Оба пути бьют в один и тот же API; разница лишь в том, где живёт вызов. Плюс ant незаменим для разовой отладки: посмотреть список агентов, вытащить поле из ответа через --transform, проверить, что видит ваш ключ. Такой подход даёт привычные преимущества инфраструктуры как кода: изменения конфигурации агентов проходят ревью в пул-реквестах, история правок остаётся в git, а откат к рабочей версии — это обычный revert, а не археология в веб-консоли. Когда определение агента лежит рядом с кодом приложения, расхождение между «что задумано» и «что реально развёрнуто» перестаёт накапливаться.

Отдельно стоит сказать про профили: если вы работаете с несколькими рабочими пространствами или организациями, каждому стоит завести именованный профиль и переключаться между ними явно. Токен интерактивного входа привязан к одному пространству, и ресурсы чужого пространства через него просто не видны — типичная причина «пропавших» агентов и сессий, которые на самом деле лежат в соседнем воркспейсе.

Типичные ошибки

Ловушка номер один в аутентификации: устаревший экспортированный ANTHROPIC_API_KEY молча перекрывает OAuth-профили. Вы логинитесь через ant auth login, а запросы продолжают идти со старым ключом — и непонятно почему. Команда ant auth status показывает, какой именно креденшел победил; проверяйте её первой при любых странностях с доступом. Вторая ошибка — забывать про префикс beta: для бета-ресурсов: агенты, сессии и окружения Managed Agents доступны как ant beta:agents, ant beta:sessions и так далее. Третья — городить jq-пайплайны там, где хватает встроенного --transform с GJSON-путём и флага -r. И не дублируйте вручную пагинацию: list-команды сами доберут все страницы.

Как это работает

Когда применять

Типичные ошибки

Связанные понятия

Полезные ресурсы