Баланс API есть, но квоты недостаточно: ключ, группа и резервирование
Что проверить после зачисления средств: источник оплаты, лимит API Key, группу и резерв запроса. Пошаговая диагностика без лишних пополнений и снятия всех ограничений.
Если в панели API-посредника есть деньги, а запрос завершается сообщением о недостаточной квоте, не спешите пополнять счёт ещё раз. Баланс на главной странице, доступный лимит API Key, область действия подписки и сумма предварительного резервирования для запроса могут быть разными величинами. Сначала найдите уровень, который отклонил запрос.
Статья посвящена ситуации, когда пополнение уже зачислено, но определённое приложение или ключ по-прежнему не работает. Примеры механизмов взяты из фиксированной версии официального открытого проекта New API. Не все посредники используют этот проект, а версия, интерфейс и правила конкретного сервиса могут отличаться. Все числовые примеры ниже условные и выражены во внутренних единицах квоты, а не в реальных ценах или списаниях.
1. Проверьте четыре уровня вместо одного баланса
| Уровень | Что записать | Типичная ошибка |
|---|---|---|
| Аккаунт и источник оплаты | Аккаунт, рабочее пространство, кошелёк, остаток подписки и срок действия | Считать средства другого аккаунта или неподходящей подписки доступными этому запросу |
| API Key | Название или внутренний ID ключа, состояние, срок действия и остаток квоты | Предполагать, что пополнение кошелька автоматически увеличивает отдельный лимит старого ключа |
| Группа и модели | Группа ключа, разрешённые модели, источник оплаты и правила IP | Принимать ошибки доступа или маршрутизации за нехватку денег |
| Отдельный запрос | Модель, размер ввода, предел вывода, параллельность, резервирование и итоговое списание | Подменять необходимую сейчас квоту стоимостью прошлого запроса |
В структуре токена New API отдельно хранятся remain_quota, unlimited_quota, срок действия, ограничения моделей, IP и группа. Проверка учитывает состояние, истечение срока и остаток токена с ограниченной квотой.[1] Поэтому сам ключ может блокировать запрос, даже если на главной странице виден положительный баланс.
Здесь «токен» означает учётные данные API Key, а не текстовые токены ввода и вывода модели. Если интерфейс показывает неограниченную квоту, уточните, какой именно лимит отменён. Это не означает бесплатных запросов и не отменяет ограничения средств аккаунта, доступа к моделям или частоты вызовов.
Сначала уточните единицы. Если знак доллара обозначает внутреннюю расчётную квоту, её нельзя автоматически приравнивать к денежным долларам. Подробнее — в статье о внутренних единицах и реальной оплате. Сопоставляйте значения в одинаковых единицах, для одного аккаунта и на один момент времени.
2. Сохраните ошибку и определите уровень отказа
Приостановите автоматические повторы или пакетную очередь неудачного задания. Для одного запроса сохраните время с часовым поясом, HTTP-статус, поля code/type/message из тела ошибки, идентификатор запроса, модель и группу. Одного переведённого клиентом сообщения «недостаточно средств» мало. Клиент, шлюз или upstream могли переоформить ошибку; HTTP-статус сам по себе не указывает, чей расчётный уровень отказал.
Ответьте на три вопроса:
- Какой ключ какого аккаунта реально использует приложение? Сверьте название в панели, внутренний ID или безопасную метку, известную вам. Не выводите полный ключ в журнал и не вставляйте его в сторонний онлайн-анализатор. Проверяйте среду развёрнутого приложения, а не только локальный файл настроек.
- Есть ли запрос в журнале шлюза? Если есть, посмотрите этап отказа и выбранный канал. Отсутствие записи может объясняться задержкой или областью журналирования; это не доказывает, что запрос не дошёл до сервера.
- Ошибка явно указывает на квоту ключа? Путь предварительного списания New API может вернуть
token quota is not enoughс доступной и необходимой квотой.[2] Это подсказка для данной реализации; другой сервис может менять текст. Доступ к модели, ограничения источника и квоту upstream проверяют отдельно.
Работающий чат в панели при неработающем приложении тоже не доказывает исправность API Key. В проверенном коде New API для Playground есть отдельные ветви в части обработки квоты токена.[2] Сравнивайте запросы с одинаковым способом доступа: веб-песочница и обращение по отдельному ключу не обязательно представляют один и тот же эксперимент.
3. Проверяйте по порядку и меняйте одно условие
Шаг первый: уточните, куда зачислено пополнение. Сверьте аккаунт заказа, запись о зачислении и тип средств. Страница успешной оплаты не доказывает, что нужное рабочее пространство получило квоту для выбранной модели. Если есть кошелёк и подписка, выясните, какой источник выбрал запрос и разрешён ли переход на другой. Не предполагайте автоматическое списание сначала бонусов или обязательное переключение на кошелёк.
Шаг второй: откройте настройки фактически используемого ключа. Проверьте состояние, срок действия и остаток. Различайте накопленный расход, установленный предел и доступную квоту. Нельзя сравнивать уже потраченную сумму с потребностью нового запроса. Перед изменением выясните, редактируется остаток или общий предел, и оставайтесь в допустимом бюджете. Для диагностики необязательно включать неограниченный доступ.
Шаг третий: проверьте группу и область действия. Не меняя модель и ключ, уточните поддержку модели в группе, применимость средств и отдельные ограничения. Группы могут иметь разные цены или каналы, поэтому случайная смена группы разрушает сравнение. Если модель есть в списке, но вызов не проходит, используйте диагностику имени модели, пути и доступа.
Шаг четвёртый: проверьте резервирование и незавершённые запросы. Некоторые системы резервируют квоту в начале, а после завершения рассчитывают фактический расход. Расчётная сессия New API содержит предварительное списание, корректировку разницы и возврат. Для разных типов запросов и настроек предусмотрены отдельные ветви, поэтому универсальной формулы резерва нет.[3] Дождитесь завершения уже запущенных запросов и сверьте неокончательные записи. Не считайте резерв окончательным списанием без проверки.
Шаг пятый: выполните одну контролируемую проверку. После проверки настроек используйте короткий текст без чувствительных данных, явно поддерживаемую модель и разумный предел вывода. Отключите автоматические повторы и замену модели. Генерация может быть платной — проводите её в пределах своего бюджета. Если резерв зависит от размера запроса, уменьшение запроса может помочь. При истёкшем ключе или неподходящей подписке сокращение текста проблему не исправит.
Сохраните результат и постепенно восстановите исходную задачу. Если одновременно заменить ключ, модель, группу и снова пополнить баланс, даже успешный результат не покажет, какое действие помогло.
4. Три условных примера положительного баланса и отказа
Далее используется упрощённая схема, в которой запрос одновременно ограничивают кошелёк и ключ. Подписки, права, коэффициенты цены и специальные ветви продукта не рассматриваются. Пусть для допуска одного запроса требуется резерв по 5 внутренних единиц на каждом уровне:
| Доступно аккаунту | Доступно ключу | Результат | Что проверять |
|---|---|---|---|
| 100 | 2 | Ключ не позволяет зарезервировать 5: отказ | Квоту ключа; новое пополнение аккаунта само по себе её не исправляет |
| 3 | Без отдельного лимита ключа | Аккаунт не позволяет зарезервировать 5: отказ | Источник оплаты; неограниченный ключ не создаёт средства |
| 100 | 10 | По квоте допустимы два запроса с резервом по 5 | Для третьего одновременного запроса квота ключа может быть уже занята |
В последнем примере предположим, что каждый из двух запросов в итоге потратил 1, а неиспользованная часть каждого резерва корректно освобождена. После расчёта у аккаунта останется 100 - 1 - 1 = 98, у ключа — 10 - 1 - 1 = 8. Если интерфейс уже показывает доступный остаток за вычетом резерва, не вычитайте этот резерв второй раз.
Пример не предсказывает списания конкретного сервиса и не доказывает, что неудачные запросы всегда бесплатны. Если запрос отправлен upstream, клиент получил тайм-аут или расчёт завершился с ошибкой, проверьте окончательную запись по идентификатору. Интерфейс может обновляться с задержкой или округлять значения. При пограничных суммах попросите сервис уточнить внутренний остаток и нужный резерв, вместо многократных пробных отправок.
Числа проверены локальной симуляцией. Реальные платные API не вызывались; скорость расчёта и сроки восстановления квоты у посредников не измерялись.
5. Подтвердите исправление, а не случайный успех
После успешного запроса проверьте фактический ключ, модель, группу и источник оплаты. Сверьте итоговый расход и остатки, исключите дополнительные повторы и автоматическую замену модели. Затем постепенно восстановите необходимую параллельность, сохранив бюджетные ограничения.
Если причина всё ещё неясна, отправьте поддержке следующую информацию:
Аккаунт/рабочее пространство: …; название или внутренний ID ключа: …; время с часовым поясом: …; модель и группа: …; HTTP-статус, обезличенный текст ошибки и ID запроса: …. В тот же момент аккаунту доступно …, ключу доступно …, единицы измерения …. Уточните, где произошёл отказ: средства аккаунта, квота ключа, применимость подписки, резервирование или квота upstream. Завершён ли расчёт этого запроса, остался ли неосвобождённый резерв и какое поле требуется изменить?
Не прикладывайте полный ключ, заголовок Authorization или рабочие промпты. Подробный порядок подготовки описан в статье о безопасном обращении в поддержку и минимальном воспроизведении.
Когда имеет смысл пополнение? Когда подтверждено, что запрос использует этот кошелёк, ключ и права модели в порядке, а доступных средств недостаточно для проверенного правила оплаты. Тогда решение принимают в пределах бюджета. Если отказывает один ключ, сначала проверяйте его. Если отказывают несколько клиентов одного аккаунта, проверьте общий источник оплаты и состояние сервиса, но не объявляйте это доказательством сбоя upstream.
Первичные источники и границы применимости
Использован фиксированный коммит официального репозитория New API b22a43b6e89e5349d8cdbddc88d570b16e15fb1f. Дата проверки — 2026-10-12. Источники подтверждают существование описанных механизмов, но не одинаковую версию во всех развёртываниях.