Прежде чем запускать автономные задачи, нужно понять простую, но неочевидную вещь: кто именно платит за работу. Claude Code допускает несколько независимых маршрутов аутентификации, и один UI может стоять поверх разных биллингов. Подписка Pro или Max считается в лимитах подписки, Team и Enterprise - в seat-квоте, Console - как API-биллинг, а Bedrock, Google и другие провайдеры - в вашем облачном аккаунте. Ответы выглядят одинаково, счёт приходит по-разному.

Первый вход прост: команда claude открывает браузерный логин. Если браузерный callback недоступен - в SSH, WSL2 или контейнере, - Claude Code показывает login-код для вставки в терминал. Управлять входом можно и из shell: claude auth login (в том числе с флагом console), claude auth status и claude auth logout. Важная деталь для скриптов: claude auth status завершается кодом 0, когда вход выполнен, и 1 - когда нет, поэтому bootstrap не нужно разбирать человеческий текст.

Отдельного понимания требует переменная ANTHROPIC_API_KEY, потому что она молча меняет источник оплаты. Если ключ есть в окружении, неинтерактивный claude -p использует именно его. В интерактивном режиме Claude Code один раз просит подтвердить, что ключ заменит subscription-аутентификацию. Если вы рассчитывали на подписку, а в окружении притаился ключ, вы неожиданно уйдёте в API-биллинг - поэтому наличие ключа проверяют до запуска.

Проверять ключ нужно аккуратно, не печатая его значение в журнал. Достаточно убедиться в наличии переменной, а не выводить её содержимое: одна строка с test -n отвечает "ключ задан" или "не задан", не раскрывая секрет. Это мелочь, но именно из таких мелочей складывается гигиена: значение credential не должно попадать в историю shell, логи CI или транскрипт сессии, откуда его потом трудно вычистить.

Полезно один раз собрать команды управления входом и безопасную проверку ключа рядом. Ниже - вход и статус из shell, а также проверка наличия ANTHROPIC_API_KEY без раскрытия значения. К этой карте возвращаются при заведении нового окружения или отладке "почему списывается не туда": сначала выясняют фактический маршрут аутентификации, а уже потом - модель и задачу.

Ключевое предупреждение: один и тот же UI не означает один и тот же счёт. Модель и ответы могут выглядеть идентично, но subscription-логин, Console API key, Bedrock и другие провайдеры считаются и ограничиваются по-разному - разными лимитами, разными политиками, разными консолями биллинга. Перед дорогой автоматизацией стоит свериться с /status, /usage и с billing-консолью конкретного провайдера, а не полагаться на то, что "выглядит как обычно".