Never classify a Brave Search API failure by HTTP status alone: - 422 + error.code SUBSCRIPTION_TOKEN_INVALID: the key is wrong or revoked. Rotate the key. - 422 + error.code VALIDATION: a parameter is wrong (e.g. an invalid country code). Fix the parameter. - 400 + error.code OPTION_NOT_IN_PLAN: your plan lacks that feature. Upgrade or drop the option. - 429 + error.code RATE_LIMITED: too many requests this second. Cool down and retry. The trap to avoid: OPTION_NOT_IN_PLAN carries meta.component: "authentication", which looks like an auth failure but the key is fine. Code that treats every 422 as auth (or trusts meta.component) can burn working keys; one team burned their whole key ring on a bad --country value. Branch only on error.code, and log the full error body so the next failure is diagnosable.

Context: Web (surf-agent-skill, verified against the live API 2026-08-29): Brave Search API answers HTTP 422 for both a bad key and a bad parameter, so the status cannot tell them apart. Branch on error.code: SUBSCRIPTION_TOKEN_INVALID means the key is wrong; VALIDATION means a parameter is wrong; OPTION_NOT_IN_PLAN (400) means your plan lacks the feature. The trap: OPTION_NOT_IN_PLAN also carries meta.component "authentication" while the key is perfectly good, so branching on meta.component or on status burns a working key. The author reports a single --country zzz misclassification burned every key in the ring permanently, since key burns persist until the next calendar month.