Как разделить ключи и лимиты AI API между проектами

Лимит бесполезен, если команда не понимает, к какой работе он относится. Проект удобно выделять по продукту, клиенту, среде или владельцу бюджета. Если два сценария имеют разные правила остановки, сроки жизни или ответственных, им обычно нужны разные границы. В TokenTool проект служит логической группировкой интеграций, ключей и учёта. Он не доказывает физическую изоляцию данных и не добавляет ролевую модель в клиентское приложение.

До выпуска ключа составляют короткий паспорт: назначение, допустимые модели, среда, плановая нагрузка, месячная сумма, владелец и дата пересмотра. В паспорт не включают значение секрета. Сам ключ сохраняют в защищённой конфигурации и никогда не встраивают в публичный frontend. Отдельные credentials для production и test помогают расследовать расход и отключать временную среду, не затрагивая основной сценарий.

Warning threshold должен оставлять время на проверку, а не совпадать с жёсткой границей. Для стабильной нагрузки исходной точкой могут быть 70–80 процентов месячного лимита. Для пакетной обработки с редкими крупными заданиями запас выбирают по максимальному ожидаемому запросу и числу параллельных операций. Процент нельзя копировать вслепую: его проверяют на фактическом профиле нагрузки и меняют после первой полной сверки.

На предупреждении владелец сравнивает текущий расход с планом, проверяет число успешных операций, ошибки и повторы. Если рост связан с полезной нагрузкой, команда согласует дополнительный бюджет. Если причина — цикл retry или неверный расписатель, сначала устраняет дефект. Автоматическое увеличение лимита без расследования делает порог декоративным и переносит проблему на конец расчётного периода.

Лимит задаёт денежную границу для ключа или проекта и помогает остановить новые обращения после достижения порога. Однако запрос, который уже принят и выполняется, может завершиться позднее и добавить списание. Поэтому конструктор отдельно показывает residual risk — оценку максимального единичного запроса. Для критичной нагрузки этот риск дополняют ограничением параллелизма, таймаутом и собственным circuit breaker в приложении.

Нельзя обещать, что расход остановится ровно на заданной сумме при любой модели и типе операции. Особенно осторожно следует относиться к generic non-chat возможностям, для которых единое поведение лимитов не подтверждено. Политика на этой странице ориентирована на финансовое планирование и проверяемые текстовые сценарии. Всё остальное проходит отдельный контролируемый тест до включения клиентской нагрузки.

Политика должна отвечать на пять вопросов: кто увидит сигнал, за какое время проверит, какие данные сравнит, что может остановить и кто разрешит продолжение. На warning уровне обычно достаточно ограничить необязательные задания и проверить повторы. На hard уровне приложение переводят в заранее описанный режим: очередь, ручное подтверждение, упрощённый ответ или временная остановка. Выбор зависит от последствий для пользователя.

После инцидента сохраняют не содержание пользовательских запросов, а необходимую операционную картину: проект, ключ, время, статус, единицы потребления, списание и внутренний код операции. Ключи, prompt'ы, ответы и документы нельзя отправлять в маркетинговую аналитику. Для спорных списаний нужна воспроизводимая сверка, но TokenTool не заявляет неизменяемый аудит или SIEM.

В начале пилота сверку делают чаще, например раз в день, затем переходят к недельному или месячному циклу. Сравнивают плановый объём, фактические успешные операции, единицы потребления, стоимость, повторы и остаток. Если показатель стоимости одной полезной операции растёт, увеличение бюджета может скрыть дефект. Если он стабилен, лимит корректируют вместе с прогнозом клиентской нагрузки.

Каждое изменение лимита записывают с причиной и датой следующего пересмотра. Устаревшие ключи отключают после подтверждения владельца, а не оставляют на всякий случай. Так политика остаётся рабочим процессом, а не таблицей для аудита. Никакая настройка сама по себе не гарантирует экономию или доступность: результат зависит от приложения, выбранной модели, профиля запросов и качества эксплуатации.

Перед клиентским запуском политику прогоняют на отдельном тестовом ключе. Команда последовательно достигает warning threshold, имитирует ошибку повторов и проверяет hard level. Владелец должен получить сигнал, найти нужный проект, сопоставить журнал и выполнить согласованное действие. После теста временный ключ отзывают, а результаты сохраняют без значения секрета и пользовательского содержимого.

Учение проверяет также человеческую часть процесса: доступен ли ответственный, понятна ли эскалация и можно ли безопасно ограничить сервис. Если остановка приводит к потере очереди или повторному списанию, сначала исправляют приложение. Только успешный контролируемый прогон даёт основание переносить лимит в production; наличие заполненной таблицы само по себе ничего не подтверждает. Дату следующего учения фиксируют рядом с владельцем политики.