A junk API response now names what actually answered and suggests checking for a proxy or gateway.
What's wrong with this entry?
When the API returns something that is not a message, the error now fingerprints the responder instead of failing bare, and suggests checking for a proxy or gateway intercepting the request. Two new structured log events, cli_api_error and cli_api_retry, carry the same detail. This is aimed at corporate gateways sitting in front of the API.
- The fingerprint records content-type bucket, body kind (event stream, HTML, XML, JSON served under the wrong content type, and so on), byte size, and whether the request id looks Anthropic-issued.
- A server-header classifier covers roughly 20 intermediaries including cloudflare, envoy, zscaler, squid, haproxy, netskope, bluecoat and big-ip, plus Apigee fault source and code taxonomies and the set of intermediary headers seen.
- The log events include a
routeblock: provider, whether the base URL is the default, an Anthropic one or custom, and whether an https proxy, custom headers, extra CA certificates or a client certificate are in use. - No flag guards this; it sits on the normal API error paths.
check for a proxy or gateway intercepting the request.
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.228
API rejections are classified from a structured marker instead of prose alone
Both mention error
-
v2.1.228
Oversized media in a request is now its own rejection class
Both mention error
-
v2.1.229
Render errors are now reported instead of silently blanking
Both mention error