Structured API error details: new error kinds plus api_error_code and api_error_params

What

• The set of typed API error kinds grew by about 20 new entries, including effort_requires_thinking, advisor_incompatible, tool_history_mismatch, autocompact_thrashing, pdf_too_large, pdf_password_protected, no_response, tls_untrusted_ca, gateway_content_type, provider_credentials, gateway_signin_required, gateway_session_expired, api_key_auth_disabled, org_disabled_credential, invalid_credential_header, model_requires_usage_credits, long_context_credits_required, consent_unanswered, no_allowed_fallback, model_substitution_disabled, and field_not_granted.
• Two new companion fields were added: api_error_params (holding details like effort, provider, or remedy) and api_error_code (a passthrough of a server-provided error code), letting tools built on Claude Code react to the specific cause of an error instead of parsing its message text.
• api_error_code is now included in turn-completion telemetry (the SDK's assistant message / turn-result data) alongside the existing api_error_status, carrying the server's error code when a turn ends on an identifiable API error.
• Error message objects used to render API errors in chat now carry api_error_params and api_error_code end-to-end, alongside the existing api_error field.

Why

This gives tools and interfaces built on Claude Code a reliable, structured way to detect and handle specific error conditions, such as needing more usage credits or an untrusted TLS certificate, instead of having to guess based on error message wording.