ChatGPT API: бюджет токенов пользователя без скрытых списаний

Разделите локальный бюджет и счёт поставщика

Бюджет пользователя — это правило вашего продукта: например, дневной предел попыток, оценочного объёма или допустимой очереди. Он не равен балансу аккаунта, цене модели, лимиту контекста или квоте внешнего маршрута. В интерфейсе называйте его именно локальным лимитом, чтобы не создать у пользователя ложного ожидания списания или доступа.

Сначала определите единицу и период. Для коротких диалогов может быть полезна консервативная оценка символов или токенов до отправки; для асинхронной задачи — отдельный резерв с последующей сверкой результата. Не публикуйте формулу как универсально точную: токенизация, формат и фактический контракт могут меняться.

Проверяйте лимит до сетевого вызова

Проверка должна выполняться на сервере после аутентификации и до постановки задачи в очередь. Клиент передаёт только свой запрос; tenant, роль, счётчик периода и разрешённое действие приложение получает из своей сессии. Так браузер не может подменить оставшийся бюджет другого пользователя или попросить больше, чем разрешено policy.

Если предварительная оценка превышает локальный порог, верните понятный код приложения и предложите безопасный следующий шаг: сократить ввод, дождаться нового периода или обратиться к владельцу проекта. Не отправляйте заведомо отклоняемую операцию «для проверки» и не показывайте пользователю внутренние параметры маршрута.

Учитывайте неизвестный итог честно

После timeout нельзя автоматически считать, что бюджет не затронут и можно сразу повторить запрос. Сохраните operation ID, отметьте исход как unknown и сначала выполните разрешённую локальную сверку. Для операции с побочным действием резерв не должен исчезать только потому, что клиент потерял соединение.

Отдельно храните estimate, решение policy и подтверждённый наблюдаемый итог. Это облегчает разбор без копирования prompt в журнал. Если факт результата нельзя установить, оставьте запись для review; не заявляйте о списании, возврате или успехе внешней стороны без подтверждённого источника.

Сделайте правила прозрачными для команды

Опишите, кто меняет локальный порог, какие роли видят агрегированные метрики и какой сигнал требует остановки. Полезны анонимные счётчики по tenant и категории операции, но не полные тексты запросов. Для нового лимита проведите маленький canary: убедитесь, что отказ понятен, а легитимные сценарии не блокируются ошибочно.

Свяжите бюджет с доступом проекта, а не с именем модели или обещанной ценой. Каталог и доступность меняются, поэтому policy должна разрешать только проверенные маршруты и иметь ручной путь rollback. Такой подход помогает контролировать собственный продукт, не выдавая его за биллинг или SLA RussiaAPI либо другого сервиса.

Проверьте интерфейс ограничения

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

Продолжите с ролями доступа проекта, идемпотентностью повторов и общим deadline API. Эти материалы объясняют соседние локальные механизмы, но не подтверждают условия какого-либо внешнего тарифа.

Начинайте с локальной границы

До интеграции определите, какое решение остаётся за приложением: доступ пользователя, допустимый объём, схема результата или публикация побочного действия. Ответ модели, сетевой статус и название маршрута не заменяют это решение. Явная граница помогает не превратить технический пример в несуществующую гарантию поставщика.

Для проверки используйте синтетический сценарий с обезличенными значениями. Не помещайте в fixture реальный prompt, вложение, cookie, заголовок Authorization или чужой ключ. В журнале обычно достаточно времени, версии адаптера, локального operation ID, категории исхода и хэша нормализованной структуры.

Тестируйте изменения на staging

Минимальный тест должен различать корректный ответ, ошибку валидации, отказ в доступе, временную сеть и неизвестный итог. Для каждого состояния заранее назначьте действие: остановка, ручной review или безопасное повторение. Бесконечный retry не исправляет неверный контракт и не подтверждает, что внешняя операция не была выполнена.

Фиксируйте дату, версию клиента и условия теста. Если меняются SDK, каталог или формат ответа, повторите маленький контрактный тест до расширения трафика. Один удачный вызов показывает только наблюдаемый сценарий в конкретной конфигурации, а не постоянную совместимость или качество модели.

Минимизируйте технические данные

Не записывайте в логи секреты, полный пользовательский текст, медиа-URL и сырой ответ, если они не нужны для диагностики. Отделите краткое пользовательское сообщение от защищённой серверной записи. Доступ к журналу ограничьте ролями, а срок хранения задайте локальной политикой и классификацией данных.

Пример кода ниже выполняет лишь локальную проверку: он не вызывает сеть, не содержит ключей и не доказывает поддержку endpoint. Используйте только собственный ключ RussiaAPI на сервере и сверяйте актуальный контракт и каталог в аккаунте перед реальным вызовом.

Сохраняйте обратимый путь

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

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

Безопасный server-side пример

Этот пример не делает сетевой вызов, не содержит реальных ключей и не подтверждает доступность endpoint. Перед подключением сверяйте актуальный контракт, каталог и условия своего аккаунта.

export function reserveLocalBudget({ tenantId, estimate, remaining }) {
  if (!tenantId || !Number.isSafeInteger(estimate) || estimate < 1) return { ok: false, code: 'invalid_input' };
  if (!Number.isSafeInteger(remaining) || estimate > remaining) return { ok: false, code: 'local_budget_exceeded' };
  return { ok: true, reservation: { tenantId, amount: estimate, state: 'pending_confirmation' } };
}

Источники и границы

OWASP Authorization Cheat Sheet · OpenAI API documentation

Источники описывают общие инженерные принципы. Они не подтверждают, что конкретная возможность включена у RussiaAPI или в вашем аккаунте. Соблюдайте применимые правила и не передавайте секреты в браузер или лог.

FAQ

Это лимит RussiaAPI или поставщика?

Нет. В статье описан локальный предел вашего приложения. Фактические цены, остаток, доступность и правила внешнего маршрута нужно смотреть в актуальном договоре, консоли и документации.

Можно ли повторить запрос после timeout?

Не автоматически. Сначала сохраните локальный operation ID и честно отметьте неизвестный итог. Повтор разрешайте только после безопасной сверки и защиты от двойного действия.

Нужно ли хранить prompt для учёта?

Обычно нет. Для бюджетной логики достаточно агрегированного estimate, tenant, времени и безопасной категории результата. Правила хранения данных определяет ваша организация.

Следующий шаг

Откройте RussiaAPI, подтвердите маршрут в своём аккаунте и проверьте синтетический сценарий на staging. Затем продолжите с материалами: Роли доступа проекта · Идемпотентность повторов · Deadline API.