Kill switch расходов API для LLM-агентов: остановите бюджет до вызова провайдера

Kill switch расходов API для LLM-агента должен срабатывать до того, как запрос уйдет к платному провайдеру. Если агент умеет повторять шаги, запускать подагентов, вызывать инструменты или переключаться на запасной маршрут, бюджетная проверка должна стоять на пути каждого такого вызова. Отчет в billing dashboard и письмо о превышении бюджета полезны, но они приходят слишком поздно для runaway loop.

Минимальная рабочая схема выглядит так: оценить максимальную стоимость запроса, атомарно зарезервировать эту сумму в общем ledger, вызвать провайдера только если резервирование прошло, затем сверить фактический usage и вернуть остаток резерва. Если лимит будет нарушен, агент получает terminal over_budget с retryable: false.

Правило остановки должно быть записано явно: после over_budget агент не повторяет запрос, не запускает helper, не переключается на другой платный ключ и не просит tool сделать скрытый model call. Новое действие возможно только после ручного изменения лимита или политики.

Что считать настоящим kill switch

Настоящий kill switch расходов не равен dashboard, email alert, quota graph или обычному rate limit. Он должен иметь право сказать no до начала оплачиваемой работы. Такой контроль можно разместить в runtime агента, внутреннем OpenAI-compatible proxy, API gateway, wrapper перед провайдером или sidecar-сервисе. Главное требование одно: именно через него проходит credential path, которым агент реально пользуется.

Самая частая ошибка архитектурная. Команда добавляет budget warning после того, как worker уже получил direct provider key. Это защищает финансовую почту, но не следующий API call. Если агент имеет planner loop, retry loop, tool loop и очередь sub-agent, все эти пути должны тратить бюджет через один gate.

Разведите термины в runbook:

Эта лексика нужна не ради чистоты текста. Во время инцидента оператор должен спросить не "где у нас поле budget", а "какой компонент может запретить следующий платный вызов".

Выберите слой контроля

Надежная production-схема почти всегда слоистая. Primary stop стоит в request path, а provider, platform, token caps и alerts работают как backstops и observability.

Если у вас уже есть OpenAI-compatible proxy, начните там: один base URL легче контролировать, чем десятки SDK-вызовов. Если только runtime агента видит все tool-triggered calls, ставьте gate в runtime и заставьте подагентов наследовать тот же budget scope. Если у вас несколько providers, внутренний gateway обычно проще для аудита, чем копирование budget logic в каждый worker.

Плохой вариант - partial gate. Planner идет через бюджет, evaluator или retrieval tool держит прямой ключ, а emergency fallback route разрешен без ledger. При аварии агент все равно найдет путь к счету.

Реализуйте reserve, call, reconcile

До ответа провайдера точную цену вы не знаете, поэтому gate должен резервировать худший допустимый сценарий. Это консервативно, но именно так вы избегаете гонки между параллельными worker.

Минимальные поля ledger:

Flow до вызова:

ts
async function guardedModelCall(request) {
  const estimate = estimateWorstCaseCost(request);
  const reservation = await ledger.reserveAtomically({
    budgetId: request.budgetId,
    requestId: request.requestId,
    agentRunId: request.agentRunId,
    amount: estimate,
  });

  if (!reservation.allowed) {
    return { error: "over_budget", retryable: false };
  }

  const response = await provider.responses.create(request.payload);
  await ledger.reconcile({
    reservationId: reservation.id,
    actualAmount: costFromUsage(response.usage),
    usage: response.usage,
  });
  return response;
}

Ключевое слово - atomically. Если пять worker одновременно читают remaining budget и все вызывают provider, usage logs придут уже после перерасхода. Резервирование должно быть транзакцией базы, Redis script, durable workflow step или gateway operation, которая не допускает interleaving для одного budget_id.

Streaming требует отдельного правила. Первичный reserve равен максимальному выводу, который вы разрешили. Если usage доступен только в конце stream, сверяйте при закрытии. Если client disconnected до финального usage, не освобождайте весь reserve автоматически: оставьте conservative charge, пометьте unknown или запустите reconciliation job по provider logs.

Заставьте агента остановиться

Budget response должен быть частью agent semantics. Обычный timeout или 429 иногда можно повторять. over_budget нельзя повторять для того же scope.

json
{
  "error": "over_budget",
  "retryable": false,
  "budget_id": "team-alpha-agent-run",
  "next_allowed_action": "human_budget_override"
}

Три правила распространения:

Retry policy должен иметь отдельный stop list: over_budget, policy_blocked и missing_budget_scope не ретраятся. Их надо логировать, показывать оператору и завершать run. Нельзя разрешать агенту "попробовать другой маршрут" без новой бюджетной политики, потому что это меняет owner, key, gateway и liability.

Проверьте границы провайдеров и gateway

Provider controls полезны, но это разные механизмы. Перед публикацией runbook проверьте текущую документацию, потому что бюджетные функции и dashboard behavior меняются.

Для OpenAI rate-limit symptoms держите отдельную ветку incident response. Rate limit отвечает на throughput; spend kill switch отвечает на вопрос, должен ли ваш агент вообще отправлять следующий платный запрос.

Протестируйте без вызова провайдера

Готовность kill switch доказывается не красивым логом blocked, а тем, что после лимита provider counter остается нулевым.

Повторяйте эти тесты после изменения price metadata, model routing, retry policy, gateway config или storage. Если fake provider получает запрос после cap, это еще cost monitor, а не kill switch.

Production runbook

1. Заморозьте direct provider credentials и проверьте, что worker не может обойти gate.
2. Уточните budget scope: user, team, project, agent run или monthly account cap.
3. Проверьте ledger: actual spend, reserved spend, in-flight calls, unknown items.
4. Убедитесь, что агент получил terminal over_budget.
5. Остановите retries, sub-agent scheduling и tool-triggered model calls.
6. Сверьте provider logs с ledger records.
7. Решите: поднять cap, сузить задачу или закрыть run.
8. Для human override запишите approver, новый cap, срок действия и причину.

Самый опасный override - "попробуем через другой route". Это уже новая budget decision, а не retry.

Часто задаваемые вопросы

Достаточно ли OpenAI project budget?

Нет. Текущая справка OpenAI описывает project budgets как soft thresholds. Они полезны для governance и alerts, но runaway agent должен быть остановлен request-path gate до provider call.

Что возвращать: HTTP 402, 429 или domain error?

Выберите статус, который умеет ваш клиент, но payload важнее. В нем должны быть budget cap exceeded и retryable: false. Gateway может использовать 429, internal runtime часто удобнее возвращать over_budget.

Как оценить стоимость до ответа?

Берите maximum allowed input, output, tool, image или streaming cost. После call сверяйте actual usage и освобождайте остаток.

Что делать с поздним usage?

Держите reserve до reconciliation или помечайте unknown с conservative charge. Не открывайте бюджет сразу после interrupted stream.

Нужны ли sub-agent отдельные budgets?

Можно, но parent cap должен наследоваться. Helper не должен тратить после остановки parent run.

Если у нас уже есть gateway?

Проверьте, что каждый paid model path идет через gateway. Потом протестируйте low cap, parallel calls и fake provider. Gateway становится primary kill switch только без bypass routes.