Подписка Claude Code vs API: как выбрать доступ и оплату

Pro или Max стоит тестировать для интерактивной работы одного человека, который уже пользуется Claude и хочет Claude Code в пределах лимитов плана. Team или Enterprise лучше подходят организациям, которым нужны seats, централизованный биллинг, управление участниками и управляемые политики. Anthropic Console, Bedrock, Google Cloud или Microsoft Foundry уместны, когда использование должно оплачиваться по токенам через организационную или облачную identity и попадать в собственный контур контроля затрат.

Это не сравнение качества модели: один и тот же coding workflow может менять плательщика, credential, доступные функции и место учета расходов. Лимит подписки не является API-кредитом, а API key в shell может иметь приоритет над входом по подписке. До пилота зафиксируйте в `/status` активный credential, плательщика, организацию, модель, источник policy и владельца бюджета; иначе команда может тестировать один контур, а платить за другой.

• Один человек, интерактивные сессии и предсказуемые расходы по подписке → начните с Pro или Max.
• Команда, web + Code, seats и admin controls → оценивайте Team или Enterprise.
• CI, service workflows, cloud IAM или детальный учет токенов → оценивайте Console или cloud provider.
• Смешанный режим → определите приоритет credentials и отдельные бюджеты до запуска.

Claude Code поддерживает несколько путей credentials. Текущая документация описывает credentials облачных провайдеров, bearer token, `ANTHROPIC_API_KEY`, helper, OAuth token, Anthropic profile и вход по подписке с разным приоритетом. Наличие активной подписки не гарантирует, что конкретная terminal session использует именно ее: environment API key может перехватывать запросы. Храните receipt без секретов с методом входа, меткой организации, источником credential, провайдером, моделью и timestamp.

Проведите negative test на disposable account: войдите способом подписки, проверьте `/status`, затем добавьте synthetic или строго ограниченный test credential в контролируемой среде и убедитесь, что оператор видит смену плательщика до первого существенного запуска. Не копируйте ключи в tickets или logs. Для production-доступа используйте vault, short-lived identity или provider IAM, где это поддерживается, и отдельно тестируйте revoke.

Для Pro, Max, Team и Enterprise использование связано с лимитами плана и может делиться с другими поверхностями Claude. Для Console или cloud provider запросы оплачиваются по потреблению токенов в соответствующей organization или cloud billing account. Локальная оценка стоимости сессии полезна для диагностики API usage, но Anthropic прямо указывает сверять авторитетный биллинг в Console; для пользователя подписки та же цифра не является счетом за сессию.

Сравнивайте стоимость принятой задачи, а не prompts или tokens по отдельности. Фиксируйте завершенные задачи, минуты review, retries, поведение cache, большие context loads, параллельные сессии и прерывания по лимитам. Подписка может быть лучше для стабильного human-in-the-loop потока, API — для контролируемой переменной интенсивности или chargeback. Ни один вариант не выигрывает без одинакового набора задач и полной стоимости проверки.

• Subscription receipt → tier, состояние лимита, окно reset, настройка usage credits и принятый артефакт.
• API receipt → provider, workspace, token usage, авторитетный источник счета и состояние бюджета.
• Shared context → учитывайте повторное чтение repository и cache misses.
• Неизвестный результат → проверьте git state и side effects перед retry.

Интерактивная developer session и unattended CI job несут разные риски. В локальной сессии по подписке человек может подтвердить действие, увидеть лимит и исправить контекст. Для headless-запуска нужны machine-appropriate authentication, максимальное время выполнения, контроль concurrency, network policy, узкий scope репозитория, детерминированные checks и kill switch. Не переносите персональный login на общий runner только потому, что он уже оплачен.

До автоматизации определите класс задачи: read-only review, предложение patch, repair тестов или внешнее действие. Каждый класс получает отдельные permissions, budget и approval. API или cloud billing упрощает metering, но не доказывает безопасную authority; подписка не запрещает полезную automation, но eligibility и terms нужно проверять для конкретного механизма. Merge, deploy и destructive operations оставляйте за независимым gate.

Team и Enterprise объединяют Claude web и Claude Code с membership организации и централизованным биллингом; Enterprise добавляет более сильные identity, compliance и managed-policy возможности. Console дает API-ориентированную organization, workspace spend limits и роли для Claude Code или более широкой разработки. Cloud providers добавляют собственные IAM, регионы, procurement и cost consoles. Это разные operating models, а не просто разные способы провести карту.

Постройте RACI: кто приглашает или удаляет developer, кто разрешает модели, кто задает managed settings, кто видит per-user usage, кто утверждает usage credits или повышение бюджета и кто расследует credential drift. Проверьте joiner, mover и leaver на synthetic user. SSO login, удаление seat, revoke API key, cached credential и доступ к repository должны быть отдельными доказательствами.

Выберите 12–20 representative задач: bug fix, multi-file change, генерация тестов, объяснение repository, исследование dependency и отказ при недостатке evidence. Первую неделю выполняйте их в candidate subscription contour, вторую — через Console или выбранного cloud provider с тем же model class, instructions, snapshot репозитория, permissions и reviewer rubric. Перед каждой сессией фиксируйте active credential; после нее сохраняйте diff, checks, accepted outcome, interruption и billing source.

Добавьте crossover trap: на машине намеренно остается неактивная test API variable, а оператор должен обнаружить ее до run. Добавьте limit event, истечение credential, budget ceiling и revoked developer. Pilot проходит только если атрибуция плательщика воспроизводима, critical task завершается или fail-closed, а финансовый owner может сверить local usage с авторитетным dashboard. Не используйте средние показатели vendor как прогноз для своей команды.

• Freeze → commit, task set, policy, model class и acceptance criteria.
• Observe → credential, плательщик, tokens/allowance, tool calls и completion state.
• Review → correctness, regressions, human correction и качество evidence.
• Reconcile → локальная оценка против plan или billing dashboard.
• Decide → самый простой контур, проходящий quality, authority и budget gates.

Миграция между subscription, Console и cloud provider меняет credential, владельца биллинга, analytics и иногда доступные product surfaces. Создайте manifest для settings, CLAUDE.md, MCP servers, hooks, plugins, выбора модели, environment variables и источников policy. Не экспортируйте секреты: восстановите их из целевого vault или IAM. После switch проверьте `/status`, allowed tools, границу repository, назначение telemetry и одну canary задачу.

Rollback возвращает предыдущий approved auth path, отключает новый credential, останавливает unattended jobs и сверяет outstanding usage. В смешанной модели явно маркируйте workload routing: например, local interactive work через organization seat, CI через cloud identity. Запретите silent fallback между плательщиками. Review нужен после изменения plan, credential precedence, model availability, pricing, managed policy или billing integration.