> ## Documentation Index > Fetch the complete documentation index at: https://docs.apiyi.com/llms.txt > Use this file to discover all available pages before exploring further. # Что такое механизм предварительного списания для API-вызовов? > Как работает предварительное списание (предварительно потреблённая квота) в APIYI: перед запросом оно оценивает удержание на основе цены модели и входных данных, а затем производит окончательный расчёт по фактическому использованию — а также как читать ошибку insufficient_user_quota. ## Краткий ответ Перед тем как запрос **фактически выполняется**, APIYI рассчитывает **предварительное удержание** («цена модели × предполагаемые token» — максимальная возможная стоимость) и временно блокирует эту сумму на вашем балансе. Когда запрос завершается, система **производит окончательный расчет по фактически использованным tokens и возвращает разницу** — предварительное удержание это только оценка, а не итоговый счет. **Две ключевые строки** * **Предварительное удержание**: предварительная оценка перед запросом, которая используется, чтобы понять, «можете ли вы оплатить этот вызов». * **Фактическая тарификация**: окончательный расчет по реальным token после завершения запроса — именно это и списывается по-настоящему. Если **оценка предварительного удержания > ваш текущий баланс**, запрос отклоняется еще до запуска, и возвращается `insufficient_user_quota`. Это и есть основная причина ситуации «баланс у меня явно есть, но запрос все равно не проходит». ## Как работает предварительное списание Система читает ваш **input** (prompt, изображения, историю переписки и т. д.) и, используя текущую цену модели и **оценочную длину output**, вычисляет **максимально возможную стоимость** и временно удерживает ее из вашего баланса. Оценка примерно такая: `pre-deduction ≈ model price × (input tokens + estimated output tokens)` Она сравнивает **предварительное списание** с вашим **текущим балансом**: * balance ≥ pre-deduction → разрешено, запрос отправляется * balance \< pre-deduction → отклонено с `insufficient_user_quota`, и **вызов фактически не выполняется** После завершения система берет фактическое использование token для input/output и пересчитывает списание по факту: * фактическая стоимость **обычно меньше**, чем pre-deduction → излишне удержанная квота **возвращается** на ваш баланс * неудачные/прерванные запросы → как правило, не тарифицируются, а удержанная квота освобождается **Большое предварительное списание не означает, что вы действительно потратили столько же** — это оценка в формате «резерв на худший случай». Фактически списываются actual token после завершения запроса. ## Чтение ошибки insufficient\_user\_quota Когда предварительное списание превышает ваш баланс, вы увидите примерно такое: ```json theme={null} { "error": { "message": "user [25359] quota [50264897] preConsumedQuota [154753475] is not enough", "localized_message": "Insufficient user quota", "type": "shell_api_error", "param": "", "code": "insufficient_user_quota" } } ``` По полям: | Поле | Значение | | ------------------------------- | ---------------------------------------------------------------------------------- | | `quota [50264897]` | Ваш **текущий доступный баланс** (внутренняя единица квоты) | | `preConsumedQuota [154753475]` | **Квота, которую этот запрос хочет предварительно списать** | | `is not enough` | предварительное списание > баланс, недостаточно для удержания, **запрос отклонен** | | `code: insufficient_user_quota` | Код ошибки: недостаточная квота пользователя | Важно именно **соотношение** между двумя числами: здесь предварительное списание `154753475` примерно в **3×** больше баланса `50264897`, поэтому оно блокируется. Эти числа — это **внутренние единицы квоты** APIYI, и их можно напрямую сравнивать. В долларовом выражении: баланс ≈ \$100, оценка предварительного списания для этого запроса ≈ \$310 (внутри системы \~500,000 единиц ≈ \$1). Иными словами, этот единственный запрос попытался удержать более \$300, хотя на счете было только \$100 — поэтому он не смог выполниться. ## Почему «у меня есть баланс, но это не запускается» В подавляющем большинстве случаев **проблема в слишком большом input**, а не в самом балансе. Реальный пример: `gpt-5.5` имеет контекстное окно до 1,050,000 tokens. Если загрузить туда **весь большой code repository**, количество input token становится огромным, и предварительное списание резко возрастает — даже при балансе в \$100 оценка в \$300 все равно будет отклонена еще до запуска запроса. **Чем больше input, тем выше предварительное списание** Слишком большой input не только увеличивает предварительное списание и легко вызывает `insufficient_user_quota`, но и: * даже если запрос пройдет, **фактическая стоимость будет высокой** (тарификация идет по реальным token); * если загрузить слишком много нерелевантного контента, модель может **вернуть посредственный результат** — деньги потрачены, а результат слабый. ## Как исправить и избежать этого Отправляйте только **релевантный** код/документацию — не загружайте весь репозиторий или длинный документ целиком. Это самый эффективный способ исправить проблему. Явно ограничьте длину вывода, чтобы снизить «оценочное количество output tokens» и, соответственно, предварительное списание. См. [руководство по max\_tokens](/ru/faq/max-tokens). Если вам действительно нужен большой входной объем, просто убедитесь, что баланс > предварительное списание. См. [способы оплаты](/ru/faq/payment-methods). Проверьте, что ваш входной объем разумен для дешевой модели, а затем переключитесь на более дорогую — не допускайте «сжигания больше, чем вы можете себе позволить». **Будьте осторожны с большими входными данными**: модели с большим контекстным окном (например, у `gpt-5.5` 1.05M tokens) могут удерживать очень много, но «могут удерживать» не означает «должны удерживать». Запихивать в них весь репозиторий часто и дорого, и посредственно — сначала подумайте, какой контекст вам действительно нужен. ## Вопросы и ответы Нет. Предварительное списание — это лишь **временное удержание перед запросом**; окончательное списание определяется **фактическим использованием token** после завершения запроса, а излишне удержанная часть возвращается. `preConsumedQuota`, который вы видите, — это оценка «резерв на худший случай», а не реальный счет. Обычно нет. Ошибка `insufficient_user_quota` блокируется **до выполнения**, поэтому модель фактически не вызывается, реальных затрат не возникает, а удержанная квота освобождается. В этой ошибке сравнивается **предварительное списание** с вашим балансом, а не «фактическая стоимость» с балансом. Слишком большой ввод делает оценку предварительного списания намного выше вашего баланса, поэтому запрос отклоняется. Сначала сократите ввод или задайте `max_tokens`, чтобы снизить оценку вывода, и пополните баланс, если этого все еще недостаточно. Базовая цена модели задается самой моделью — **большее окно ≠ более высокая цена за единицу**. Но большее окно означает, что вы *можете* передать больше ввода, и когда вы действительно заполняете его, количество input tokens резко растет, и как предварительное списание, так и фактическая стоимость становятся высокими. Дорого стоит не само окно, а «сколько вы в него помещаете». ## Связанные документы Полная диагностика и способы устранения проблемы с недостаточным балансом. Управляйте длиной вывода, это влияет на предварительную оценку списания. Поймите, как работает тарификация по факту использования. Как быстро пополнить баланс, когда он низкий.