Управление квотами: Комбинация Quota Protection + Smart Warmup

Вы уже довольно стабильно используете Antigravity Tools в качестве прокси, но больше всего боитесь一件事: квота ключевой модели незаметно «съедена», и когда вам реально нужно её использовать, вы обнаруживаете, что она уже настолько низка, что запрос невозможен.

В этом уроке подробно рассказывается об управлении квотами: используйте Quota Protection, чтобы сохранить ключевые модели; используйте Smart Warmup, чтобы выполнить «лёгкий разогрев» когда квота вернётся к полному объёму, снизив временные перебои.

Что такое управление квотами?

Управление квотами означает использование двух связных механизмов в Antigravity Tools для контроля «как тратятся квоты»: когда процент остаточной квоты определённой модели падает ниже порога, Quota Protection добавит эту модель в protected_models учётной записи, при запросе этой модели она будет избегаться с приоритетом; когда квота вернётся к 100%, Smart Warmup запустит запрос разогрева с минимальным трафиком и использует локальный исторический файл для 4-часового охлаждения.

Что вы сможете сделать после изучения

• Включить Quota Protection, чтобы учётные записи с низкой квотой автоматически «уступали дорогу», сохраняя высокоценные модели для ключевых запросов
• Включить Smart Warmup, чтобы автоматически разогревать, когда квота вернётся к полному (и знать, как 4-часовое охлаждение влияет на частоту срабатывания)
• Понять, какие поля quota_protection / scheduled_warmup / protected_models вступают в силу где
• Знать, какие имена моделей будут нормализованы в «группу защиты» (а какие не)

Ваша текущая проблема

• Вы считаете, что выполняете «ротацию учётных записей», но на самом деле постоянно потребляете один и тот же класс высокоценных моделей
• Квота стала низкой, только когда вы обнаруживаете, что даже warmup клиентов вроде Claude Code потратил лимит
• Вы включили разогрев, но не знаете, когда именно он срабатывает, есть ли охлаждение, повлияет ли это на квоту

Когда использовать этот подход

• У вас есть несколько пулов учётных записей, и вы хотите, чтобы ключевые модели в «важный момент» ещё имели запас
• Вы не хотите вручную следить за временем возврата квоты к полному, хотите, чтобы система автоматически выполняла «проверку после возврата к полному»

🎒 Подготовка перед началом

Предварительные требования

В этом уроке подразумевается, что вы уже умеете:

• На странице Accounts видеть список учётных записей и вручную обновлять квоту
• Уже запускали локальный обратный прокси (минимум доходит до /healthz)

Кроме того, Smart Warmup будет записывать локальный исторический файл warmup_history.json. Он находится в каталоге данных, как найти каталог данных и как выполнять резервное копирование, можно сначала посмотреть Первый запуск: Каталог данных, журналы, трей и автозапуск.

Основная идея

Эта «комбинированная стратегия» по сути очень проста:

• Quota Protection отвечает за «прекратить трату»: когда модель ниже порога, она помечается как защищённая, при запросе этой модели она избегается с приоритетом (на уровне модели, а не универсальное отключение учётной записи).
• Smart Warmup отвечает за «проверить после возврата к полному»: когда модель возвращается к 100%, запускается запрос разогрева с минимальным трафиком, подтверждая доступность цепочки, и используется 4-часовое охлаждение, чтобы избежать повторных помех.

Им соответствуют поля конфигурации в AppConfig на стороне фронтенда:

• quota_protection.enabled / threshold_percentage / monitored_models (см. src/types/config.ts)
• scheduled_warmup.enabled / monitored_models (см. src/types/config.ts)

А логика, действительно определяющая «при запросе этой модели нужно ли пропустить эту учётную запись», находится на стороне бэкенда в TokenManager:

• Поле protected_models в файле учётной записи будет участвовать в фильтрации в get_token(..., target_model) (см. src-tauri/src/proxy/token_manager.rs)
• target_model будет сначала нормализован (normalize_to_standard_id), поэтому варианты вроде claude-sonnet-4-5-thinking будут свёрнуты в одну и ту же «группу защиты» (см. src-tauri/src/proxy/common/model_mapping.rs)

Следуйте за мной

Шаг 1: Сначала приведите квоту в «понятное состояние»

Почему Quota Protection основывается на quota.models[].percentage учётной записи. Если вы не получили квоту, логика защиты не может сработать на вас.

Путь действий: откройте страницу Accounts, нажмите кнопку обновления на панели инструментов (отдельная учётная запись или массово).

Вы должны увидеть: в строках учётных записей появляются проценты квоты по моделям (например, 0-100) и reset time.

Шаг 2: Включите Smart Warmup в Settings (необязательно, но рекомендуется)

Почему Цель Smart Warmup не «экономить квоту», а «проверить цепочку после возврата квоты к полному». Он срабатывает только когда квота модели достигает 100%, и есть 4-часовое охлаждение.

Путь действий: перейдите в Settings, перейдите в область настроек учётных записей, включите переключатель Smart Warmup, затем выберите модели, которые хотите мониторить.

Не забудьте сохранить настройки.

Вы должны увидеть: после развертывания Smart Warmup появляется список моделей; сохраняется минимум 1 отмеченная модель.

Шаг 3: Включите Quota Protection и установите порог и модели мониторинга

Почему Quota Protection — это ядро «сохранения запасов»: когда процент квоты отслеживаемых моделей <= threshold_percentage, эта модель будет записана в protected_models файла учётной записи, при последующих запросах этой модели будут с приоритетом пропущены这类 учётные записи.

Путь действий: в Settings включите переключатель Quota Protection.

1. Установите порог (1-99)
2. Отметьте модели, которые хотите мониторить (минимум 1)

Очень удобная начальная конфигурация

Если вы не хотите ломать голову, начните с threshold_percentage=10 по умолчанию (см. src/pages/Settings.tsx).

Вы должны увидеть: в отмеченных моделях Quota Protection сохраняется минимум 1 (UI не позволит вам отменить последнюю).

Шаг 4: Подтвердите «нормализацию группы защиты» не приведёт вас к ловушке

Почему Когда TokenManager принимает решение о защите квоты, он сначала нормализует target_model в стандартный ID (normalize_to_standard_id). Например, claude-sonnet-4-5-thinking будет нормализован в claude-sonnet-4-5.

Это означает:

• Вы отмечаете claude-sonnet-4-5 в Quota Protection
• Когда вы фактически запрашиваете claude-sonnet-4-5-thinking

Всё ещё будет срабатывать защита (потому что они принадлежат одной группе).

Вы должны увидеть: когда protected_models какой-либо учётной записи содержит claude-sonnet-4-5, запросы к claude-sonnet-4-5-thinking будут с приоритетом пропускать эту учётную запись.

Шаг 5: При необходимости немедленной проверки используйте «ручной разогрев»

Почему Периодическое сканирование Smart Warmup — раз в 10 минут (см. src-tauri/src/modules/scheduler.rs). Если вы хотите немедленно проверить доступность цепочки, ручной разогрев более прямой.

Путь действий: откройте страницу Accounts, нажмите кнопку «Разогреть» на панели инструментов:

• Не выбирайте учётную запись: запускается массовый разогрев (вызывается warm_up_all_accounts)
• Выберите учётную запись: по очереди запускается разогрев для выбранных учётных записей (вызывается warm_up_account)

Вы должны увидеть: появляется toast, содержимое из строки, возвращаемой бэкендом (например, "Warmup task triggered ...").

Контрольная точка ✅

• Вы можете видеть процент квоты по моделям на странице Accounts (доказывая, что цепочка данных квоты OK)
• Вы можете включить Quota Protection / Smart Warmup в Settings и успешно сохранить конфигурацию
• Вы понимаете, что protected_models — это «ограничение на уровне модели»: одна учётная запись может быть пропущена только для определённых моделей
• Вы знаете, что у разогрева есть 4-часовое охлаждение: повторное нажатие разогрева в короткое время может увидеть подсказки о «skipped/cooldown»

Напоминания о возможных ошибках

1) Вы включили Quota Protection, но она всё ещё не срабатывает

Самая частая причина: у учётной записи нет данных quota. Логика защиты на стороне бэкенда должна сначала прочитать quota.models[], чтобы судить о пороге (см. src-tauri/src/proxy/token_manager.rs).

Вы можете вернуться к Шагу 1, сначала получить квоту.

2) Почему только несколько моделей будут считаться «группой защиты»?

Нормализация target_model в TokenManager — это «белый список»: только явно перечисленные имена моделей будут сопоставлены со стандартным ID (см. src-tauri/src/proxy/common/model_mapping.rs).

Логика после нормализации: использовать нормализованное имя (стандартный ID или исходное имя модели) для сопоставления с полем protected_models учётной записи. Если совпадение успешно, эта учётная запись будет пропущена (см. src-tauri/src/proxy/token_manager.rs:555-560, 716-719). Это означает:

• Модели в белом списке (например, claude-sonnet-4-5-thinking) будут нормализованы в стандартный ID (claude-sonnet-4-5), затем проверяться, есть ли они в protected_models
• Модели вне белого списка при неудачной нормализации возвращаются к исходному имени модели, всё ещё будут сопоставляться с protected_models

Другими словами, решение о защите квоты действительно действует на «все имена моделей», только модели в белом списке будут сначала нормализованы.

3) Почему ручной/плановый разогрев требует, чтобы прокси был запущен?

Запросы разогрева в конечном итоге попадут на внутреннюю конечную точку локального прокси: POST /internal/warmup (см. маршрут в src-tauri/src/proxy/server.rs, а также реализацию в src-tauri/src/proxy/handlers/warmup.rs). Если вы не запустили службу прокси, warmup не удастся.

Кроме того, порт вызываемого разогрева берётся из конфигурации: proxy.port (если чтение конфигурации не удаётся, он вернётся к 8045 по умолчанию, см. src-tauri/src/modules/quota.rs).

Краткое содержание урока

• Quota Protection выполняет «стоп-убыток»: при падении ниже порога записать модель в protected_models, при запросе этой модели избегать с приоритетом
• Smart Warmup выполняет «проверку после возврата к полному»: срабатывает только при 100%, сканирование раз в 10 минут, 4-часовое охлаждение
• Оба зависят от цепочки «обновление квоты»: сначала есть quota.models[], тогда управление имеет основу

Предварительный просмотр следующего урока

Управление квотами решает «как тратить стабильнее». Следующий урок — посмотреть Proxy Monitor, превращая вызовы чёрного ящика в воспроизводимую цепочку доказательств.

---

Приложение: Ссылка на исходный код

Нажмите, чтобы развернуть и просмотреть местоположение исходного кода

Дата обновления: 2026-01-23

Функция	Путь к файлу	Номер строки
UI Quota Protection (порог, выбор модели, минимум 1)	src/components/settings/QuotaProtection.tsx	13-168
UI Smart Warmup (включить по умолчанию, минимум 1)	src/components/settings/SmartWarmup.tsx	14-120
Поля конфигурации управления квотами (quota_protection / scheduled_warmup)	src/types/config.ts	54-94
Порог по умолчанию и конфигурация по умолчанию (threshold_percentage: 10)	src/pages/Settings.tsx	20-51
Запись/восстановление protected_models (суждение порога и сохранение на диск)	src-tauri/src/proxy/token_manager.rs	254-467
Фильтрация защиты квоты на стороне запроса (get_token(..., target_model))	src-tauri/src/proxy/token_manager.rs	470-674
Нормализация группы защиты (normalize_to_standard_id)	src-tauri/src/proxy/common/model_mapping.rs	230-254
---	---	---
Команды ручного разогрева (warm_up_all_accounts / warm_up_account)	src-tauri/src/commands/mod.rs	167-212
Реализация разогрева (вызов внутренней конечной точки /internal/warmup)	src-tauri/src/modules/quota.rs	271-512
Реализация внутренней конечной точки разогрева (создание запроса + вызов вышестоящего)	src-tauri/src/proxy/handlers/warmup.rs	3-220