Claude API враќа 429: retry не помага ако го погодите погрешниот лимит

Кога Claude API враќа 429, прво прочитајте ја причината за грешката. Документацијата на Anthropic за лимитите наведува дека надминувањето на стапката за барања, влезни или излезни токени враќа 429 со заглавје retry-after. Тоа заглавје кажува колку секунди треба да почекате пред повторен обид. Месечниот лимит за потрошувачка на тарифното ниво, пак, може да врати ист статус без retry-after; кратко чекање тогаш нема да го врати пристапот.

Пред да испратите барање, избројте ги влезните токени со моделот и содржината што планирате да ги користите. Упатството за броење токени го опишува повикот messages.count_tokens, кој враќа проценка во полето input_tokens. Таа проверка помага да го планирате влезот, но дијагнозата за веќе одбиено барање доаѓа од пораката за грешка и заглавјата на одговорот. Повторувајте само кога причината е привремена и кога задачата сè уште има време за нов обид.

Избројте го влезот пред да го ставите барањето во редица

Составете ја пораката еднаш, па предадете ги нејзиниот модел, системската инструкција, пораките и поддржаните дефиниции на алатки на messages.count_tokens. Зачувајте ја проценката со задачата што ќе ја испратите преку Messages API. Така работникот што ја презема задачата може да ја спореди нејзината големина со расположливиот капацитет, наместо да одлучува само според бројот на задачи во редицата.

Бројачот пресметува влезни, а не идни излезни токени. Неговиот резултат е проценка и вистинската потрошувачка при создавање порака може малку да се разликува. Поставете max_tokens според потребниот одговор и буџетот на задачата, но не додавајте ја целата таа вредност на проценката за влез: таа е горна граница за одговорот, не веќе потрошени токени.

Preflight броењето има граница што е важна за реални интеграции. Endpoint-от може да врати invalid_request_error за влез што Messages API го прифаќа, вклучувајќи повеќето серверски алатки, MCP-конекторот и блокови за слика или документ со извор url или file. Слики и PDF-документи може да се испратат како base64 за броење. Кога користите неподдржана серверска алатка, неуспехот на бројачот не значи дека вистинското барање е невалидно; искористете го полето usage од одговорите на Messages API за понатамошно планирање.

Разликувајте RPM, ITPM и OTPM

RPM е бројот на барања во минута. Ако тој лимит е тесното грло, скратувањето на промптот нема да го намали бројот на испраќања. Ограничете го приливот од сите работници што го делат лимитот и избегнувајте нагли налети: минутна стапка може да се спроведува и во пократки интервали.

ITPM ги мери влезните токени во минута. Тука влијаат должината на контекстот, приложените содржини и повторливите делови од промптот. Кај повеќето модели, токените прочитани од кеш не се бројат во ITPM, додека новиот влез и токените со кои се создава кеш се бројат. Затоа вкупниот резултат од preflight броењето не треба механички да се изедначи со влезот што ќе го потроши минутниот лимит при кеширан промпт.

OTPM ги мери излезните токени што навистина се генерираат во минута. Ако тој лимит е достигнат, намалете ја должината на одговорите или бројот на истовремени генерирања. Вредноста max_tokens сама по себе не го троши OTPM однапред. Висока граница за поединечен одговор затоа не е доволна дијагноза за грешка поврзана со излезните токени.

За конкретното одбиено барање, споредете ја пораката за грешка со заглавјата од групите anthropic-ratelimit-requests-*, anthropic-ratelimit-input-tokens-* и anthropic-ratelimit-output-tokens-*. Полето remaining покажува преостанат капацитет, а reset означува кога соодветниот капацитет ќе биде целосно обновен; токенските вредности во remaining се заокружени. Заглавјето anthropic-workspace-id помага да утврдите на кој работен простор се однесува барањето. Чувајте ги заедно моделот, работниот простор и типот на погодениот лимит: тие кажуваат дали треба да го намалите бројот на барања, влезот или генерираниот излез.

Почитувајте го retry-after и ограничете ги обидите

Кога одговорот за привремено ограничување има retry-after, третирајте ја неговата вредност како најрано дозволено време за повторување, изразено во секунди. Ако задачата има пократок рок, вратете контролирана грешка или одложете ја задачата; не испраќајте ја порано само за да го исполните локалниот рок. Капацитетот се обновува постепено, па истовремено разбудени работници можат повторно да го погодат лимитот.

Без употребливо retry-after, користете експоненцијално одложување со случајна варијација. За секој следен обид зголемете ја горната граница на чекањето, а секој работник нека избере различно време во таа граница. Поставете и најголем број обиди и вкупен рок за задачата. Ова е политика за обработка на привремена грешка, не начин да се зголеми дозволената стапка: ако новите барања продолжат да пристигнуваат побрзо од капацитетот, намалете го приливот кон заедничката редица.

Ако користите официјален SDK, земете ги предвид неговите автоматски повторувања во истиот вкупен буџет за обиди. SDK-јата повторуваат дел од привремените грешки со експоненцијално одложување и го почитуваат retry-after кога е присутно. Сопствена петља поставена над нив може да испрати повеќе барања отколку што очекувате. При повторен неуспех, повторно прочитајте ја причината: следниот одговор може да укажува на друг лимит.

Одделете ја потрошувачката од минутната стапка

Описот на грешките во Claude API разликува поставен лимит за потрошувачка, кој за организација или работен простор обично враќа 400, од месечниот лимит на тарифното ниво, кој враќа 429 без retry-after. Лимитот на работниот простор Claude Code е посебен случај: неговите барања може да добијат 429 со retry-after. Затоа ниту статусот 429 ниту присуството на заглавјето сами по себе не ја заменуваат проверката на пораката за грешка.

Кај 400, прочитајте ги типот и пораката пред да го запрете барањето: тој статус може да означува и проблем со содржината. Ако пораката кажува дека е достигнат лимит што сте го поставиле, прекинете ги автоматските повторувања и проверете го буџетот во Claude Console. Кај 429 без retry-after, проверете дали error.details.error_code е enforced_spend_limit_reached. Тој код означува достигнат месечен лимит на тарифното ниво; повторувањето ќе продолжи да не успева додека пристапот не се обнови или лимитот не се зголеми.