{"version":"2.1.228","anchor":"api-rejections-are-classified-from-a-structured-marker-inste","canonical_anchor":"api-rejections-are-classified-from-a-structured-marker-inste","heading":"API rejections are classified from a structured marker instead of prose alone","tier":"internal","area":"API Errors","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.228\/e\/api-rejections-are-classified-from-a-structured-marker-inste","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.228","markdown":"### API rejections are classified from a structured marker instead of prose alone\n\nRequest rejections are now identified from a structured marker rather than guessing from error wording.\n\n**What**\n\nClaude Code now reads a `capability_rejected: ` marker with a reason token out of 400 and 413 responses, rather than only lowercasing the error text and searching it for phrases. Token matching uses a word boundary, so `image_block` no longer matches `image_blockade`. Prose matching remains as a fallback, so nothing changes against servers that do not send the marker.\n\n**Details**\n\n- Reason codes include prompt_too_long, mid_conv_system, cache_control_field, thinking_signature, effort_unsupported, media_budget, max_tokens_context_overflow, and per-beta-header entries.\n\n**Evidence**\n\n`capability_rejected: `\n\n- Area: API Errors\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 3\/5"}