{"version":"2.1.281","anchor":"auto-mode-stage-2-classifier-rate-limit-errors-carry-the-re","canonical_anchor":"auto-mode-stage-2-classifier-rate-limit-errors-carry-the-re","heading":"Auto mode classifier stops at its deadline on rate limits and tells the model how long to wait","tier":"notice","area":"Auto Mode","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281\/e\/auto-mode-stage-2-classifier-rate-limit-errors-carry-the-re","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281","markdown":"### Auto mode classifier stops at its deadline on rate limits and tells the model how long to wait\n\nAuto mode's safety classifier can give up at its deadline under rate limits and now passes the API's requested wait on to the model\n\n**What**\n\nAuto mode uses a classifier, a separate model call that reviews each action before it runs. This release changes how that classifier handles rate limits. A rate limit is when the API answers \"too busy, try again after a while\", and the wait it asks for is called a retry-after.\n\n- `sideQuery`, the helper that makes these background model calls, takes a new `retryAfterBudgetMs` option. If a 429 or 529 response asks for a wait at least as long as the time left before the deadline, the response is marked `x-should-retry: false` and tagged with an internal `x-cc-retry-after-too-long` header. The call then fails instead of sleeping past its deadline. The internal header is removed before the error is shown. Before, any retry-after was honoured.\n\n- The classifier passes this budget only when `rateLimitFailFastEnabled` is true in the `tengu_auto_mode_config` remote configuration.\n\n- When the second-stage classifier call fails with a retry-after, the reason given to the model now says how long the API asked to wait and not to retry before then. It says the denial is not a safety judgment and tells the model not to retry or try other reviewed actions until the wait is over. For long waits it adds: stop and tell the user. Before, it always said the error was \"usually transient\" and that retrying often succeeds.\n\n- The classifier result now carries `retryAfterMs`, which is passed to the code that writes the denial message, and the outcome record gains `retryAfterBucket`.\n\n- The classifier's outer retry loop now stops as soon as the result carries `retryAfterMs`, and its check for results that must not be retried now reads the current result.\n\n- `server_thread_unsupported` is now treated as a temporary failure with no verdict.\n\n- A user message holding a single tool result can now carry `classifierBoundary: true`. When the conversation is prepared for the classifier, the action whose result is marked this way starts a new text segment. The mark is saved with the message, so it is kept even when only the stored transcript is available. The classifier call also takes one extra argument.\n\n**Why**\n\nUnder rate limits, an action no longer has to sit blocked waiting on a classifier that cannot answer in time, and the model is no longer told to keep retrying a service that has asked it to wait. Nothing has been read about `rateLimitFailFastEnabled`, so whether the fail-fast part is active is unknown.\n\n- Flag `tengu_auto_mode_config`: Not enough to say (read for one account on one subscription tier against v2.1.281; this account: no value returned, anonymous baseline: no value returned, compiled default: not a boolean we can read) These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.\n- Area: Auto Mode\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 3\/5"}