Бібліотека детекторівОбмеження частоти запитів

Обмеження частоти запитів

Очікування на постачальника.

Відрізняйте відмови через потужність від продуктивної роботи агента.

Побачте проблему. Зрозумійте знахідку.

Озвучення англійською з субтитрами.

Як це залишається непоміченим

Ваш агент не закінчив, але й насправді не думає. Запити продовжують повертатися з помилкою потужності. Без чіткого сигналу обмеження постачальника може виглядати як повільна або не відповідає сесія.

Уявіть дві відмови постачальника під час виконання завдання. Агент може тихо повторювати спроби або припинити рухатися вперед. Подальше очікування не вирішить кожну проблему з квотою або потужністю, особливо коли кілька сесій ділять ті самі ліміти.

Що виявляє ClawMetry

ClawMetry шукає відмови через потужність у результатах інструментів і явних подіях API-помилок. Він розпізнає коди статусу, такі як HTTP 429 та HTTP 529, а також текст про обмеження частоти запитів і перевантаження. Повторні відмови підіймають попередження.

Різниця, яка змінює знахідку

Приклад спрацювання

2 відмови через потужність

Попереджувальна знахідка

Тиха порівняльна ситуація

1 відмова через потужність

Для цього детектора знахідок немає.

У перевіреному прикладі дві події помилки HTTP 429 формують знахідку про обмеження частоти запитів. Одна відмова залишається нижче стандартного порогу. Знахідка включає кількість відмов, тому ви можете відрізнити повторювану проблему від одного перехідного відгуку.

Перегляньте результат детектора
{
  "kind": "rate_limited",
  "severity": "warning",
  "evidence": {
    "refusals": 2,
    "threshold": 2,
    "threshold_source": "static",
    "observed": "HTTP 429/529 status or rate-limit text on tool results and API error events",
    "sample": ""
  }
}
Завантажити вхідні дані та повні результати (JSON)
Як перевірявся приклад

Ці приклади оцінюють опублікований детектор із авторськими даними подій або одноразовими файлами конфігурації. Відео ілюструє цю поведінку. Це не записи живих агентів або інтерфейсу продукту. Жодна команда з прикладів не виконувалась.

Результат встановлює поведінку для цих вхідних даних. Він не встановлює прийом у середовищі виконання, запобігання або реального компрометування. Перегляньте закріплений вихідний контракт.

Що перевірити далі

Перевірте статус постачальника і ліміти для облікового запису або моделі, що використовується. Зменшіть паралельну роботу або зачекайте скидання відповідного ліміту, де це доречно. Потім підтвердіть відновлення запитів, а не просто припускайте, що агент відновив роботу.

  1. Перевірте статус постачальника
  2. Перевірте квоту та паралелізм
  3. Підтвердіть відновлення запитів

Що встановлює цей сигнал

Це симптом потужності, а не діагноз першопричини. Він не підвищує квоти автоматично і не перемикає постачальників.

Тримайте важливі моменти у полі зору.

Стежте за активністю агента, перевіряйте знахідки та вирішуйте, що потребує вашої уваги.